Day 24: Core Extensions — BasicConstraints, KeyUsage, EKU

Phase 1 · June 6, 2026

Agenda (2–3 hours)

• Read (75 min): RFC 5280 §4.2.1.1–4.2.1.3 (BasicConstraints, SKI, AKI), §4.2.1.12 (EKU), §4.2.1.3 (KeyUsage)
• Study (45 min): What each extension controls and why it matters
• Practice (30 min): Compare extensions across a real cert chain
• Challenge (30 min): Minimum extension set analysis

Extensions: Critical vs Non-Critical

Extension ::= SEQUENCE {
    extnID   OBJECT IDENTIFIER,
    critical BOOLEAN DEFAULT FALSE,
    extnValue OCTET STRING  -- DER-encoded extension value
}

Critical extension: if a validator doesn't understand it, it must reject the cert.
Non-critical extension: if a validator doesn't understand it, it may ignore it.

If an extension is marked critical but the validator doesn't implement it → chain validation fails.
This is how PKIX enforces security-critical constraints.

BasicConstraints

BasicConstraints ::= SEQUENCE {
    cA                  BOOLEAN DEFAULT FALSE,
    pathLenConstraint   INTEGER (0..MAX) OPTIONAL
}

cA = TRUE: This certificate is a CA and may sign other certificates.
cA = FALSE (or absent): This is an end-entity certificate. Must not sign certs.

pathLenConstraint: Maximum number of intermediate CAs below this CA.

• Root CA with pathLen=1: can have one intermediate, which issues leaf certs
• Root CA with pathLen=0: its issued certs are leaf certs only (no sub-CAs)

Should be critical on CA certificates.

KeyUsage

KeyUsage ::= BIT STRING {
    digitalSignature  (0),  -- sign data/handshakes
    contentCommitment (1),  -- non-repudiation signing (old: nonRepudiation)
    keyEncipherment   (2),  -- encrypt symmetric keys (RSA key transport — TLS 1.2)
    dataEncipherment  (3),  -- encrypt bulk data directly (rare)
    keyAgreement      (4),  -- ECDH
    keyCertSign       (5),  -- sign certificates (CA cert only)
    cRLSign           (6),  -- sign CRLs
    encipherOnly      (7),  -- combined with keyAgreement
    decipherOnly      (8)   -- combined with keyAgreement
}

CA certificate: must have keyCertSign; usually also cRLSign.
TLS server leaf cert (ECDHE): needs digitalSignature.
Should be critical.

ExtendedKeyUsage

Refines the purpose of the key beyond KeyUsage:

ExtendedKeyUsage ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId

Practice Exercise

# Download and inspect a 3-cert chain
openssl s_client -connect amazon.com:443 -showcerts 2>/dev/null > /tmp/chain.pem

# Split certs and inspect extensions of each
csplit -z /tmp/chain.pem '/-----BEGIN CERTIFICATE-----/' '{*}'
for f in xx*; do
  echo "=== $f ===" && openssl x509 -in $f -noout -text | \
    grep -A3 -E "Basic Constraints|Key Usage|Extended Key Usage"
done

Challenge Assignment

For each of these four certificate types, identify the minimum necessary extensions:

Then: what happens if keyCertSign is set on a leaf cert but cA=FALSE?
Does RFC 5280 allow this? What should validators do? Check §4.2.1.9.

Resources

• RFC 5280 §4.2.1.1: Basic Constraints
• RFC 5280 §4.2.1.3: Key Usage
• RFC 5280 §4.2.1.12: Extended Key Usage
• RFC 5280 §4.2 overview: extension processing rules