Subject Alternative Name and the end of Common Name matching

Ask an experienced engineer which field of a certificate names the server and a surprising number will say the Common Name. That answer has been wrong for a while and is now wrong by specification. Service identity in TLS lives in the Subject Alternative Name extension and nowhere else, and the fallback that once made the old answer half-true has been deleted rather than deprecated. The practical consequences show up in error messages, in issuance profiles, and in certificates that have no subject at all.

The rule that changed, and what it replaced

RFC 9525, “Service Identity in TLS”, published in November 2023, obsoletes RFC 6125. Its section 2 is unambiguous:

The Common Name RDN MUST NOT be used to identify a service because it is not strongly typed (it is essentially free-form text) and therefore suffers from ambiguities in interpretation. For similar reasons, other RDNs within the subjectName MUST NOT be used to identify a service.

RFC 6125 had merely deprecated the Common Name identifier as a fallback, which meant a client was permitted to check the Subject Alternative Name first and consult the Common Name if no name was found there. RFC 9525 removes the fallback. Appendix A of the newer document states that the server identity “can only be expressed in the subjectAltNames extension; it is no longer valid to use the commonName RDN”. There is no ordering question left to answer, because there is only one place to look.

The second sentence of the quotation is the one people miss. The prohibition is not narrowly about Common Name. No Relative Distinguished Name inside the subject may be used to identify a service, so an organisation that has been stuffing hostnames into an organisational unit field has no better standing than one relying on Common Name.

A certificate with no subject at all

The cleanest proof that identity has moved is a certificate that has nowhere else to put it. Below is a real certificate issued over ACME by a test authority, inspected immediately after issuance.

subject=
issuer=CN=Pebble Intermediate CA 03d090
serial=3DC74918D250C7E9
notBefore=Aug 26 21:31:04 2026 GMT
notAfter=Nov 24 21:31:03 2026 GMT

X509v3 Key Usage: critical
    Digital Signature
X509v3 Extended Key Usage:
    TLS Web Server Authentication
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Subject Alternative Name: critical
    DNS:web.lab.example

The subject= line is not truncated output. The subject is an empty sequence: the certificate names no organisation, no country, no locality and no Common Name. It is nonetheless a completely ordinary, usable TLS server certificate, and any current client will accept it for web.lab.example. Everything a verifier needs in order to decide who this certificate is for is inside the Subject Alternative Name.

Now look at the word critical on that extension, because it is not present on the SAN of the certificate in the first lesson of this part. RFC 5280 requires the Subject Alternative Name to be marked critical exactly when the subject is an empty sequence, and recommends non-critical otherwise. The reason is a direct consequence of the criticality contract. If the SAN were non-critical, a verifier that did not recognise the extension would be permitted to skip it, and it would then be looking at a certificate with no identifying information whatsoever. Marking the extension critical converts that outcome into an outright rejection. An old verifier fails closed instead of accepting an anonymous certificate.

Verification and issuance are two different rules

It is easy to over-correct here, so hold the two rules apart.

• Verification is settled. A client MUST ignore the Common Name for service identity. There is no fallback and no configuration flag that is supposed to bring one back.
• Issuance is not a prohibition. Under the CA/Browser Forum TLS Baseline Requirements, the Subject Alternative Name MUST be present and must contain at least one dNSName or iPAddress entry, and the Common Name in a subscriber certificate is marked NOT RECOMMENDED. It is not banned. If a CA does include it, the value must be exactly one of the values already in the SAN, encoded as a character-for-character copy of that entry.

So a certificate carrying a Common Name is not defective, and a certificate lacking one is not incomplete. What would be defective is a Common Name carrying a name that does not appear in the SAN, because clients will not see it and will refuse the connection while an operator reading the certificate insists the name is present.

The Baseline Requirements also restrict which kinds of name may appear in a SAN for a public TLS certificate: dNSName and iPAddress only. The other general name forms, including uniformResourceIdentifier and rfc822Name, are not permitted. Private hierarchies are free to be more liberal, and some workload identity systems rely on that freedom, but a name form that a public CA cannot issue is also a name form that many verifiers will not match on.

What a mismatch looks like from two tools

The failure is common enough that both wordings are worth memorising, because they describe the same event from different sides.

CERT=/etc/ssl/certs/app.lab.example.pem
openssl x509 -in "$CERT" -noout -ext subjectAltName
openssl verify -CAfile root.crt -untrusted srv-ca.crt \
  -verify_hostname wrong.lab.example "$CERT"

The first command lists the names the certificate actually asserts. The second asks OpenSSL to perform the same match a TLS client performs, and when the requested name is not among them the result is:

error 62 at 0 depth lookup: hostname mismatch

A client speaking to a live listener describes it differently. The same condition reported by curl reads:

curl: (60) SSL: no alternative certificate subject name matches target hostname 'wrong.lab.example'

The phrase “alternative certificate subject name” is curl naming the SAN extension, and the message is telling you that it looked there and found nothing that matched. It will not tell you what the Common Name says, because it never read it. Depth zero in the OpenSSL wording localises the problem to the leaf, so the chain and the trust store are already exonerated.

flowchart TD
    A["Client wants api.example.com"] --> B["Server sends certificate"]
    B --> C["Collect dNSName entries from SAN"]
    C --> D{"Requested name matches an entry?"}
    D -- "yes" --> E["Identity accepted, continue"]
    D -- "no" --> F["error 62: hostname mismatch"]
    B -- "Common Name is never consulted" --> C

The diagram shows the whole matching decision. The client starts with the name it intended to reach, collects the dNSName entries from the Subject Alternative Name, and compares. The subject field never enters the comparison, which is why editing a Common Name to fix a mismatch achieves nothing at all.

Production discipline

1. Enumerate the SAN before you argue about the name. One -ext subjectAltName run settles what the certificate asserts, and it takes precedence over what any ticket or inventory record claims.
2. Never fix a mismatch by editing the Common Name. No current client reads it. If the name is missing from the SAN the certificate must be reissued, and any procedure that suggests otherwise is describing behaviour that was removed.
3. Add every name a service is reached by, including the ones you inherited. Vanity aliases, load balancer names and legacy redirect hosts all hit the same match, and each one omitted is a future outage on a path nobody tests.
4. Treat a wildcard as one label of coverage, no more. Plan the naming hierarchy so that services sit at the depth the wildcard actually reaches, rather than relying on a client that matches loosely.

Cross-course references

• Kubernetes for Production Sysadmins - Part LXXVI (Certs) covers the cluster PKI, whose component certificates must carry every in-cluster name a peer will actually use to reach them.
• Observability for Production Sysadmins - Part XI (Blackbox) covers probing a service from outside, the only reliable way to notice that a name was dropped from a SAN during a reissuance.
• Linux for Production Sysadmins - Part LXXI (TLS) covers host TLS service configuration, including the reverse proxy that most often answers an SNI value with the wrong certificate.

Quiz