skip to content

What does marking an X.509 v3 extension critical require of a verifier, and why is basicConstraints marked critical?

level: middleimportance: should knowfreq 52%

answer

  1. a boolean per extension
  2. unknown and critical: stop
  3. unknown and ordinary: carry on
  4. the cA boolean decides authority
  5. narrowing, never widening

basics

~20 s

Critical means a reader that does not recognise the extension must reject the certificate instead of ignoring it. basicConstraints is critical in a CA certificate because its cA boolean decides whether that certificate may act as an issuer at all.

solid answer

~40 s

Every v3 extension carries a `critical` boolean, and it is a fail-closed switch. RFC 5280 requires a certificate-using system that meets a critical extension it does not recognise to **reject the certificate**; an unrecognised extension that is not critical may be ignored. So criticality is the issuer saying "you cannot use this certificate safely unless you understand this constraint." `basicConstraints` is the clearest case: it carries the `cA` boolean, and conforming CAs must include it in CA certificates and mark it critical, because a reader that skipped it could not tell an authority from an ordinary end-entity certificate. `keyUsage` is different in one detail worth knowing — the profile says issuers *should* mark it critical, not must — while `nameConstraints`, when present, must be critical.

code

pseudocode · 13 lines
pseudocode
for each extension in leaf_certificate.extensions:

    if verifier recognises extension.id then
        apply extension            // whether or not it is critical

    else if extension.critical then
        reject certificate         // unknown constraint: fail closed

    else
        ignore extension           // unknown and not critical: carry on
    end if

end for

go deeper

for a junior

Remember that each v3 extension carries a critical flag, and that critical means a reader which does not understand it must refuse the certificate rather than skip the field.

for a middle

Explain the three processing outcomes, and what basicConstraints, keyUsage and extKeyUsage each constrain — including that extended key usage narrows rather than adds.

for a senior

Use criticality to explain why one implementation rejects a certificate another accepts, and be precise about which rules are requirements and which are recommendations.

for a principal

Weigh what marking an in-house extension critical costs: every reader outside your control refuses the certificate, which is the mechanism working as designed.

The `critical` boolean is the smallest field in the extension block and the one that changes a verifier's behaviour most sharply. ## Criticality is a fail-closed switch An extension is an OID, a `critical` boolean and an encoded value. When a certificate-using system processes the extension block, three outcomes are possible: 1. **Recognised** — the system understands the OID and applies the extension's meaning, whether or not it is critical. 2. **Unrecognised and critical** — the system must **reject the certificate**. It has been told there is a constraint it cannot evaluate, so it cannot conclude the certificate is safe to use. 3. **Unrecognised and not critical** — the system may ignore the extension and carry on. That asymmetry is the whole design. A new constraint can be deployed into a world of existing implementations in one of two ways: non-critical, so old readers ignore it and keep working, or critical, so old readers refuse rather than proceed under a rule they cannot see. The issuer chooses, per extension, which failure it prefers. Note what criticality is *not*: it is not a measure of importance or of how security-sensitive an extension is. `authorityKeyIdentifier` is useful and must be non-critical; `subjectAltName` is the identity of the subject and is usually non-critical, because every serious reader already understands it and there is nothing to fail closed about. ## The extensions that constrain what a certificate may be used for | Extension | The question it answers | Typical criticality | What it asserts | |---|---|---|---| | `basicConstraints` | Is this an authority? | Critical, and required in CA certificates | The `cA` boolean, plus `pathLenConstraint` when `cA` is true | | `keyUsage` | What may this key do? | The profile says issuers **should** mark it critical | Bits including `digitalSignature`, `keyEncipherment`, `keyCertSign`, `cRLSign` | | `extKeyUsage` | For which purposes? | Either; if critical, use outside the listed purposes is out of bounds | Purposes such as `id-kp-serverAuth`, `id-kp-clientAuth`, or `anyExtendedKeyUsage` | | `nameConstraints` | Which names may follow? | Must be critical, and only in a CA certificate | The name spaces an authority's subordinates are confined to | Three of these are commonly misread. `extKeyUsage` **narrows**: a certificate with `id-kp-clientAuth` and nothing else has not gained a capability, it has lost the others, and `anyExtendedKeyUsage` exists precisely so an issuer can include the extension for applications that demand one without narrowing anything. `keyUsage` is the field that separates signing data from signing certificates: `digitalSignature` and `keyCertSign` are different bits, and an authority's certificate is the one asserting `keyCertSign` and usually `cRLSign` alongside it. And `pathLenConstraint` is meaningful only where `cA` is true and `keyCertSign` is asserted; the profile bars an issuer from including it otherwise. ## pathLenConstraint as a field Read purely as encoded data, `pathLenConstraint` states the maximum number of non-self-issued intermediate certificates allowed to follow this one. A value of `0` therefore says: this authority may issue end-entity certificates and no further authorities. Whether a given verifier enforces that while building and validating a path is a different subject with its own rules; what the certificate does is *assert the limit*, and a monitor reading certificates can record the assertion without ever walking a path. ## Why basicConstraints is the archetype The historically important failure is easy to state. If a reader ignores `basicConstraints`, it has no field left that distinguishes an ordinary end-entity certificate from an authority. Anyone holding a legitimately issued certificate for one name could then sign certificates for any other name, and the signature would check out. Marking the extension critical closes that from the issuer's side: a reader that does not understand the concept of a CA certificate at all is forced to reject rather than to guess. ## Practical consequences - A certificate rejected "for no visible reason" by one implementation and accepted by another very often carries a critical extension only one of them understands. - Adding a private, organisation-specific extension marked critical will break every reader outside the organisation. That is the intended meaning, and it is rarely the intended outcome. - `keyUsage` marked non-critical is still conforming and its bits still constrain use; a candidate who insists it must be critical is over-promoting a SHOULD to a MUST. - When a certificate profile and an application disagree about what a certificate may do, the encoded answer is in `keyUsage` and `extKeyUsage`, not in the subject line or the file name.

  • Must keyUsage be marked critical?
    No. The profile says a conforming CA **should** mark it critical when it is present, which is a recommendation rather than a requirement. A certificate carrying a non-critical `keyUsage` is still conforming, and the bits still say what the key may be used for.
  • What does pathLenConstraint set to 0 assert?
    That no non-self-issued CA certificate may follow this one — the authority may issue end-entity certificates only. The field is meaningful only when `cA` is true and `keyCertSign` is asserted, and enforcing it during path validation is a separate matter from the assertion itself.
  • Why is it safe to ignore an unrecognised non-critical extension?
    Because the issuer said so. Criticality is reserved for semantics a reader must understand for the certificate to be used safely; marking an extension non-critical is the issuer's judgement that ignoring it cannot make acceptance unsafe.

saying these in an interview costs you the question

  • Reads critical as important and non-critical as cosmetic
  • Says an unknown critical extension can be skipped if everything else validates
  • Claims keyUsage must always be marked critical
  • Thinks basicConstraints only matters on root certificates
  • Says extKeyUsage widens what a certificate may be used for
  • Reads pathLenConstraint as the total certificate count in a chain