A root CA certificate sits in a file on the host - what makes it a trust anchor to a validator?

This is the precision question behind the whole subject, and it explains a family of failures that otherwise look like implementation whims. ## A certificate is a statement; an anchor is an input A certificate is a signed statement by an issuer: *this name has this public key, over this window, for these uses*. Its validity is something a verifier checks by verifying the issuer's signature. A **trust anchor** is the opposite end of the process. It is the thing the verifier already accepts without checking anybody's signature, because there is nobody above it to check. `RFC 5280` defines what path validation takes as its anchor input - **trust anchor information** - and that consists of: - the **trusted issuer name**; - the **trusted public key algorithm**; - the **trusted public key**; - optionally, the **associated public key parameters**. That is a name and a key, not a document. The specification notes the information may be supplied in the form of a self-signed certificate, which is why stores are full of them - a self-signed certificate is a portable, signed, tamper-evident envelope for exactly those fields. But the envelope is a transport convenience, and different implementations unwrap it to different depths. ## Why the distinction has consequences Once you see that the validator is handed a name and a key, several otherwise puzzling behaviours line up: 1. **The anchor's own validity window.** Path validation as specified starts from the anchor information and does not require checking the anchor certificate's `notBefore`/`notAfter`. An implementation that keeps the anchor as a certificate in a store commonly *does* check it, because that is what it does to every certificate it holds. So a root whose own window has passed can be accepted by one runtime and refused by another on the same host, with no change to anything on the wire. 2. **Extensions carried on the anchor certificate.** `basicConstraints`, `keyUsage` with `keyCertSign`, and above all `nameConstraints` live in the self-signed certificate. A validator that reduced the file to name-and-key has no way to apply them; a validator that retained the certificate can. Constraining an installed anchor is therefore only as effective as the validators that read the constraint. 3. **Two files, one anchor.** Cross-issued copies of the same authority - the same subject name and the same public key, signed differently - are different certificates but the *same* trust anchor information. A store may hold both; a validator handed name-and-key sees one anchor. 4. **Identity is the key, not the file.** Replacing the file with a re-encoded copy changes nothing. Re-keying the authority changes everything, because the key is half the anchor's identity. ## The comparison, laid out | | A root certificate in a file | Trust anchor information | |---|---|---| | What it is | a signed, self-issued document | an input to path validation | | Carries | name, key, validity window, extensions | trusted name, key algorithm, key, optional parameters | | Signature | present and self-verifying | irrelevant; nothing above it signs | | Own validity window | printed in the document | not required to be checked by validation as specified | | Constraints | extensions such as `nameConstraints` may be present | only if the implementation retains and applies them | ## How to use the distinction in practice - When an anchor works in one place and not another, ask what each implementation actually reads out of the file. "Both hosts have the same root installed" does not mean both validators were given the same anchor input. - When you install a **constrained** internal CA, verify the constraint is actually enforced by the specific validators that matter. A constraint that one runtime honours and another ignores is a policy you only half have. - When an authority is re-keyed, treat it as a new anchor. The file name and the subject may be unchanged, and it is still a different trust anchor because the key is different. - When auditing an anchor list, record the key, not just the display name. Two entries with the same friendly name and different keys are two grants of authority. ## The one-line version A store holds files; a validator is handed names and keys. Everything a store *appears* to say beyond "this name with this key may vouch for others" - a window, a constraint, a usage - is only in force if the implementation reading the file chose to carry it through.