Certificate Revocation and Certificate Transparency in Depth

TL;DR: Revocation tells clients to stop trusting a certificate before it expires, and Certificate Transparency (CT) makes every publicly trusted certificate visible so mistakes can be found. Both behave differently from the textbook picture. CAs must publish CRLs; OCSP is now optional and the largest CA has switched it off. Browsers do not ask CAs anything during a connection: Firefox checks a local CRLite filter that covers every revocation, Chrome uses a small CRLSet covering about 1% of them, and many non-browser clients check nothing, so certificate lifetime is often the real limit. CT logs are Merkle trees: a log can prove a certificate is included with about 31 hashes even at two billion entries, and witnesses stop a log showing different histories to different people. CT has exposed mis-issuance again and again, but only for names someone was watching.

Before you read

Pick an answer before you read further. The lesson below explains it, and guessing first, right or wrong, helps the explanation stay with you.

1. 1Your server's private key leaks. You revoke the certificate within an hour. A colleague says every browser will reject it within the hour too. What is wrong with that?

   Commit to a guess, then reveal

Why this lesson exists

The PKI lesson explains chains, and trust on the wire explains why revocation is weak and why lifetimes are shrinking. This lesson goes underneath: what is inside a CRL and an OCSP response, what each client really does in 2026, the clocks a CA must meet, how a CT log proves its contents, and how to monitor your own names. Interviewers use these details to separate people who have run certificates from people who have read about them.

Inside a CRL

A certificate revocation list is a signed list of serial numbers that the issuing CA no longer stands behind. The fields that matter:

• thisUpdate and nextUpdate. RFC 5280 makes nextUpdate mandatory: it promises the next CRL will appear by then. For publicly trusted server certificates, the CA/Browser Forum's Baseline Requirements (BRs) allow at most 10 days between the two.
• Revoked entries: serial number, revocation date and an optional reason code: keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), privilegeWithdrawn (9) and a few others. The BRs ban certificateHold: a public certificate cannot be suspended and un-suspended. They also allow the revocation date to be backdated to when a key was probably compromised.
• CRL number, which must strictly increase, so a client can tell old from new.

Large CAs split their CRLs into partitions (shards), so no single file grows huge. Each certificate carries a CRL Distribution Point URL naming its shard. Partitioned CRLs must carry a critical Issuing Distribution Point extension that repeats that exact URL. Without it, an attacker on the network could serve a different, legitimate, signed shard that does not list the revoked serial, and a client would accept it.

The publication clocks. A CA must publish a full set of CRLs within 24 hours of issuing its first certificate, refresh subscriber CRLs at least every 4 days (7 if every certificate also points at OCSP), and publish an update within 24 hours of recording any revocation. Since 2024, CRLs are the one mandatory mechanism: ballot SC-063 made OCSP optional and CRLs required from 15 March 2024. CAs must also list every CRL URL in the Common CA Database (CCADB) as a JSON array, within four hours of the first revocation in a new shard. That array is what browser vendors crawl.

Across the public web there are about 3,000 active CRLs totalling roughly 300 MB, according to Mozilla's 2025 figures. No browser downloads that on each connection, which is why aggregation exists.

Inside an OCSP response

OCSP (RFC 6960) answers a question about one certificate. The client identifies it by a CertID: a hash of the issuer's name, a hash of the issuer's key and the serial number. The responder answers one of three statuses:

• good: no certificate with that serial is revoked. It does not prove the certificate was ever issued. Only the BRs stop public responders from saying good for serials that were never assigned.
• revoked, with a time and reason.
• unknown: the responder does not know this issuer.

The response is signed by the CA, or by a delegated responder certificate that the CA issued with the id-kp-OCSPSigning purpose. Delegated responder certificates usually carry an ocsp-nocheck extension, telling clients not to check the responder's own revocation status, which avoids an infinite regress.

Responses are almost always pre-signed and cached on CDNs. Requests can carry a nonce, but public responders rarely honour it, so a captured good response can be replayed until its nextUpdate. The BRs require each response to be valid for 8 hours to 10 days. Since January 2025, responders must give an authoritative answer within 15 minutes of a certificate being published.

OCSP leaks browsing. Every lookup tells the CA which IP address is visiting which site. Let's Encrypt cited this privacy risk, along with cost, when it shut down its OCSP service in August 2025. The same logs can also help investigators. After the DigiNotar compromise in 2011, the Fox-IT investigation for the Dutch government used OCSP requests for the rogue *.google.com certificate to estimate the exposed population: roughly 300,000 IP addresses, overwhelmingly in Iran.

Soft-fail, hard-fail and Must-Staple

If a client cannot reach the responder, it must choose. Hard-fail rejects the connection; soft-fail proceeds. Browsers chose soft-fail because responders go down and captive portals block them, and hard-fail would have broken large parts of the web. But an attacker able to use a stolen certificate is usually on the network path and can block the OCSP request too. Adam Langley's 2012 summary of soft-fail revocation was that it is "like a seat-belt that snaps when you crash".

OCSP stapling has the server fetch its own response and attach it to the handshake (the status_request TLS extension), fixing latency and privacy. Must-Staple (RFC 7633) is a certificate extension telling clients to hard-fail if no staple arrives. It made revocation real, and it made every OCSP outage a site outage. It was rarely deployed, and Let's Encrypt stopped issuing it in 2025.

Who actually checks, in 2026

Firefox: CRLite. Mozilla crawls every CRL disclosed in CCADB and compresses the full set of revoked serials into a filter the browser downloads. It was enabled for all desktop users from Firefox 137 in 2025. Mozilla reports about 300 kB of updates per day, a 4 MB snapshot about every 45 days, and a client refresh every 12 hours. The check is local, so it is private and fast. OCSP had blocked the handshake for about 100 ms at the median, and the median handshake fell from 56.4 ms to 39.9 ms as CRLite took over. Mozilla also announced it would stop OCSP checks for domain-validated certificates.

Chrome: CRLSets. Chrome states that it does not generally perform online OCSP or CRL checks. It pushes a CRLSet, a small list built from a subset of crawled CRLs, which Google calls its main way to block certificates quickly in emergencies. Mozilla's 2025 comparison put it at about 600 kB covering about 1% of revocations, roughly 35,000 of 4 million. How Google selects entries is not published.

Edge is Chromium-based and uses CRLSets. Enterprise policies can turn on online checks, including hard-fail for privately issued roots.

Apple documents its CT policy but not its TLS revocation mechanism in detail. Do not claim specifics in an interview without a source.

Everything else is the uncomfortable part. Command-line tools, language runtimes, embedded devices and API clients vary from "checks if configured" to "never checks". For many of the clients that call your API, expiry is the only revocation that works.

The revocation clock

When a key leaks, several clocks run in sequence. The BRs set the CA's part:

• Within 24 hours: revoke on evidence of key compromise, on the subscriber's request, or when domain validation can no longer be relied on.
• Within 5 days: revoke for most other problems, including certificates not issued according to the rules, which is the mass mis-issuance case.
• Within 24 hours of recording a revocation: publish the updated CRL.

You can start the clock yourself. The ACME protocol's revokeCert request can be signed with the certificate's own key, so anyone holding a leaked key, including the person who found it, can revoke the certificate without the account credentials.

Short-lived certificates are the exception. Since 15 March 2026, certificates valid for 7 days or less (10 days before that) need no CRL or OCSP pointer, and the CA may choose not to support revocation at all. Let's Encrypt's six-day certificates, generally available since January 2026, are built on this.

Worked example: exposure by client type

Assume a key is compromised at a random point in a certificate's life, so on average half its lifetime remains, and at worst all of it. The CA revokes at the 24-hour limit and publishes the CRL 24 hours later. Assume CRLite's pipeline and the 12-hour client refresh add about half a day to a day, so Firefox is protected roughly 2.5 to 3 days after detection. Mozilla does not publish its back-end cadence, so treat that figure as an estimate.

Two conclusions follow. For a client with complete revocation data, the process sets the exposure. For a client that never checks, the lifetime does. At six-day lifetimes the two converge, which is the argument for short-lived certificates and for letting CAs skip revocation for them.

Certificate Transparency, mechanically

CT exists because any trusted CA can issue a certificate for any name, and before CT nobody could list what had been issued. DigiNotar's 2011 compromise produced hundreds of rogue certificates that no one could enumerate.

The flow:

1. Before issuing, the CA builds a precertificate: the certificate's contents plus a critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3) that makes it unusable as a real certificate.
2. The CA submits it to several logs. Each returns a Signed Certificate Timestamp (SCT), a signed promise to include the entry within the log's maximum merge delay.
3. The CA embeds the SCTs in the final certificate. SCTs can also be delivered in a TLS extension or, for some clients, in a stapled OCSP response.
4. Browsers refuse publicly trusted certificates without enough valid SCTs.

Some current details matter in interviews:

• Merge delay. The RFCs set no value, and 24 hours was the convention. Chrome's log policy now caps it at 4 hours for classic RFC 6962 logs and 1 minute for the newer static-ct-api logs.
• How many SCTs. Chrome requires 2 embedded SCTs for certificates valid up to 180 days and 3 for longer ones, from distinct logs with at least two operators. Apple and Firefox have similar counts. Apple still requires at least one SCT from an RFC 6962 log; Chrome dropped that rule in April 2026. Chrome stopped accepting SCTs from stapled OCSP responses in Chrome 148 (May 2026), while Apple and Firefox still accept them.
• Log before issuance. Since 15 June 2026, Chrome's root programme requires the precertificate to be logged before the certificate is issued.
• Temporal sharding. Each log accepts only certificates expiring within one calendar year, so logs carry names like 2026 or 2027 and can be retired once their certificates have expired.
• Tiled logs. New logs must use the static-ct-api: entries and tree nodes are served as immutable, cacheable 8 KB tiles instead of through custom read APIs. Let's Encrypt moved to this design (its Sunlight software) partly because running classic logs was costing close to seven figures a year.

How a log proves what it contains

A log is a Merkle tree. Each certificate becomes a leaf hash; each parent node is the hash of its two children; the root summarises everything. The log signs the root and the tree size in a signed tree head (a checkpoint).

Two proofs make the structure useful:

• An inclusion proof shows that one entry is in the tree. It is the list of sibling hashes on the path from the leaf to the root. The verifier recomputes the root and compares it with the signed one.
• A consistency proof shows that a later tree contains an earlier one unchanged: the log only appended, never rewrote history.

Worked example: proving inclusion in two billion entries

The path from a leaf to the root has one sibling per level, and a tree of n leaves has about log2(n) levels.

• log2(2,000,000,000) ≈ 30.9, so an inclusion proof needs at most 31 hashes: 31 × 32 bytes = 992 bytes.
• A consistency proof needs at most log2(n) + 1 hashes: 32 hashes, 1,024 bytes.
• Checking inclusion by downloading every leaf hash instead would mean 2 × 10^9 × 32 bytes = 64 GB.

Tiled logs trade a few more bytes for caching. Each tile holds 256 hashes, and 256^4 is about 4.3 billion, so a two-billion-entry tree is 4 tile levels deep. A client fetches at most one tile per level, about 32 KB, all of it cacheable by a CDN.

Split views, auditors and witnesses

A proof is only as good as the root it is checked against. A dishonest log could show one tree, containing a rogue certificate, to its victim, and another tree, without it, to everyone else. This is a split view, and Chrome's log policy forbids it.

Three roles keep logs honest:

• Monitors download whole logs and look for certificates of interest. Domain owners and CAs run them.
• Auditors take partial evidence, such as an SCT seen in a connection or a pair of tree heads, and check it against the log with inclusion and consistency proofs. Chrome samples SCTs it sees in the wild and checks they were included, using a privacy-preserving lookup for users who have not opted into extra reporting.
• Witnesses co-sign a log's checkpoint only after verifying a consistency proof from the last checkpoint they saw. A client that requires several independent witness signatures cannot be shown a fork, because the witnesses will not sign two incompatible histories.

When a log misbehaves, it is distrusted. SCTs it issued before the cut-off still count, which is exactly why policies demand SCTs from logs run by different operators.

What CT has caught

The 2025 case is the one to remember. The certificates were logged for 18 months before anyone acted. CT gives you evidence; you still have to look at it, for every kind of identifier you own.

Monitoring your own names

Use a monitoring service or run your own over the logs, and alert on:

1. An issuer not allowed by your CAA records. Either a CA ignored CAA or someone changed it.
2. Wildcards, if you do not use them.
3. Names you do not recognise: shadow IT, a forgotten vendor, or a takeover.
4. IP-address certificates for your address ranges.
5. Look-alike domains for phishing, which needs fuzzy matching across the whole log, not just your own suffix.
6. The same public key appearing on certificates for unrelated teams or services.
7. Precertificates without a final certificate. A precertificate is evidence of intent to issue; treat it as issuance.

Pair monitoring with CAA records using the accounturi parameter (RFC 8657), which restricts issuance to your specific ACME account at a CA, not just to the CA. Remember that browsers never check CAA; it binds CAs at issuance, and CT is how you find out a CA ignored it. CT also exposes your internal hostnames to attackers enumerating subdomains, so names that should stay private belong on a private CA.

Private PKI: none of this exists

Certificates from your own CA, for service-to-service mutual TLS, device identity or internal tools, get no CT, no CRLite and no CRLSet. Chrome's root programme now requires public TLS hierarchies to be dedicated to server authentication, pushing client certificates onto private CAs, exactly where the browser machinery does not reach. You need a design:

• Short lifetimes as revocation. SPIRE's defaults are 1-hour certificates and a 24-hour CA. step-ca revokes "passively" by default: it refuses renewal, and the certificate dies at expiry.
• CRLs with hard-fail, inside a network where you own availability, with short nextUpdate values and partitioning to keep files small.
• Internal OCSP with stapling, again with hard-fail, and responder keys kept separate.
• A pushed deny-list of revoked key hashes at the mesh or gateway, for emergencies, the same idea as a CRLSet.

Where this is heading: Merkle Tree Certificates

Post-quantum signatures are large: an ML-DSA-44 signature is 2,420 bytes against 64 for ECDSA P-256, and a typical handshake carries several signatures, two of them SCTs. Merkle Tree Certificates, an IETF working-group draft from Google, Apple, Cloudflare and others, fold CT into the certificate itself: the CA logs everything it issues, and a certificate carries an inclusion proof instead of its own signature. In an experiment across about 1,000 Cloudflare domains with Chrome Beta, the largest proof was 512 bytes and handshakes were about 9% faster at the median. Chrome plans to invite CT log operators to bootstrap public Merkle Tree Certificates in early 2027. With validity periods of 7 to 47 days, expiry again does most of the work of revocation.

Misconceptions interviewers listen for

• "Browsers check OCSP on every connection." Chrome does not, and Firefox uses local CRLite data.
• "An OCSP good response proves the certificate is legitimate." It says the serial is not revoked, not that it was issued.
• "CRLs are dead." They are the only mandatory mechanism. Clients just do not fetch them directly any more.
• "An SCT proves the certificate is in the log." It is a promise. Inclusion needs a proof.
• "The merge delay is 24 hours." Chrome now caps it at 4 hours, or 1 minute for tiled logs.
• "CT prevents mis-issuance." It makes mis-issuance visible to whoever is watching.
• "Short-lived certificates cannot be revoked." The CA may still revoke them; it is just not required to.

What if · interview follow-ups

Hold your answer as the constraints change

You own TLS for a company with public websites, a public API used by partners' scripts, and an internal service mesh with its own CA. A private key for a public API certificate has just been found in a public repository.

1. 1

   Start here

   What do you do in the first hour, and in what order?

   Nudge meAnswer it out loud, then reveal

Revising, not practising? Show every answer

Primary references

References for the mechanisms discussed above, accessed 6 November 2026:

• RFC 5280: X.509 certificates and CRLs and RFC 6960: OCSP.
• CA/Browser Forum TLS Baseline Requirements: revocation deadlines (section 4.9.1.1), CRL publication (4.9.7), OCSP rules (4.9.9) and the CRL profile (7.2).
• Ballot SC-063: OCSP optional, CRLs required.
• Mozilla Hacks: CRLite in Firefox, August 2025 and Chromium: CRLSets.
• Let's Encrypt: ending OCSP support and six-day and IP certificates.
• RFC 6962 and RFC 9162: Certificate Transparency.
• Chrome CT policy, Chrome CT log policy and Apple's CT policy.
• C2SP static-ct-api and C2SP tlog-witness.
• Cloudflare: unauthorised issuance of certificates for 1.1.1.1, September 2025 and Google on the 2015 Symantec certificates.
• IETF draft: Merkle Tree Certificates.

How this shows up in interviews

Expect "how does certificate revocation work?", "why doesn't OCSP work?", "what is Certificate Transparency and what are its limits?", "walk me through a leaked private key" and "how do you revoke certificates in a service mesh?". Strong answers describe what each client actually does today, give the CA's deadlines, explain inclusion proofs and split views, cite a real CT detection with its lesson, and design revocation for private PKI around short lifetimes.

Say it in 30 seconds: "CAs must publish CRLs; OCSP is optional and fading because soft-fail checks fail exactly when attacked and leak browsing. Browsers use pushed data instead: Firefox's CRLite covers every revocation, Chrome's CRLSet a small slice, and many non-browser clients check nothing, so lifetime is the real bound, which is why lifetimes are shrinking to 47 days. CT makes every public certificate visible: logs are Merkle trees with small proofs, witnesses stop split views, and monitors find mis-issuance, but only for names someone watches. For private PKI I use hour-scale certificates and a deny-list."

Check yourself

Say or write your answer first, then reveal. Explaining it from memory, in your own words, is the skill an interviewer is checking.

1. 1What does an OCSP 'good' status actually tell you?

   Answer it, then reveal

2. 2Why do partitioned CRLs need an Issuing Distribution Point extension?

   Answer it, then reveal

3. 3How do Firefox and Chrome learn about revocations in 2026?

   Answer it, then reveal

4. 4How many hashes does an inclusion proof need in a log of two billion entries?

   Answer it, then reveal

5. 5What is a split view, and what stops it?

   Answer it, then reveal