skip to content

When a verifier builds a path from an end-entity certificate up to a trust anchor, what links each certificate to the next?

level: juniorimportance: must knowfreq 70%

answer

  1. two links per hop, not one
  2. names say where, signatures say whether
  3. issuer below equals subject above
  4. the key above verifies the body below
  5. the anchor is configured, not verified upward

basics

~10 s

Two links join every hop: the issuer name in one certificate equals the subject name of the certificate above it, and that upper certificate's public key verifies the lower one's signature.

solid answer

~40 s

Path building walks upward one hop at a time, and each hop has to satisfy two independent links. The **name link**: the `issuer` field of the certificate you are standing on must equal the `subject` field of the candidate above it. The **signature link**: that candidate's `SubjectPublicKeyInfo` must verify the issuer's signature over the lower certificate's `TBSCertificate`. Names alone prove nothing, because anyone can write any string into an `issuer` field; the signature is the part that carries evidence, and the name only tells the verifier where to look. The walk ends at a trust anchor, which the verifier holds as configured trust anchor information rather than as something checked against anything higher. `authorityKeyIdentifier` and `subjectKeyIdentifier` narrow the search when several candidates share a name.

code

pseudocode · 16 lines
pseudocode
certificate[0]  (end-entity)
    subject = CN=shop.example.com
    issuer  = CN=Example Issuing CA        -- names the certificate above

certificate[1]  (intermediate CA)
    subject = CN=Example Issuing CA        -- equals the issuer above it
    issuer  = CN=Example Root CA

trust anchor information (held by the verifier)
    name       = CN=Example Root CA        -- equals the issuer above it
    public key = held in configuration, not fetched

verify signature on certificate[0].TBSCertificate
       using certificate[1].SubjectPublicKeyInfo
verify signature on certificate[1].TBSCertificate
       using anchor.public key

go deeper

for a junior

Be able to say the two links out loud: the issuer name below equals the subject name above, and the key above verifies the signature below. Then say where the walk stops and why it stops there.

for a middle

Explain that names are a search index and signatures are the evidence, and that a trust anchor enters the process as configured key material rather than as a certificate the verifier checked against anything.

for a senior

Show where this bites in production: several stored candidates sharing one subject name, a verifier that tries one and gives up, and key identifiers that speed a search without deciding it.

for a principal

The question you own is how much of this your estate verifies independently. A fleet that trusts whatever anchor list it was handed at install time has made a trust decision by default rather than by design.

## What a certification path is A certification path is an ordered run of certificates in which each one is signed by the next, ending at something the verifier already trusts. **Nothing inside a certificate stores that run.** A certificate carries only the ingredients a verifier needs to rebuild it: - a `subject` name, saying who this certificate speaks for; - a `SubjectPublicKeyInfo`, carrying the public key bound to that name; - an `issuer` name, naming the authority that signed it; - the issuer's signature over the `TBSCertificate`, the to-be-signed body holding every field above. The path itself is reconstructed, every time, by whoever is checking. ## The two links at every hop Each step upward has to satisfy two independent links, and conflating them is where most confusion about chains begins. **The name link.** The `issuer` field of the certificate you are standing on must equal the `subject` field of the candidate above it. This is *name chaining*, and it is a lookup rule: it tells the verifier which certificate to reach for next. **The signature link.** The public key in that candidate's `SubjectPublicKeyInfo` must verify the issuer's signature over the lower certificate's `TBSCertificate`. This is the link that carries evidence: only a party holding the matching private key could have produced that signature over those exact bytes. | Link | What it compares | What it proves | What it is for | |---|---|---|---| | Name chaining | `issuer` below against `subject` above | nothing on its own | finding the next candidate | | Key identifier hint | `authorityKeyIdentifier` against `subjectKeyIdentifier` | nothing on its own | ordering and narrowing candidates | | Signature | the issuer's signature over `TBSCertificate` | the holder of that key signed this body | the actual evidence | ## Why the names are only an index An `issuer` field is written by whoever generates the certificate. A name costs nothing to copy, so a forged certificate can claim any issuer in the world and the name link will happily match. Everything the name buys the verifier is efficiency: out of a pool of candidate CA certificates, it points at the few worth trying. If the signature over the lower certificate does not verify under a candidate's public key, that candidate is rejected no matter how perfectly the names line up. The two key-identifier extensions work the same way and are worth naming precisely, because they are routinely misread as proof of issuance: 1. `subjectKeyIdentifier` labels the public key inside the certificate that carries it. 2. `authorityKeyIdentifier` in the certificate below says which issuing key signed it. 3. A verifier can match one against the other to shortlist candidates when several certificates share a `subject` name. That is all they do. They are unauthenticated hints sitting inside the same signed body; a certificate whose identifier matches but whose signature fails is rejected exactly like any other. ## Where the walk stops, and why The walk cannot continue forever, so it ends at a **trust anchor** - supplied to the verifier as *trust anchor information*: an authority name, a public key, and the algorithm that key belongs to. The anchor is trusted because of how it reached the verifier's configuration, not because of any signature. Roots are usually distributed as self-signed certificates, whose `issuer` and `subject` are the same name and whose signature verifies under their own key. That self-signature is genuine, but it proves only that whoever assembled the certificate held the matching private key. **Anything can self-sign.** Treating a self-signature as the reason a root is trustworthy inverts the model: the signature is a consistency property, and the trust is a decision made before the certificate was ever presented. ## What a completed run does not establish Reaching an anchor through unbroken name and signature links answers one question - *does this certificate descend from something I trust?* - and no others: - it says nothing about whether any certificate on the path has been withdrawn since issue, which is a separate check with its own mechanisms; - it says nothing about whether the end-entity certificate speaks for the party you actually wanted to reach, which is a separate identity comparison; - it says nothing about whether each certificate is inside its own `notBefore` and `notAfter` window, which the validation step checks against the current time; - it says nothing about whether each issuer was entitled to issue below itself, which the constraint checks cover. A candidate who can state the two links, say which one carries evidence, and say where the walk stops has the spine of the whole subject. Everything else on this branch is a refinement of those three facts.

  • Why is the topmost certificate in a chain not verified by a signature the verifier checks against something above it?
    Because the walk has to stop somewhere. A trust anchor is supplied to the verifier as configured information - an authority name, a public key and its algorithm - and it is trusted because of where it came from, not because of any signature. A root is usually distributed as a self-signed certificate, and a self-signature proves possession of the matching private key while saying nothing about whether that key deserves trust.
  • Two candidate issuer certificates carry the same subject name. How does the verifier tell which one to use?
    It tries them. `authorityKeyIdentifier` in the lower certificate and `subjectKeyIdentifier` in the candidates narrow and order the search, making path building cheaper rather than sounder. Whichever candidate is tried, the signature check decides, and one whose key identifier matches but whose signature fails is rejected like any other. This case is ordinary wherever one CA key has been certified more than once.

A sealed letter of introduction names who vouched for you, but you check the seal against a seal you already hold, not against the name printed inside. The name tells you whose seal to reach for; the seal is the part that convinces you.

saying these in an interview costs you the question

  • Thinks matching issuer and subject names is enough to trust a chain.
  • Says the root certificate is verified by a signature from someone higher.
  • Treats authorityKeyIdentifier as proof of who issued the certificate.
  • Believes a self-signed certificate is trusted because it verifies its own signature.
  • Assumes reaching a trust anchor also proves the peer's name is the one you wanted.