skip to content

Where must a server's identity appear in an X.509 end-entity certificate, and what became of the subject common name?

level: middleimportance: must knowfreq 68%

answer

  1. two sets of names, compared
  2. the extension, not the directory name
  3. which kind of identifier, exactly
  4. dNSName for hosts, iPAddress for addresses
  5. the CN fallback was withdrawn

basics

~20 s

A server identity belongs in the subjectAltName extension, as a dNSName or iPAddress GeneralName. The common name inside the subject is descriptive text: the CN-ID fallback older rules allowed for identity matching has been removed.

solid answer

~40 s

Identity matching has two halves. The **reference identifier** is what the caller wanted — the name it set out to reach. The **presented identifiers** are what the certificate offers, and those come from `subjectAltName` only: `dNSName` entries for host names, `iPAddress` entries for literal addresses, with `SRV-ID` and `URI-ID` forms for protocols that name a service rather than a host. The `subject` distinguished name, including its common name, is descriptive directory data. RFC 6125 allowed a `CN-ID` fallback when no suitable `subjectAltName` entry existed; RFC 9525 removed that, so a certificate whose only matching name is in the common name matches nothing. And a name in `subjectAltName` proves only that the issuer wrote it there — what was checked before signing is a separate question entirely.

code

pseudocode · 18 lines
pseudocode
presented = empty list

for each name in leaf_certificate.subjectAltName:
    if name is a dNSName   then append name to presented
    if name is an iPAddress then append name to presented
end for

if presented is empty then
    reject          // nothing is presented; the subject common name is not consulted
end if

for each candidate in presented:
    if candidate matches reference_identifier then
        accept
    end if
end for

reject

go deeper

for a junior

Know that the name a client matches lives in the subjectAltName extension, not in the subject line, and that one certificate can present many names.

for a middle

Explain the reference-identifier and presented-identifier split, name the GeneralName choices that carry host names and addresses, and say why the common-name fallback was withdrawn.

for a senior

Diagnose the failures: an address written as text, a name only in the common name, a wildcard expected to span two labels — and separate a structural match from evidence of diligence.

for a principal

Decide what your organisation does about a structurally valid certificate naming your domains that nobody there requested, since the certificate itself cannot answer that question.

"The certificate has the right name on it" is the single most common half-truth about X.509, because it skips both which field the name came from and what writing a name there actually proves. ## Two vocabularies: reference and presented Identity checking compares two sets of strings: - A **reference identifier** is what the initiating side intended to reach, derived from the name it was configured with or asked for. - A **presented identifier** is what the certificate offers as a name for its subject. A match means one presented identifier equals one reference identifier under the comparison rules for that identifier type. The vocabulary matters because the profile names the *kinds*: a `DNS-ID` is a host name, a `CN-ID` is the deprecated common-name form, a `SRV-ID` names a service at a domain, a `URI-ID` names a resource. "The identifier did not match" is meaningless until you say which kind. ## Where the presented identifiers actually live They come from the `subjectAltName` extension, which holds a sequence of `GeneralName` choices. Two carry almost all web traffic: - **`dNSName`** — a host name as text. A certificate covering several names lists them all here, one entry each. - **`iPAddress`** — a literal address, encoded as octets rather than as text. The encoding distinction is a real, recurring production failure. An address written into a `dNSName` entry as the string `10.2.0.7` is not an `iPAddress` entry, and a verifier comparing an address reference identifier looks in the `iPAddress` entries only. The certificate looks correct to a human reading a dump and fails every connection. Wildcards, where the profile allows them at all, are confined to the **entire leftmost label** of a `dNSName`: a certificate for `*.example.test` presents a name that matches `shop.example.test` and does not match either `example.test` itself or `a.b.example.test`, because the wildcard covers exactly one label. Partial-label forms are not permitted by the current rules, and an `iPAddress` entry cannot be wildcarded at all. ## Why the common name went away | | RFC 6125 | RFC 9525 | |---|---|---| | `DNS-ID` from `subjectAltName` | The primary source | The only source | | `CN-ID` from the subject | Permitted as a fallback when no suitable SAN entry existed | Removed; not consulted | | Wildcards | Allowed, with partial-label forms discouraged | Confined to the whole leftmost label | | Practical effect | Two places to look, and implementations disagreed about when | One place to look | The fallback was removed because it created exactly the ambiguity an identity check cannot afford. A distinguished name is a directory record with organisation, country and locality components; its common name is free text with no structure guaranteeing it is a host name at all. Two implementations could reach opposite conclusions about the same certificate, depending on whether they consulted the common name and under what conditions. Conforming clients had already stopped honouring it well before the rule was written down. ## What the presence of a name proves This is where the interviewer usually pushes, and the honest answer is short: a `dNSName` entry proves the **issuer wrote that name into a certificate it signed**. Nothing in the field records what was checked beforehand — whether anyone demonstrated control of the name, what kind of validation the authority performed, what its profile required. Those are properties of the issuance process, not of the encoded structure, and they are not recoverable from the certificate by inspection. That gap is the entire reason a registry runs a monitor over certificates issued for names in its zone. The monitor is not asking whether a certificate is well formed; it is asking **who was willing to name our domains, and did anyone ask us?** A well-formed certificate carrying a perfectly spelled `dNSName` for a name the registry administers, issued by an authority nobody in the organisation deals with, is structurally flawless and operationally alarming. ## Practical consequences - Read identities from `subjectAltName` and nowhere else; if it is absent or empty there is no presented identifier and the comparison fails. - Put literal addresses in `iPAddress`, never as text in `dNSName`. - Expect multi-name certificates: one entry per name, and the subject's common name — if present at all — is usually just the first of them repeated for display. - Treat a matching name as the beginning of the question, not the end of it. Structure is checkable; diligence is not.

  • A certificate lists 10.2.0.7 as a dNSName rather than an iPAddress. What goes wrong?
    A verifier comparing an address reference identifier reads the `iPAddress` entries, and there are none, so nothing matches. The text in `dNSName` is never consulted for that comparison. The certificate looks right in a dump and fails every connection until it is reissued with the correct GeneralName choice.
  • Does a dNSName entry prove the requester controlled that domain?
    No. It proves the issuer wrote the name into a certificate and signed it. What the authority verified beforehand is a property of the issuance process and leaves no trace in the encoded fields — which is exactly why a registry monitors certificates issued for its own zone.
  • Which names does a certificate presenting *.example.test match?
    One label in that position: `shop.example.test` matches, `a.b.example.test` does not, and the bare `example.test` does not either. The wildcard must be the complete leftmost label, so partial forms are not permitted and an address entry can never be wildcarded.

saying these in an interview costs you the question

  • Says the certificate is fine because its common name matches the host name
  • Thinks subjectAltName is only needed when a certificate covers several names
  • Puts a literal address in a dNSName entry because it is still a name
  • Claims a name in subjectAltName proves the holder owns that domain
  • Believes a wildcard spans several labels, so it covers sub-subdomains