skip to content

Why does path building fail when a verifier holds the trust anchor and the end-entity certificate but no intermediate?

level: middleimportance: should knowfreq 58%

answer

  1. the hole is in the middle
  2. no candidate matches the leaf's issuer
  3. the anchor signed the intermediate, not the leaf
  4. authorityInfoAccess points at the issuer
  5. id-ad-caIssuers needs a network to help

basics

~20 s

Nothing joins the two. An intermediate CA signed the end-entity certificate, not the anchor, so with that intermediate absent no candidate has a subject matching the leaf's issuer and a key that verifies its signature.

solid answer

~50 s

The anchor did not sign the end-entity certificate - a subordinate CA did - so holding both ends of the hierarchy still leaves a hole in the middle. Path building looks for a candidate whose `subject` equals the leaf's `issuer` and whose public key verifies the signature over the leaf's `TBSCertificate`; with no such candidate in its pool the search returns nothing and validation never runs at all. The online repair is `authorityInfoAccess` carrying the `id-ad-caIssuers` access method, an extension in the leaf that points at a location from which the issuing CA's certificate can be retrieved. A verifier with outbound network access that implements the fetch heals the gap quietly; one that is offline, or that does not implement it, cannot - which is why the same certificate works on one client and fails on another.

code

http · 8 lines
http
GET /ca/example-issuing-ca.cer HTTP/1.1
Host: aia.example-ca.test

HTTP/1.1 200 OK
Content-Type: application/pkix-cert
Content-Length: 1193

[DER-encoded issuing CA certificate]

go deeper

for a junior

Remember which certificate signed which. The anchor signed the intermediate and the intermediate signed the end-entity certificate, so an absent middle certificate leaves nothing for the verifier to check the leaf against.

for a middle

Explain the search that fails: no candidate has a subject equal to the leaf's issuer with a key that verifies its signature, so no path exists and validation is never reached.

for a senior

This is the failure that reproduces on one client and not another. Be able to say why - a cached intermediate, an issuer-certificate fetch, or neither - and to test it from a host with nothing cached.

for a principal

Decide whether your estate may depend on an online repair at all. Verifiers without egress are a design constraint rather than an edge case, and they change what 'correctly deployed' has to mean.

## The hole is in the middle, not at either end The intuition that trips people is that holding "the certificate and the root" ought to be enough. It is not, because the root's key never touched the end-entity certificate. In a two-level hierarchy the anchor signs a subordinate CA certificate, and that subordinate CA's key signs the leaf. A verifier checking the leaf needs the key that actually signed it, and that key lives in the subordinate CA certificate - the one it does not have. Concretely, the search asks for a candidate that satisfies both hop links at once: - a `subject` equal to the leaf's `issuer`, and - a `SubjectPublicKeyInfo` whose key verifies the issuer signature over the leaf's `TBSCertificate`. The anchor satisfies neither. Its name is not the leaf's issuer name, and its key does not verify that signature. So the search terminates with no prospective path, and **validation never runs**. This is the distinction that makes the error message readable: there is no verdict on the certificate, because there was never a path to pass a verdict on. ## The pointer that repairs it RFC 5280 defines `authorityInfoAccess`, a non-critical extension listing places a verifier can go for information about the issuer. One of its access methods, `id-ad-caIssuers`, names a location from which the issuing CA's certificate can be retrieved - in practice an HTTP URI serving the issuer's certificate. A verifier that follows it gets the missing candidate, completes the run, and validates. That repair is genuinely useful and genuinely unreliable: | Property | What it means in practice | |---|---| | The extension is optional | a certificate may carry no pointer at all | | Following it is not required | a conforming verifier may ignore it entirely | | It needs egress | an offline verifier cannot use it, however well implemented | | It costs a round trip | the fetch happens inside connection setup, so a slow endpoint becomes a slow connection | | It may be cached | the next check on that host may succeed without any fetch, hiding the defect | ## Why the same certificate behaves differently on two machines This is the mechanism behind the most commonly misdiagnosed trust failure there is, and every branch of it is about *the verifier's candidate pool*, not about the certificate: 1. A verifier that has checked another certificate from the same authority may have the intermediate cached, and succeeds with no fetch and no complaint. 2. A verifier with egress and support for the `id-ad-caIssuers` fetch retrieves the intermediate on demand and succeeds a little more slowly. 3. A verifier with neither - an embedded reader, a locked-down build agent, a host with no outbound route - has no way to obtain the missing certificate and fails every time. All three are looking at identical certificate bytes. "It works on my machine" is, here, a precise technical statement about what that machine had cached. ## The offline case as the design constraint A device that must decide from what it is handed - a reader with an anchor list burned in at installation and no network - has no repair available at all. For that class of verifier there is exactly one workable arrangement: **every certificate needed to reach an anchor must be in the candidate pool at the moment of the check.** Treating the online fetch as the deployment plan makes correctness depend on a network the verifier may not have, and the failure surfaces at the worst possible moment, in the field, on the devices least able to report why. ## Fixing it, and the fix that is not one The legitimate repair is to make the intermediate available to the verifier - supplied alongside the leaf, or pre-loaded into the candidate pool the verifier searches. A tempting alternative is to install the intermediate into the anchor list so it becomes an anchor in its own right. That does make the immediate symptom disappear, and it is the wrong fix: - it promotes a subordinate CA to the status of something trusted unconditionally; - it discards the constraints the real anchor imposed on everything beneath it; - it makes that machine's behaviour differ permanently from every other verifier; - and it hides the actual defect, which is a deployment that does not supply a complete candidate set. The diagnostic instinct worth having is the split from the previous idea: ask whether you are looking at a **build** failure (nothing to check - a certificate is missing) or a **validation** verdict (something was checked and failed). A missing intermediate is always the first.

  • If `authorityInfoAccess` can repair a missing intermediate, why is relying on it a poor deployment plan?
    Because the repair is optional on both sides and impossible for some verifiers. The extension need not be present, a verifier need not follow it, and one with no outbound route - an embedded reader, a locked-down agent, an isolated host - cannot. The fetch also adds a network round trip inside connection setup, so a slow or unreachable issuer endpoint turns a certificate problem into a latency problem.
  • Can a verifier still build a path when its candidate pool holds more certificates than it needs?
    Yes, and that is the ordinary case. Extra, unrelated or even expired candidates do not by themselves break the search; they enlarge it. Validation runs over one prospective path, so candidates that never appear in the accepted path are simply never processed. The costs are search time and, in a verifier that tries only the first ordering it assembles, the risk that the run it picks is not the one that would validate.
  • How do you tell a missing intermediate from an expired certificate without guessing?
    By which of the two jobs failed. A missing intermediate is a path-building failure: no run of certificates could be assembled, so nothing was ever checked and no verdict exists. An expiry is a validation verdict: a complete path was assembled and one certificate on it fell outside its `notBefore` and `notAfter` window at the current time. The two need opposite fixes.

saying these in an interview costs you the question

  • Says the anchor can verify the leaf directly because both are present.
  • Blames the anchor list when the certificate that is missing is an intermediate.
  • Assumes every verifier fetches a missing issuer certificate automatically.
  • Thinks installing the intermediate as an anchor is the correct fix.
  • Treats a path-building failure and an expired certificate as the same error.