Day 25: SANs, AKI, SKI, and pathLenConstraint

Phase 1 · June 7, 2026

Agenda (2–3 hours)

• Read (75 min): RFC 5280 §4.2.1.6 (SAN), §4.2.1.1 (BasicConstraints/pathLen), §4.2.1.2 (SKI), §4.2.1.3 (AKI)
• Study (30 min): How AKI/SKI chain linkage works
• Practice (45 min): Verify AKI/SKI linkage in a real cert chain
• Challenge (30 min): Manual chain verification

Subject Alternative Names (SANs)

SubjectAltName ::= GeneralNames
GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
GeneralName ::= CHOICE {
    otherName                 [0] OtherName,
    rfc822Name                [1] IA5String,     -- email
    dNSName                   [2] IA5String,     -- hostname
    x400Address               [3] ORAddress,
    directoryName             [4] Name,
    ediPartyName              [5] EDIPartyName,
    uniformResourceIdentifier [6] IA5String,     -- URI
    iPAddress                 [7] OCTET STRING,  -- IPv4 (4 bytes) or IPv6 (16 bytes)
    registeredID              [8] OBJECT IDENTIFIER
}

For TLS server certs: dNSName entries are what browsers and TLS stacks validate.
The CN field is not checked for hostnames by RFC 6125 — SANs only.

Wildcard SANs

dNSName: *.example.com matches api.example.com but NOT:

• example.com (no subdomain)
• sub.api.example.com (only one label)
• *.example.com (literal asterisk)

RFC 5280 does not define wildcard semantics — that's left to RFC 6125 and CA/B Forum rules.

For provisioning services: prefer explicit SANs over wildcards.
A wildcard cert issued to a compromised service can impersonate all subdomains.

Authority Key Identifier (AKI)

Links a certificate to its issuer's public key.

AuthorityKeyIdentifier ::= SEQUENCE {
    keyIdentifier [0] KeyIdentifier OPTIONAL,
    ...
}
KeyIdentifier ::= OCTET STRING  -- SHA-1 of issuer's subjectPublicKey

AKI in a cert must match the SKI of its issuing CA cert.
This enables efficient chain building when multiple certs share the same subject DN.

Subject Key Identifier (SKI)

Identifies this certificate's public key.

SubjectKeyIdentifier ::= KeyIdentifier  -- SHA-1 of this cert's subjectPublicKey

CA certs must include SKI (required per RFC 5280 §4.2.1.2 for CA certs).
End-entity certs should include it.

Chain building: validator finds the CA cert whose SKI == leaf cert's AKI.

Practice Exercise

# Extract AKI and SKI from a 3-cert chain
for cert in leaf.pem intermediate.pem root.pem; do
  echo "=== $cert ==="
  openssl x509 -in $cert -noout -text | \
    grep -A3 -E "Subject Key Identifier|Authority Key Identifier"
done

# Verify: leaf AKI should match intermediate SKI
# intermediate AKI should match root SKI
# root AKI == root SKI (self-signed)

Challenge Assignment

Using openssl x509 -noout -text on a real 3-cert chain:

1. Extract the hex value of the SKI for the root CA cert
2. Extract the hex value of the AKI for the intermediate CA cert
3. Verify they match (they should be identical hex strings)
4. Repeat for intermediate SKI → leaf AKI

Write a Rust function using x509-parser that:

• Takes two PEM certs as input (a cert and its alleged issuer)
• Returns true if the cert's AKI matches the issuer's SKI
• This is one step of chain validation

Resources

• RFC 5280 §4.2.1.6: Subject Alternative Name
• RFC 5280 §4.2.1.2: Subject Key Identifier
• RFC 5280 §4.2.1.3: Authority Key Identifier
• RFC 6125: hostname validation rules (SANs vs CN)
• CA/Browser Forum Baseline Requirements: wildcard certificate rules