🚫Module 09 — Revocation: CRL, OCSP & Why It's Broken

=== the ledger before ===
V	261122052744Z		0A15C224EBD2EAB834BB6E87BE21A71E1DF7E26A	unknown	/CN=a.test
V	261122052744Z		63777A2531F69CF6C85A6C5B5DC374A653968A40	unknown	/CN=b.test
V	261122052744Z		5A89C90E462B572355643F3AD716B69378A4C51E	unknown	/CN=c.test

=== revoke b.test ===
Revoking Certificate 63777A2531F69CF6C85A6C5B5DC374A653968A40.
Database updated

=== the ledger after ===
V	261122052744Z		0A15C224EBD2EAB834BB6E87BE21A71E1DF7E26A	unknown	/CN=a.test
R	261122052744Z	260824052817Z,keyCompromise	63777A2531F69CF6C85A6C5B5DC374A653968A40	unknown	/CN=b.test
V	261122052744Z		5A89C90E462B572355643F3AD716B69378A4C51E	unknown	/CN=c.test

What to read out of this — compare the middle line before and after.

• Field 1 changed from V to R. That is the revocation.
• Field 3 went from empty to 260824052817Z,keyCompromise — the revocation timestamp and the reason. Module 05 (B2.2) predicted exactly this, and here it is.
• Nothing else changed. The certificate file b.crt is byte-for-byte identical. You cannot revoke a certificate by editing it — the signature would break. Revocation is a statement the CA makes about the certificate, held entirely on the CA's side.
• This is why revocation is hard. The certificate in the attacker's hands is unchanged and still perfectly valid-looking. The only way anyone learns otherwise is by asking the CA.

🔑 The reason codes matter more than people think. -crl_reason accepts: unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL.

keyCompromise is the serious one. It means the private key leaked. Some clients and audit processes treat it differently from superseded — which just means "we replaced this one" and is what a routine reissue should use. Marking a routine replacement as keyCompromise triggers alarm that is not warranted; marking a real leak as superseded hides one that is.

You tell the CA, and the CA records it. With OpenSSL that is openssl ca -revoke cert.crt -crl_reason <reason>, which changes that certificate's status in index.txt from V to R and writes the revocation date and reason.

The certificate itself does not change and cannot change — editing it would break the signature. Revocation is a statement the CA makes about the certificate, held on the CA's side. The copy in an attacker's hands is byte-identical and still looks perfectly valid.

That asymmetry is the whole difficulty: the only way a client learns about revocation is by asking the CA, either by downloading a CRL or by querying OCSP.

The detail worth adding: choose the reason code deliberately. keyCompromise means the private key leaked and is treated seriously by audit processes; superseded means a routine replacement. Using the wrong one either raises a false alarm or hides a real incident.

Certificate Revocation List (CRL):
        Version 2 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN = Revocation Lab CA
        Last Update: Aug 24 05:28:17 2026 GMT
        Next Update: Aug 31 05:28:17 2026 GMT
        CRL extensions:
            X509v3 CRL Number:
                4096
Revoked Certificates:
    Serial Number: 63777A2531F69CF6C85A6C5B5DC374A653968A40
        Revocation Date: Aug 24 05:28:17 2026 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Key Compromise

-rw------- 1 zaeem zaeem 638 Aug 24 05:28 ca.crl

What to read out of this.

• Last Update and Next Update — seven days apart, from default_crl_days=7. This is the freshness problem, printed in the file. A client that fetched this CRL on Monday will not learn about a Tuesday revocation until it refetches. Public CAs typically publish every few hours to a few days, so there is always a window in which a revoked certificate still works.
• It lists only serial numbers, not names. Revocation is identified by (issuer, serial), exactly as Module 03 (A2) said. That also means a CRL leaks very little — you cannot tell from it which sites were revoked without cross-referencing.
• CRL Number: 4096 — the counter from db/crlnumber, which started at 1000 in hex. It stops an attacker replaying an older CRL that does not yet contain a revocation.
• 638 bytes for one revoked certificate. Small. Now multiply: a large public CA has millions of unexpired certificates, and every revocation stays on the list until the certificate would have expired anyway. Real CRLs have reached tens of megabytes.
• The CRL is signed by the CA. It has to be, or an attacker could publish an empty one. That is also why the CA needs cRLSign in its Key Usage (Module 03, C3).

=== 1. verify the REVOKED certificate, the normal way ===
b.crt: OK

=== 2. the same certificate, this time ASKING about revocation ===
CN = b.test
error 23 at 0 depth lookup: certificate revoked
error b.crt: verification failed

=== 3. a certificate that was NOT revoked ===
a.crt: OK

=== 4. asking about revocation with NO CRL available ===
CN = a.test
error 3 at 0 depth lookup: unable to get certificate CRL
error a.crt: verification failed

What to read out of this — blocks 1 and 4 are the two halves of the problem.

Block 1: b.crt: OK. A revoked certificate passed verification, cleanly, with no warning. Because revocation checking is not on by default — you have to ask for it with -crl_check. Every chain check you have run since Module 05 has silently skipped this gate.

Block 4: error 3: unable to get certificate CRL. A perfectly good certificate failed, purely because the CRL was not available. That is hard-fail behaviour: no revocation information means refuse.

Put those two together and you have the entire dilemma:

• Do not check → revoked certificates work forever. (Block 1)
• Check and hard-fail → the CA's availability becomes your site's availability. Every CRL server outage becomes a global internet outage. (Block 4)
• Check and soft-fail → an attacker simply blocks the CRL fetch, and you are back to block 1.

🔑 Browsers chose the third option, and Part B1 explains why that choice made revocation ornamental rather than protective.

Two new error codes for your table (Modules 05 and 07): 23 certificate revoked — revocation confirmed. 3 unable to get certificate CRL — could not check, and this configuration refuses rather than guesses.

A Certificate Revocation List — a signed list of the serial numbers a CA has revoked, published at the URL in the certificate's crlDistributionPoints extension. It carries Last Update and Next Update timestamps, and a CRL Number that increments so an old CRL cannot be replayed.

A client fetches it, caches it until Next Update, and checks whether the certificate's serial appears.

The three problems, and they are all structural:

1. Freshness. A CRL is a snapshot. Between publications there is a window in which a revoked certificate still works — hours to days for a public CA.
2. Size. Every revocation stays listed until the certificate would have expired anyway, so CRLs for large CAs have reached tens of megabytes. Downloading that on a mobile connection to load one page is not viable.
3. Availability. If the CRL cannot be fetched, the client must choose between refusing a good certificate or ignoring revocation entirely.

What is worth knowing about 2026: CRLs have made a comeback. Let's Encrypt shut down its OCSP responders in August 2025 and moved to CRLs, and browsers now consume CRLs centrally rather than per-client — Firefox's CRLite being the clearest example. The mechanism did not change; who downloads it did.

A CA that still runs OCSP:

Authority Information Access:
    OCSP - URI:http://oneocsp.microsoft.com/ocsp
    CA Issuers - URI:http://www.microsoft.com/pkiops/certs/...crt
X509v3 CRL Distribution Points:
    Full Name:
      URI:http://www.microsoft.com/pkiops/crl/...crl

A Let's Encrypt certificate issued after May 2025:

Authority Information Access:
    CA Issuers - URI:http://e7.i.lencr.org/

What to read out of this — look at what is missing from the second one.

• No OCSP - URI line at all. Let's Encrypt removed OCSP URLs from newly issued certificates on 7 May 2025 and shut down its OCSP responders on 6 August 2025.
• And no crlDistributionPoints either. That surprises people. Let's Encrypt publishes CRLs, but does not point at them from the leaf — because the consumers are browser vendors building aggregated revocation data, not individual clients. The CRLs are fetched centrally by Mozilla and Google, not by your laptop.
• CA Issuers is still there, because that is the AIA chasing URL from Module 03 (C5) and has nothing to do with revocation.
• The first certificate has both — many enterprise and commercial CAs still publish OCSP and CRL URLs, and will for years.

🔑 This is the single clearest signal of where revocation has gone. The world's largest CA — by a wide margin — issues certificates with no revocation URL of any kind on them. It concluded that per-client revocation checking was not worth the privacy cost and the operational expense, and that browsers had already stopped relying on it.

⚠️ If you are behind a TLS-inspecting proxy (Module 03, B1.1) you will see the proxy's re-issued certificate instead, which may have quite different extensions. Check the issuer first.

A CRL is a bulk download of every revoked serial from a CA; OCSP is a query about one certificate. The client finds the OCSP URL in the certificate's authorityInfoAccess extension and asks the responder, which replies good, revoked or unknown — signed, so it cannot be forged.

OCSP looks strictly better: a few hundred bytes instead of megabytes, and always current. Its two problems turned out to be worse than the CRL's:

1. Privacy. The client tells the CA which site it is visiting, from which IP, every time. The CA becomes an unintentional log of everyone's browsing. This is the reason Let's Encrypt gave for shutting its responders down.
2. Latency. It is a blocking round trip in the middle of connection setup, to a third party you do not control.

The 2026 answer to "which should I use": neither, per-client. OCSP is being retired — Let's Encrypt removed OCSP URLs from certificates in May 2025 and shut its responders down in August 2025. Browsers moved to aggregated, locally-stored revocation data (Firefox's CRLite, Chrome's CRLSets) built from CRLs fetched centrally. OCSP stapling remains useful for privacy and latency, but as Module 08 noted, it does not make revocation enforceable.

=== curl against a REVOKED certificate, trusting the CA ===
HTTP 200

=== and with curl asked to check revocation ===
curl: (60) SSL certificate problem: certificate revoked

What to read out of this.

• HTTP 200 against a certificate you revoked five minutes ago. curl trusted the CA, validated the chain, checked the dates, matched the hostname — and never asked whether the certificate was still valid. Revocation checking is off by default in curl, as it is in most clients.
• With --crlfile it fails correctly. The mechanism works perfectly. Nobody uses it.
• Notice what --crlfile requires: you had to already have the CRL, locally, as a file. curl will not go and fetch it from crlDistributionPoints for you. So making this work in production means building your own CRL distribution — which is precisely the effort nobody wants to spend.

🔑 This exercise is the module in miniature. The cryptography is fine. The protocol is fine. The default is off, and turning it on is somebody's job that nobody is doing.

💡 Your browser behaves differently again: it will not consult this CRL at all, and will instead check its own aggregated revocation data (Part C2) — which knows nothing about your private lab CA. A private CA gets no revocation support from browsers whatsoever. That is Part D's problem.

When a client cannot obtain revocation information — the responder is unreachable, times out, or returns an error — soft-fail means it proceeds with the connection anyway. Hard-fail means it refuses.

Browsers use soft-fail, and had to. Under hard-fail, any CA whose OCSP responder is slow or down takes a large fraction of the web offline with it, and the internet's availability cannot depend on every CA's infrastructure being perfect.

But soft-fail makes revocation ineffective against a real attacker. Anyone in a position to exploit a revoked certificate — on the network path, or holding a stolen key — is also in a position to block the revocation check. Drop those packets and the client's own policy accepts the certificate.

The framing that lands: soft-fail means revocation stops attackers who are not trying. It is a genuine dilemma rather than an oversight, and the industry's response was not to fix soft-fail but to stop depending on revocation — hence aggregated browser revocation data, and certificate lifetimes falling to 47 days.

Two reasons, and they said so publicly.

Privacy. With OCSP, the CA learns which website is being visited from which IP address, on every connection. Let's Encrypt's own wording is that the CA "immediately becomes aware of which website is being visited from that visitor's particular IP address." That makes the CA an unintended log of a large share of the web's browsing, which it never wanted, cannot safely retain, and could be compelled to disclose.

Cost. Running responders at their scale consumed resources they judged better spent elsewhere — and browsers had largely stopped depending on OCSP anyway.

The timeline: Must-Staple requests rejected from 30 January 2025, OCSP URLs removed from certificates on 7 May 2025, responders shut down on 6 August 2025.

What replaced it: CRLs, but consumed centrally by browser vendors rather than by individual clients. Notably Let's Encrypt certificates now carry no revocation URL at all — neither OCSP nor CRL — because the intended consumer is Mozilla and Google's aggregation pipelines, not your laptop.

The general point worth making: CRLs and OCSP failed for opposite reasons — OCSP was small but leaked, CRLs were private but enormous. Neither could be fixed without turning into the other, so the fix was to change who downloads them.

1.3.6.1.5.5.7.1.24:
    0...

What to read out of this.

• 1.3.6.1.5.5.7.1.24 is the TLS Feature extension from RFC 7633. The value 30:03:02:01:05 is DER for a sequence containing the integer 5, which is the TLS extension number for status_request — OCSP stapling.
• So the certificate is saying: "I will always be served with a stapled OCSP response. If one is missing, refuse me."
• OpenSSL prints it as a raw OID because it does not have a friendly name for it — a fair indication of how rare it is.
• You have just created a certificate that would take your own site down the moment stapling failed. That is not a criticism of the design; it is the design. It is why adoption never happened.

🔑 The lesson generalises well beyond TLS. Must-Staple is a security control that works exactly as intended and was rejected because the failure mode was worse than the threat. Operators would rather accept a small, hard-to-exploit risk than a mechanism that can take the site down. Being able to reason about that trade-off out loud is worth more in an interview than knowing the OID.

Not by asking at connection time. They ship aggregated revocation data to the client in advance and check it locally.

Firefox uses CRLite, default since Firefox 137: Mozilla fetches every CA's CRLs centrally, cross-references Certificate Transparency logs, and compresses all known revocations into a compact set-membership filter — about a 4 MB snapshot every 45 days plus roughly 300 kB of daily deltas, refreshed every 12 hours. Mozilla describes it as a thousand times more bandwidth-efficient than daily CRL downloads.

Chrome uses CRLSets, a much smaller curated list covering roughly 1% of revocations — high-priority ones — pushed through the component updater.

Why this is better: it is fast, entirely offline, perfectly private (nothing is asked, so nothing is logged), and it cannot be blocked by an attacker on the path, which finally escapes soft-fail.

The trade-off: it depends on Certificate Transparency to be complete, and it is controlled by the browser vendor. It also means a private CA gets no browser revocation support at all — internal CAs are not in CT logs and are not aggregated by anyone, so internal revocation has to be handled by other means.

letsencrypt.org           90 days total lifetime
www.google.com            90 days total lifetime
www.microsoft.com         91 days total lifetime

What to read out of this.

• Everyone is already at about 90 days, well under the 200-day cap that took effect in March 2026. The large operators went short voluntarily, years before they were required to — because they had automated renewal and there was no reason not to.
• 90 days is the Let's Encrypt default and has become the industry norm. Google has been issuing 90-day certificates for years.
• The date -d arithmetic is Linux-only — BSD and macOS need date -j -f. Same portability trap as Module 03 (A3.1).

🔑 The thing to notice: nobody at this scale is anywhere near the maximum. The regulatory cap is chasing behaviour that automated operators adopted willingly. The organisations that will be hurt by 47 days in 2029 are the ones still renewing by hand — and that is deliberate pressure, not an accident.

💡 Let's Encrypt now also offers 6-day certificates. At that lifetime revocation is genuinely irrelevant: a compromised certificate expires before most CRLs would even have listed it.

Because revocation does not work, and shortening lifetimes is the alternative.

Revocation fails for structural reasons: CRLs are stale and enormous, OCSP leaks browsing history and adds latency, and both soft-fail — so an attacker who can use a revoked certificate can also block the check. Must-Staple was the honest fix and nobody adopted it, because the failure mode took sites offline.

If you cannot reliably withdraw a certificate, the next best thing is to ensure it stops working on its own, soon. The CA/Browser Forum schedule is 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. At 47 days, a compromised certificate's remaining life is shorter than the refresh interval of many CRLs.

The second effect, which is arguably the point: short lifetimes force automation, and automation removes the manual steps where outages come from. The industry is deliberately making manual certificate management impossible.

The judgement to show: shorter lifetimes trade a rare catastrophic risk for a frequent routine operation. That is a good trade only if the routine operation is automated. For a team renewing by hand it makes things strictly worse — which is exactly the pressure intended.

=== 1. regenerate the CRL ===
lastUpdate=Aug 24 05:28:17 2026 GMT
nextUpdate=Aug 31 05:28:17 2026 GMT

=== 2. publish it as DER too ===
-rw------- 1 zaeem zaeem 638 Aug 24 05:28 ca.crl
-rw------- 1 zaeem zaeem 431 Aug 24 05:31 ca.crl.der

=== 3. a client that actually enforces it ===
  a.test:      a.crt: OK
  b.test:      error b.crt: verification failed
  c.test:      c.crt: OK

=== 4. is the CRL stale? ===
  fresh until Aug 31 05:28:17 2026 GMT

What to read out of this.

• DER is 431 bytes against PEM's 638 — the Base64 overhead from Module 02 (B2), on a file that gets fetched constantly. CRLs are conventionally published as DER over HTTP, and crlDistributionPoints URLs usually end in .crl meaning DER. Publishing PEM there is a common mistake that some clients silently fail on.
• Only b.test failed, and it failed because you revoked it. The mechanism works exactly as designed.
• Check 4 is the one that will bite you. A CRL past its nextUpdate is treated as absent, and any client configured to hard-fail then rejects every certificate from that CA. Your entire internal estate goes down because a cron job did not run.

⚠️ This is the real operational risk of internal revocation, and it is worth stating plainly: a stale CRL is more likely to cause an outage than a revoked certificate is to cause a breach. So:

• Regenerate well before nextUpdate — if the CRL is valid for 7 days, regenerate daily.
• Monitor the published CRL's nextUpdate, not just the fact that the file exists.
• Publish to somewhere at least as available as the services depending on it.

🔑 The full internal revocation flow, for reference:

# revoke
openssl ca -config ca.cnf -revoke bad.crt -crl_reason keyCompromise
# regenerate and publish (cron, daily)
openssl ca -config ca.cnf -gencrl -out /var/www/crl/ca.crl.pem
openssl crl -in /var/www/crl/ca.crl.pem -outform DER -out /var/www/crl/ca.crl
# verify what you published
openssl crl -in /var/www/crl/ca.crl -inform DER -noout -nextupdate

=== step 1-2: NEW key, NEW certificate ===
Database updated
=== confirm the new pair actually matches ===
  MATCH - safe to deploy

=== step 4: ONLY NOW revoke the old one ===
Revoking Certificate 5A89C90E462B572355643F3AD716B69378A4C51E.

=== the result ===
  old c.crt : error c.crt: verification failed
  new c.crt : c-new.crt: OK
  revoked certificates in the ledger: 2

What to read out of this.

• A new key, not the old one. This is the step people skip under pressure — reissuing with the same key means the attacker still holds a working key for the new certificate. Reissuing on a compromised key achieves nothing.
• The key↔certificate check happened before deployment, not after. Module 04 (D2.1)'s gate, in an incident where you least want a second surprise.
• The old certificate now fails and the new one passes, on a client that actually enforces revocation. On a browser against a public CA it might well not — which is the whole point of Part B.
• Two revoked certificates in the ledger, b from earlier and c now. The ledger is the audit trail: what was revoked, when, and why.

🔑 The sentence worth having ready: "I would replace before revoking, with a fresh key, because revocation may not reach clients but replacement definitely ends the exposure. Then revoke, then fix the source of the leak."

Now imagine this at 500 hosts. Every step above needs to be automatable, because doing it by hand across 500 hosts during an incident is where mistakes happen. This is the strongest argument for ACME and short lifetimes that has nothing to do with expiry: when a key leaks, you want reissuing everything to be a routine operation you have already performed a thousand times — not an emergency procedure nobody has rehearsed.

Replace first, revoke second — and the order matters more than people expect.

1. Generate a brand-new key. Not the same one. Reissuing a certificate on a compromised key achieves nothing, and it is the step most often skipped under pressure.
2. Issue a new certificate and verify the key↔certificate match before touching anything.
3. Deploy it everywhere and reload, confirming on the wire rather than on disk.
4. Then revoke the old certificate, with reason keyCompromise.
5. Fix the source. Git history — permanent, so the key is burned regardless. Backups, container image layers, log aggregation, config-management repos. And check whether the same key was reused on other hosts.

Why revocation is last: it is the weakest control in that list. On the public internet it soft-fails, so it may protect nobody. Deploying the replacement is what actually ends the exposure. Revoking first takes your service down while achieving little.

The scale point worth adding: every one of those steps needs to be automatable, because doing it by hand across a fleet during an incident is where the real mistakes happen. That is an argument for ACME that has nothing to do with expiry — when a key leaks you want mass reissuance to be a routine operation you have already done a thousand times.

Usually no. If the old certificate is simply being superseded and the key was never exposed, let it expire. Revoking it adds an entry to the CRL until its original expiry date, which grows the CRL for no security benefit.

Worse, revoking early is actively risky: if the old certificate is still deployed anywhere you have forgotten — a second load balancer, a health-check endpoint, a container image — you have just caused an outage on any client that does enforce revocation.

Revoke when the key may have been exposed, or when the certificate was mis-issued. For public certificates, mis-issuance is not optional: the CA/Browser Forum requires revocation within five days, which is what caused the mass revocations in the 2019 serial-number-entropy incident (Module 03, A2.1) — certificates that were perfectly safe but non-compliant.

The nuance worth voicing: with 47-day lifetimes arriving in 2029, "just let it expire" becomes a much stronger answer than it used to be. That is the whole design intent.

mkdir -p ~/tls-lab/m09/capstone && cd ~/tls-lab/m09/capstone
umask 077
mkdir -p certs db && touch db/index.txt
openssl rand -hex 8 > db/serial && echo 1000 > db/crlnumber

cat > ca.cnf <<'EOF'
[ca]
default_ca=CA
[CA]
dir=.
database=$dir/db/index.txt
serial=$dir/db/serial
crlnumber=$dir/db/crlnumber
new_certs_dir=$dir/certs
certificate=$dir/ca.crt
private_key=$dir/ca.key
default_md=sha256
default_days=90
default_crl_days=2
policy=pol
rand_serial=yes
unique_subject=no
copy_extensions=none
email_in_dn=no
[pol]
commonName=supplied
[srv]
basicConstraints=critical,CA:FALSE
keyUsage=critical,digitalSignature
extendedKeyUsage=serverAuth
subjectAltName=DNS:one.test,DNS:two.test,DNS:three.test
crlDistributionPoints=URI:http://crl.internal.test/ca.crl
EOF

# ---------- 1. CA + three certificates ----------
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out ca.key
openssl req -x509 -key ca.key -out ca.crt -days 3650 -subj "/CN=Capstone Internal CA" \
  -addext "basicConstraints=critical,CA:TRUE" -addext "keyUsage=critical,keyCertSign,cRLSign"
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out srv.key
for n in one two three; do
  openssl req -new -key srv.key -out $n.csr -subj "/CN=$n.test"
  openssl ca -config ca.cnf -extensions srv -batch -notext -in $n.csr -out $n.crt
done

# ---------- 2. revoke two, with different reasons ----------
openssl ca -config ca.cnf -revoke one.crt   -crl_reason keyCompromise
openssl ca -config ca.cnf -revoke two.crt   -crl_reason superseded
openssl ca -config ca.cnf -gencrl -out ca.crl
cat ca.crt ca.crl > bundle.pem

# ---------- 3. with and without revocation checking ----------
echo "== WITHOUT -crl_check =="
for n in one two three; do printf '  %-8s ' "$n"; openssl verify -CAfile ca.crt $n.crt 2>&1 | tail -1; done
echo "== WITH -crl_check =="
for n in one two three; do printf '  %-8s ' "$n"; openssl verify -CAfile bundle.pem -crl_check $n.crt 2>&1 | tail -1; done

# ---------- 4. the stale-CRL outage ----------
echo "== a CRL that expired yesterday =="
openssl ca -config ca.cnf -gencrl -crldays -1 -out stale.crl
cat ca.crt stale.crl > stale-bundle.pem
printf '  three.crt (VALID cert, stale CRL): '
openssl verify -CAfile stale-bundle.pem -crl_check three.crt 2>&1 | tail -1

# ---------- 5. the health check ----------
cat > crl-health <<'EOS'
#!/usr/bin/env bash
# crl-health <crlfile> [-inform DER]
set -uo pipefail
crl="${1:?usage: crl-health <crlfile>}"; shift || true
inf=(); [ "${1:-}" = "DER" ] && inf=(-inform DER)

lu=$(openssl crl -in "$crl" "${inf[@]}" -noout -lastupdate | cut -d= -f2)
nu=$(openssl crl -in "$crl" "${inf[@]}" -noout -nextupdate | cut -d= -f2)
n=$(openssl crl -in "$crl" "${inf[@]}" -noout -text | grep -c 'Serial Number:')
num=$(openssl crl -in "$crl" "${inf[@]}" -noout -crlnumber 2>/dev/null | cut -d= -f2)

printf '\n  CRL: %s\n' "$crl"
printf '  %-16s %s\n' "revoked certs"  "$n"
printf '  %-16s %s\n' "CRL number"     "${num:-n/a}"
printf '  %-16s %s\n' "published"      "$lu"
printf '  %-16s %s\n' "expires"        "$nu"

now=$(date +%s); exp=$(date -d "$nu" +%s 2>/dev/null || echo 0)
left=$(( (exp - now) / 3600 ))
if   [ "$exp" -eq 0 ];  then printf '  ⚠️  could not parse nextUpdate (BSD date? use gdate)\n\n'; exit 2
elif [ "$left" -lt 0 ]; then printf '  ❌ STALE by %d hours - hard-fail clients will reject EVERYTHING\n\n' "$(( -left ))"; exit 1
elif [ "$left" -lt 24 ];then printf '  ⚠️  expires in %d hours - regenerate now\n\n' "$left"; exit 1
else                         printf '  ✅ fresh for another %d hours\n\n' "$left"; exit 0
fi
EOS
chmod +x crl-health
./crl-health ca.crl
./crl-health stale.crl; echo "  exit code: $?"

# ---------- 6. incident order ----------
echo "== key compromise on three.test: replace FIRST =="
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out three-new.key
openssl req -new -key three-new.key -out three-new.csr -subj "/CN=three.test"
openssl ca -config ca.cnf -extensions srv -batch -notext -in three-new.csr -out three-new.crt
diff <(openssl x509 -in three-new.crt -noout -pubkey) <(openssl pkey -in three-new.key -pubout) \
  && echo "  new pair matches - deploy and reload, verify on the wire"
echo "  ...only now:"
openssl ca -config ca.cnf -revoke three.crt -crl_reason keyCompromise
openssl ca -config ca.cnf -gencrl -out ca.crl
./crl-health ca.crl

Expected output at the key points:

== WITHOUT -crl_check ==
  one      one.crt: OK          <- REVOKED, and it passes
  two      two.crt: OK          <- REVOKED, and it passes
  three    three.crt: OK

== WITH -crl_check ==
  one      error one.crt: verification failed
  two      error two.crt: verification failed
  three    three.crt: OK

== a CRL that expired yesterday ==
  three.crt (VALID cert, stale CRL): error three.crt: verification failed

  CRL: ca.crl
  revoked certs    2
  CRL number       1001
  published        Aug 24 06:02:11 2026 GMT
  expires          Aug 26 06:02:11 2026 GMT
  ✅ fresh for another 47 hours

  CRL: stale.crl
  ❌ STALE by 25 hours - hard-fail clients will reject EVERYTHING
  exit code: 1

The five things this capstone is really testing.

1. Requirement 3 is the module's core finding. Two revoked certificates pass a normal verification cleanly. Revocation checking is off by default, so every chain check you have run since Module 05 has skipped this gate silently.

2. Requirement 4 is the failure you are more likely to cause. A valid certificate rejected because the CRL expired. -crldays -1 generates a CRL that expired yesterday — a one-flag way to test that your monitoring catches it. In production this is a cron job that stopped running, and it takes down everything at once rather than one service.

3. crl-health exits non-zero on stale, so it can be a monitoring check rather than something a human reads. It also warns at under 24 hours rather than only on failure — because by the time a CRL is stale, the outage has already started.

4. The two reason codes are visible in the ledger. openssl crl -text shows Key Compromise against one and Superseded against the other. That distinction is what an auditor reads, and it costs nothing to get right at revocation time.

5. Requirement 6's one-line answer: revocation comes last because replacement definitely ends the exposure while revocation might reach nobody — and because revoking before the replacement is live guarantees an outage while achieving nothing.

What is still missing, honestly: no OCSP responder, no automated publication, no distribution to clients, and — the big one — no browser will ever consult this CRL, because your CA is not in Certificate Transparency and nobody aggregates it. Internal revocation only works for clients you explicitly configure. That is the honest limit of what Part D can achieve.

-crl_check                  Check leaf certificate revocation
-crl_check_all              Check full chain revocation
-crl_download               Download CRL from distribution point of checked certificates
-no_check_time              Do not check certificate/CRL validity period
-extended_crl               Enable extended CRL features

What to read out of this — three of these are worth knowing.

• -crl_check versus -crl_check_all. The first checks only the leaf. The second checks every certificate in the chain, including intermediates. A revoked intermediate is far more serious than a revoked leaf, and -crl_check alone will not notice it — the same leaf-only blind spot as expiry monitoring in Module 05 (D3).
• -crl_download will fetch the CRL from crlDistributionPoints automatically. Very useful for a one-off check, and it explains why --crlfile in curl felt so manual: most tools make you supply the CRL yourself, and OpenSSL's ability to fetch it is opt-in.
• -no_check_time disables validity-period checking for both certificates and CRLs — which is how you would examine an expired CRL's contents without the staleness getting in the way. Never in production.

💡 The most useful one-liner this gives you, for checking a public certificate's revocation status end to end:

openssl s_client -connect host:443 -servername host -showcerts </dev/null 2>/dev/null \
  | sed -n '/BEGIN CERT/,/END CERT/p' > c.pem
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt -crl_download -crl_check c.pem

Expect it to fail on many modern certificates — Let's Encrypt leaves out crlDistributionPoints entirely, so there is nothing to download. That failure is the module's conclusion, demonstrated.

One field in the CA's database — V becomes R in index.txt, plus a timestamp and reason. The certificate itself does not change and cannot, because editing it would break the signature.

So revocation is a statement the CA holds, and the only way a client learns it is by asking the CA. That asymmetry is the entire difficulty.

A CRL is a bulk download: private but stale and enormous — tens of megabytes at CA scale, and always a window between publications.

OCSP is a per-certificate query: small and current but leaks which site you are visiting to the CA, and adds a blocking round trip mid-handshake.

They fail in opposite directions, and neither could be fixed without becoming the other.

If revocation information cannot be obtained, the connection proceeds anyway. Browsers chose it because hard-fail makes every CA's uptime into the web's uptime — one responder outage takes a large share of the internet down.

But it makes revocation ineffective: an attacker able to use a revoked certificate can also block the check, and the client's own policy waves them through.

Because the alternatives are both bad. Hard-fail creates availability risk; soft-fail creates a false sense of security while adding latency and, for OCSP, a privacy leak.

Demonstrably: openssl verify accepts a revoked certificate with no warning unless you pass -crl_check, and curl accepts one unless you pass --crlfile and supply the CRL yourself.

An extension (RFC 7633) placed in the certificate, saying it must always be served with a stapled OCSP response — turning soft-fail into hard-fail for that certificate only. A genuinely clever fix.

It failed on operability: the instruction is baked into a certificate valid for months, so if stapling breaks for any reason the site is hard-down until stapling is fixed or the certificate reissued. Adoption stayed negligible, and Let's Encrypt stopped issuing Must-Staple certificates in May 2025.

Privacy first: the CA learns which site is being visited from which IP on every connection, making it an unwanted log of the web's browsing. Cost second.

Must-Staple rejected from 30 January 2025, OCSP URLs removed from certificates 7 May 2025, responders shut down 6 August 2025. Their certificates now carry no revocation URL at all.

Firefox: CRLite, default since Firefox 137 — Mozilla fetches all CAs' CRLs centrally, cross-references Certificate Transparency, and ships a compact filter covering all revocations: ~4 MB every 45 days plus ~300 kB daily, refreshed every 12 hours.

Chrome: CRLSets — a curated list covering roughly 1% of revocations, at about double CRLite's bandwidth.

Both are local, offline and perfectly private, and cannot be blocked by an attacker — which finally escapes soft-fail.

Short lifetimes. 200 days from March 2026, 100 from March 2027, 47 from March 2029. At 47 days a compromised certificate's remaining life is shorter than many CRLs' refresh interval.

Revocation was not fixed; it was made less necessary. The second effect is deliberate: short lifetimes force automation, and automation removes the manual steps where outages come from.

New key → new certificate → verify the pair → deploy and reload everywhere → confirm on the wire → then revoke → then fix the source.

Revocation is last because it is the weakest control and may reach nobody, while deploying the replacement definitely ends the exposure. And never reissue on the compromised key.

A stale CRL. Past nextUpdate it is treated as absent, and any client configured to hard-fail then rejects every certificate from that CA — the whole estate at once, because a cron job stopped.

A stale CRL is far more likely to cause an outage than a revoked certificate is to cause a breach. Regenerate daily on a 7-day CRL, and monitor nextUpdate rather than the file's existence.

-crl_check checks the leaf only. -crl_check_all checks every certificate in the chain, including intermediates.

A revoked intermediate is far more serious than a revoked leaf, and leaf-only checking will not see it — the same blind spot as leaf-only expiry monitoring.

For clients you explicitly configure, yes, and better than on the public internet — your CRL is kilobytes, there is no third-party privacy problem, and it is on infrastructure you control.

For browsers, no, not at all. Your CA is not in Certificate Transparency logs and is not aggregated by Mozilla or Google, so CRLite and CRLSets know nothing about it. Internal revocation reaches only the clients you have set up to check.

Question selection was cross-referenced against publicly published 2026 SSL/TLS and PKI interview question sets, then rewritten and deepened:

• ClimbTheLadder — 15 PKI Interview Questions and Answers
• InterviewPrep — Top 25 SSL Certificate Interview Questions and Answers
• ClimbTheLadder — 10 SSL Certificate Interview Questions and Answers
• Devinterview.io — Web Security interview questions for 2026

Every command and expected output in this module was executed on OpenSSL 3.0.13, including the full revoke → CRL → verify cycle, the index.txt before-and-after showing V becoming R with a reason code, and the four verification outcomes that make up Exercise A2.2 — that a revoked certificate passes a normal openssl verify (b.crt: OK), that -crl_check catches it (error 23), and that -crl_check with no CRL available rejects a valid certificate (error 3). That last pair is the hard-fail/soft-fail dilemma, demonstrated rather than described.

Current-state claims were verified against primary sources: Let's Encrypt's OCSP retirement announcement for the January/May/August 2025 timeline and the privacy rationale; Mozilla's CRLite post for Firefox 137 default enablement, the ~4 MB/45-day plus ~300 kB/day figures, and the comparison with Chrome's CRLSets covering roughly 1% of revocations; CA/B Forum Ballot SC081v3 for the 200/100/47-day schedule; and RFC 6960, RFC 7633 and RFC 5280 §5 for the protocols themselves.

Answers were rewritten and deepened rather than reproduced — published versions are usually correct but shallow, and the added operational detail is what actually differentiates a candidate in the room.