How can one end-entity certificate have two valid certification paths, ending at two different trust anchors, at the same moment?

## What a cross-certificate actually is A cross-certificate is an ordinary certificate with an unusual subject: one certification authority issues it over *another authority's* name and public key. Nothing exotic is happening in the encoding. The `subject` is the second authority's name, the `SubjectPublicKeyInfo` holds that authority's existing public key, and the signature is made by the first authority's key. The crucial property follows from that: **the key being certified does not change.** Every certificate that authority has already issued was signed with the same private key, so every one of them still verifies. A new certificate has appeared *above* the authority, and nothing below it has moved. That is what makes two simultaneous paths possible. Given one leaf: - a verifier holding the newer anchor walks leaf, issuing CA, done - it has already reached something it trusts; - a verifier holding only the older anchor walks leaf, issuing CA, cross-certificate over the newer root, and arrives at the older anchor. Both runs consist of unbroken name and signature links ending at a trust anchor. Both are valid. They are different lengths, they end in different places, and they exist at the same instant. ## Why hierarchies are transitioned this way The problem an anchor transition has to solve is not technical, it is demographic: **the verifiers you cannot reach.** Anchor lists on shipped devices, in pinned images and inside long-lived installations update on their own schedule, or never. A leaf that reaches only the new anchor is worthless on every one of them. A cross-certificate lets both populations validate the same leaf, with no change required at the leaf and no reissuance anywhere below: | Verifier population | Path it builds | What the operator had to do | |---|---|---| | Holds the newer anchor | short, stops at the new root | nothing | | Holds only the older anchor | longer, through the cross-certificate | nothing | | Holds both | either, depending on its search | nothing | The cost is that this arrangement runs for as long as the old population survives - often years - and during that time the operator is maintaining two truths about the same hierarchy. ## The failure this produces Because a path belongs to the verifier and not to the certificate, verifiers disagree. The characteristic incident looks like this: 1. A leaf and the certificates supplied with it are identical everywhere. 2. Some clients validate, others report a trust failure, and the split does not follow anything obvious. 3. The split actually follows which anchors each verifier holds and how hard it searches after a first failure. The sharpest version arrives when a widely held older root finally reaches the end of its own validity window. A verifier that considers only the supplied ordering, and that enforces the expiry of a certificate representing that old root, now finds an expired certificate on the one path it looked at, and rejects. A verifier that keeps searching finds the shorter path to the newer anchor and accepts. Whether a stored anchor's own validity window is enforced at all varies between implementations, which is exactly why this failure appears unevenly rather than everywhere at once. ## What the two paths do and do not prove Both paths establish the same thing: that the leaf's name and public key were bound by a run of signatures ending at something the verifier chose to trust. Neither is stronger. What differs is *who vouched at the top*, and therefore which verifiers can check it at all. A leaf reachable from two anchors is trusted by the union of the two populations - broader reach, not deeper assurance. A few precise distinctions are worth holding: - a cross-certificate is **not** a reissue of the leaf, and the leaf is unaware of it; - it is **not** a duplicate of the other authority's certificate, because the issuer and the signature differ; - it does **not** merge two hierarchies into one - it adds one edge between them; - and the alternative path it creates is only usable by a verifier that actually looks for it. ## The operational takeaway When you are asked to diagnose "it works here and not there" on identical certificates, cross-signing is one of the first things to consider, and the investigation is about the verifiers rather than the certificate. Ask what anchors each population holds, what candidates each had available, and whether each keeps searching after a rejection. Changing the leaf, which is the instinctive first move, addresses none of those.