While walking a certification path, what does a verifier check in each CA certificate about its authority to issue the next one?

## Entitlement is checked at every hop, not once A signature that verifies proves only that the holder of a key produced it. It says nothing about whether that party was *entitled* to sign a certificate. Path validation therefore checks authority separately, at each certificate above the end-entity, and it reads that authority out of the certificate itself - written there by the issuer above, not decided by the verifier. Three checks carry the weight. **`basicConstraints` with `cA` TRUE.** For version 3 certificates the extension must be present and the boolean set, otherwise the certificate may not issue the one below it. This is what stops an ordinary end-entity certificate from being used as an issuing authority - the single most consequential structural check in the whole algorithm. **`keyUsage` asserting `keyCertSign`.** The extension need not be present, but if it is, the algorithm requires `keyCertSign` to be asserted. A key marked for `digitalSignature` over data, or for `cRLSign` only, cannot sign certificates. The extension can therefore narrow authority but never widen it. **`pathLenConstraint`.** Carried inside `basicConstraints` and meaningful only when `cA` is TRUE, it states the maximum number of non-self-issued intermediate certificates that may follow that certificate on a valid path. ## How the depth counter actually moves The algorithm maintains a `max_path_length` counter, initialised to the path length, and for each certificate it processes: 1. if the certificate is **not self-issued**, the counter is decremented - and if it was already zero, the path is rejected; 2. if the certificate carries a `pathLenConstraint` **smaller** than the current counter, the counter is clamped down to it; 3. a larger `pathLenConstraint` lower down therefore cannot relax a tighter one set higher up. Two values are worth being exact about: | Value in a CA certificate | What it permits below that certificate | |---|---| | `pathLenConstraint` absent | unconstrained depth | | `pathLenConstraint` = 0 | end-entity certificates only, no further CA certificate | | `pathLenConstraint` = 1 | one more subordinate CA, and leaves beneath it | Note also that **self-issued** certificates - those whose `issuer` and `subject` are the same name - do not decrement the counter. That is what lets an authority certify its own new key without consuming depth, and it is distinct from *self-signed*, which is about the signature verifying under the certificate's own key. ## What a violation is evidence of This is the part that separates a candidate who has operated a hierarchy from one who has read about it. `pathLenConstraint` is set by an issuer **above**, and it binds everything beneath. A path rejected on depth is therefore not a client quirk and not a verifier bug: it is evidence that some authority issued a subordinate CA certificate deeper than its own certificate permitted. Every certificate on the path may be individually well formed, correctly signed and comfortably unexpired; the defect is in the *shape* of the hierarchy, and it sits upstream of whatever certificate was handed to you. The practical consequence is that the repair is never at the leaf. Reissuing the end-entity certificate changes nothing. Somebody above has to reissue with a constraint that accommodates the depth, or the delegation below has to be flattened. ## The other limit imposed downward `nameConstraints` restricts names rather than depth. Set in a CA certificate, it carries permitted and excluded subtrees limiting the `subject` and `subjectAltName` values that any certificate beneath it may carry. Three properties matter: - an excluded subtree wins over a permitted one - a name matching an exclusion is invalid regardless of what the permitted set says; - restrictions are stated **per name form**, so a limit written for `dNSName` does not by itself restrain a name of another form such as `iPAddress`; - the constraint binds the whole subtree beneath that certificate, not just the certificate directly below it. That combination is what makes name constraints the sharpest tool available for scoping a delegated authority - and the easiest to set in a way that binds less than the author intended, because the form nobody thought to constrain is the form nobody constrained. ## What to say in an interview Name the three per-hop checks, say which two live in `basicConstraints`, describe the counter's decrement-then-clamp behaviour, and finish with the diagnosis: a depth rejection points at the issuing hierarchy, not at the certificate in front of you.