Certificate does not cover the hostname

The Subject Alternative Name extension holds the list. The older Common Name field is deprecated for this purpose and is ignored by current browsers, which is why a certificate that looks correct in a control panel can still fail.

Matching is exact for a plain name. `example.com` does not cover `www.example.com`, and `www.example.com` does not cover `example.com`. They are two names and both must be listed.

A wildcard covers exactly one level. `*.example.com` matches `www.example.com` and `shop.example.com`; it does not match `example.com` itself, and it does not match `a.b.example.com`.

So a site serving the apex and the `www` host needs both listed, and a wildcard alone is not enough — which is the single most common cause of this failure.

Server Name Indication decides which certificate is presented when several sites share an address. A server configured without SNI, or with the wrong default, presents another site's certificate entirely.

A new subdomain pointed at an existing server. DNS is added, the server answers, and the certificate was issued before the name existed.

A migration to a hosting platform that issues certificates automatically for the names it knows about, where one name was configured later and never added.

A wildcard purchased on the assumption it covers the apex, which it does not.

Regional or language hosts added for a campaign and never added to the certificate.

An API or asset subdomain, where the failure is invisible in a browser because nobody visits it directly and highly visible to the clients that depend on it.

And staging or preview hosts, which usually matter less but produce the same alarming interstitial for anyone testing.

What they share is that the site works. Somebody checks the home page, sees a padlock, and the uncovered name is one nobody thought to open — so the gap is reported by a customer rather than found by a review.

`openssl s_client -connect example.com:443 -servername www.example.com < /dev/null 2>/dev/null | openssl x509 -noout -text | grep -A1 'Subject Alternative Name'` prints the covered names.

The `-servername` flag matters: it sends SNI, which is what a real browser does. Omitting it can return a different certificate entirely and give a misleading answer.

Test each hostname you serve, including the ones nobody visits in a browser. `curl -I https://api.example.com/` fails loudly on a mismatch.

Check the certificate chain too. A missing intermediate produces a failure that looks like a mismatch to some clients and works fine in desktop browsers, which fetch the missing pieces.

Reissue the certificate with every hostname the server answers on, listed explicitly, plus a wildcard if subdomains are added often.

List both the apex and `www` even when one redirects to the other. The redirect happens after the TLS handshake, so the certificate must be valid for the name the visitor typed before any redirect can occur.

That last point catches people: a certificate covering only `www` does not save the apex, because the browser never gets far enough to be redirected.

Keep the hostname list in the automation rather than in someone's memory, so adding a DNS record and adding a certificate name are one step.

After reissuing, verify each hostname externally rather than trusting the issuance log, and confirm the service reloaded.

`transport.certificate_coverage` compares the hostnames the certificate declares against the hostnames the site is served on, and reports the ones not covered.

`transport.certificate_details` reports the certificate itself — issuer, validity, the full name list — so the gap is visible as evidence rather than as a conclusion.

`transport.canonical_host` and `domain.url_variants` report which host variants actually answer, which is what determines whether a missing name matters in practice.

`availability.tls_failure` reports a handshake that failed outright, which is what a visitor to an uncovered hostname experiences.