The certificate field browsers read, and CN is not it

A certificate carries a Common Name in its subject, and it carries a list of names in an extension called Subject Alternative Name. The Common Name is the one that looks authoritative, appears first in every viewer, and is the one people check.

It is also not consulted. Name matching is done against the SAN list, and only against the SAN list. RFC 6125 deprecated using the Common Name for this, and the CA/Browser Forum's baseline requirements make the extension mandatory. A certificate whose Common Name says example.com and whose SAN list does not will fail on every current client, with an error that mentions the name and not the field.

Read the list, not the summary

echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -ext subjectAltName

The -servername flag is not optional decoration, and leaving it out is the single most common way to diagnose this incorrectly. More on that below.

What comes back is the complete set of names this certificate is valid for. Compare it against the list of hostnames the site actually answers on, and the answer to almost every multi-domain certificate problem is in that comparison.

The wildcard rule that catches everyone

A wildcard replaces exactly one label, in the leftmost position. That produces two consequences people consistently get wrong.

*.example.com does not match example.com. The apex is a different name and needs its own entry, which is why almost every real wildcard certificate carries two SAN entries: the wildcard and the bare domain. A certificate issued with only the wildcard leaves the apex broken, and since most visitors arrive at www, it can go unnoticed for a while.

*.example.com also does not match shop.eu.example.com. One label, not any number of them. A site that grows a second level of subdomains needs either a second wildcard or explicit entries, and the failure arrives on the day somebody adds the DNS record.

Four shapes this takes on real sites

The apex is missing. Certificate covers www.example.com only. Everything works because the site redirects the apex to www, until somebody links directly to the apex over HTTPS, or a monitoring check does, and the redirect is never reached because the handshake fails first.

A subdomain outgrew the certificate. A new shop. or api. or staging. record is created, the vhost is configured, the service works over plain HTTP, and TLS fails for a name that was never requested. The DNS change and the certificate are managed by two different processes and nothing connects them.

A reissue dropped a name. The certificate is renewed by a process that rebuilds the name list from configuration, and one entry was in the old certificate and not in the configuration. Renewal succeeds, everything reports healthy, and one hostname out of six stops working. This is the nastiest one, because a renewal that partially breaks the estate looks identical to a renewal that worked.

A migration changed the default. A host that serves several sites has a default virtual host, and requests that do not match a name get its certificate. Adding or removing a site changes which one is the default.

SNI, and why omitting -servername gives the wrong answer

Several sites share one address, and the server has to know which certificate to present before it has seen any HTTP. The client tells it during the handshake, in a field called Server Name Indication.

Run openssl s_client without -servername and it does not send SNI. The server, given no name, presents whatever it considers the default, which on a shared host is frequently some other customer's certificate. You then read a SAN list belonging to a site you have never heard of and conclude the certificate is catastrophically wrong.

# wrong: no SNI, may return the default vhost's certificate
echo | openssl s_client -connect example.com:443

# right: names the host, gets the certificate a browser would get
echo | openssl s_client -servername example.com -connect example.com:443

The same applies to monitoring. A check that connects by IP address, or through a tool that does not send SNI, will validate against a certificate no visitor ever sees. When a certificate check disagrees with a browser, this is the first thing to rule out, and the rest of the ordering, step by step, is in where a handshake actually stops.

The reverse case also exists and is worth knowing about: a client too old to send SNI at all gets the default certificate and therefore a name mismatch, no matter how correct your configuration is. That population is small now, and it is not zero if the client's audience includes embedded devices or payment terminals.

Checking every name you are responsible for

The failure is always a name that is served and not listed, so the check writes itself: for each hostname, fetch the certificate that name receives, and assert the name is in its SAN list.

while read -r h; do
  san=$(echo | openssl s_client -servername "$h" -connect "$h:443" 2>/dev/null \
        | openssl x509 -noout -ext subjectAltName 2>/dev/null)
  case "$san" in
    *"DNS:$h"*) printf 'ok      %s\n' "$h" ;;
    "")         printf 'NO TLS  %s\n' "$h" ;;
    *)          printf 'MISSING %s\n' "$h" ;;
  esac
done < hostnames.txt

That is deliberately naive about wildcards, and the naivety is useful: a wildcard-covered host will report MISSING, which makes you look, and looking at your wildcard coverage once a quarter is not wasted. Refine it if the noise annoys you.

The input file matters more than the script. It has to be every hostname you serve, including the ones nobody visits: the apex and the www, the staging copy, the mail hostname, the API, the old domain still redirecting from a rebrand three years ago. Those last two are where lapses live, because nothing in normal traffic touches them until something does.

The one to add to the list today

Redirect-only hostnames. A domain retired during a rebrand, still pointed at your server, still doing its job of sending people to the new name. It needs a valid certificate for the redirect to be reachable over HTTPS, and it is the hostname least likely to be in anyone's renewal configuration.

The failure is quiet in a specific way: search engines and old links still send traffic there, those visitors get a full-page security warning instead of a redirect, and no analytics on the destination site will ever show you the loss. Reading what such a certificate is actually serving, chain included, takes one of the three commands worth memorising.

Redirect-only hosts are also where a certificate somebody generated by hand tends to get left in place, on the reasoning that nobody looks at that name anyway. Sometimes that reasoning holds and a self-signed certificate is the right answer. A hostname search engines still send traffic to is not one of those cases.