A freelance designer had a lovely portfolio. She had spent weeks on the case studies, photographed her work properly, and written text she was reasonably proud of. The site was fast, the padlock was there, and she checked it on her own laptop and her phone before telling anyone it was live.
Then a prospective client sent a message. They liked the work, but when they typed the address into their browser with www in front, a full-page security warning had appeared, and they had not been brave enough to click past it. They had found her by another route, and mentioned the warning almost as a favour.
What the client saw
Depending on the browser, the warning reads a little differently. One says "Your connection is not private". Another says "Warning: Potential Security Risk Ahead". Underneath, in small type, is an error code, and the one that matters here is a name mismatch. Chrome-family browsers call it NET::ERR_CERT_COMMON_NAME_INVALID, and Firefox says SSL_ERROR_BAD_CERT_DOMAIN. In plain terms, both mean: this certificate is genuine, but it was issued for a different name from the one you asked for.
The details panel went on to list the names the certificate did cover: example.com and nothing else. The client had typed www.example.com.
That tells you almost everything. It was not expiry, not a bad installation, not an attacker. The certificate had one name on it and the visitor had arrived using another.
Why she never noticed
She always typed the bare version of the address, example.com, because it was shorter and it was what she printed on her cards. Her browser had also been remembering it. Every test she made was a test of the one name that worked.
This is a classic blind spot. We test our own sites the way we always reach them, from machines that have visited many times. Browsers cache redirects, remember which version you prefer, and in some cases will add or strip a prefix for you. A visitor arriving from a search result, an old link, a directory listing, or an email signature they typed by hand will not have any of that help.
The two names are separate hostnames as far as the network is concerned, even though most people think of them as the same site. They can have different DNS records, different certificates and different behaviour. The apex or bare domain (example.com) and the www subdomain are as different as example.com and shop.example.com.
What had gone wrong
The history was short. When she bought hosting, the host issued a free certificate automatically for the domain. Automatic issuance of this kind works by asking a certificate authority to confirm that the hostname points at the server, and it can only cover names that already work at the moment of the request. At the time, the domain had been set up with only the bare name resolving. Her www record was added later, as a CNAME pointing at the bare domain, a few hours after the certificate was issued.
example.com. 3600 IN A 203.0.113.25
www.example.com. 3600 IN CNAME example.com.Nothing told the certificate system that a new name had appeared. The certificate stayed as it was, covering the bare domain only, and it would have stayed that way until renewal. Some hosting panels will add the new name on the next renewal cycle automatically; others never do unless asked. In her case, it was the second kind, and nobody had added it.
The diagnosis
She phoned her host. The support agent asked her to try both versions on a device that had never visited the site, and she borrowed her partner's phone, which had been on mobile data throughout. The bare domain was fine and the www version produced the warning, exactly as the client had said.
The agent had her run a command from the terminal on her laptop, which shows precisely what the server offers:
openssl s_client -connect www.example.com:443 -servername www.example.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltNameThe output listed a single entry under the subject alternative names, DNS:example.com. The Subject Alternative Name field is the list modern browsers actually check. The older common name field is largely ignored for matching, so putting the name in only one place does not help. She did not have to read the output with any expertise; the absence of a second line was the answer.
The fix, in five minutes
In the hosting control panel, under the SSL or certificate section, she found the automatic certificate and an option to reissue or add a hostname. The steps were short.
- Confirm that
www.example.comresolves correctly and points at the same server. A certificate request for a name that does not resolve will fail. - Add
www.example.comto the certificate's list of names, so that it covers both the bare domain and thewwwform. - Request issuance, wait a minute or two for validation to finish, and let the panel install the new certificate.
- Test both addresses again from a device that had never visited, then clear the browser's cache on her own laptop and repeat.
Total time was about five minutes, most of it waiting for the certificate authority. Because the new certificate named both hostnames, the warning disappeared on the next visit with no change to the website itself.
She also added a redirect so one of the two forms always sends visitors to the other, which avoids the site existing at two addresses in search results. The redirect generator writes the rule for common servers. The choice between bare and www is largely a matter of taste, but pick one, and redirect the other.
Why the order of events matters
If the www record had existed before the first issuance, the automatic system would very probably have covered both names from day one. The same trap catches people who add a shop or blog subdomain months later and assume the existing padlock extends to it. It does not. A certificate is a list of names, and a name that is not on the list gets a warning, however healthy everything else looks.
What to look at on your own setup
You can test any site in a couple of minutes without special software.
- Open a private or incognito window and visit both
https://example.comandhttps://www.example.com, typing the full address each time. Click the padlock and read the names the certificate covers. - Repeat on a phone using mobile data, which has no history with your site.
- Run
curl -I https://www.example.comfrom a terminal. A certificate error appears as a refusal to connect, which is the same warning your visitors meet in a browser. - Check any other subdomains you use, such as
mail,blogorportal. Each hostname that serves HTTPS needs to appear on a certificate, either listed individually or covered by a wildcard. - Note the expiry date while you are there. The SSL expiry checker reports it for any public hostname.
Smaller questions
Does a wildcard certificate solve this?
A wildcard for *.example.com covers www and any other subdomain, but it does not cover the bare domain on its own. Wildcards are normally issued together with the bare name for that reason. Many hosts avoid wildcards for shared hosting because the validation step is harder.
Why did the host not add www automatically?
Some do, but the certificate was requested when only the bare name existed. Automated systems cannot guess a name will appear later.
Is the warning actually dangerous?
In this case, no. The connection to the correct server was fine. But visitors cannot tell that, and the correct reaction to a warning is to leave, which is exactly what the first client nearly did.
Could the problem come back?
Yes, if the renewal process rebuilds the certificate with only one name. Check after the first automatic renewal, and after any move.
Looking back
The lesson the designer took away was to test both versions of the address after any change, and to do it from a device that had never visited the site. That second part matters more than it sounds: your own machines have every reason to be kind to you, and a stranger's phone does not.