Revocation

30.0 What this chapter gives you#

1. You will be able to say in one sentence why a certificate must sometimes be cancelled before it expires, and name the three situations that force it.
2. You will be able to read a certificate revocation list field by field, name the reason codes with their numbers, and say which of them the public web forbids.
3. You will be able to build an OCSP request by hand, including computing the two hashes inside it, and predict what the responder will send back.
4. You will be able to explain, in one honest paragraph, exactly what a certificate authority learns about a person when their software asks it a status question.
5. You will be able to describe OCSP stapling and the must-staple extension, and give the measured reason each of them failed to take over the web.
6. You will be able to define soft-fail, state what each major browser does when a status check fails as of August 2026, and explain why they chose it.
7. You will be able to compare CRLSets, OneCRL and CRLite with real sizes and coverage figures, and say what each one can and cannot answer.
8. You will be able to recite the Heartbleed revocation numbers from the 2014 measurement papers and say what they proved about the whole mechanism.
9. You will be able to state the certificate lifetime schedule with its exact dates, and explain why shortening lifetimes is a revocation strategy.
10. You will be able to design revocation for a private certificate authority inside one company, where almost every constraint is different.

A certificate is a signed statement with an expiry date on it. That is a useful thing, but it has one obvious weakness: signatures cannot be recalled. Once a certificate authority has signed a certificate and handed it over, the bytes exist. They are correct bytes. They verify. Anybody holding the matching private key can present them to anybody in the world, and the mathematics will say yes. If the private key is stolen on the second day of a two hundred day certificate, the thief holds a perfectly valid credential for the remaining one hundred and ninety-eight.

Revocation is the industry’s attempt to solve that. The idea is simple and old: the authority keeps a list of the certificates it has cancelled, and everybody consults the list before trusting one. Every part of that sentence turns out to be harder than it sounds. The list gets enormous. Consulting it costs a network round trip on the critical path of every connection. The consultation leaks to the authority which sites a person visits. And when the consultation fails, which it does constantly, the software has to decide between refusing to work and pretending everything is fine. It chose the second one, everywhere, and the choice was rational.

This chapter is the honest account of that failure and of what the industry did instead. We will build a real certificate on a laboratory authority, revoke it, print the resulting revocation list, compute an online status request by hand and read the answer. We will look at the two large-scale revocation events, in April 2014 and July 2024, that showed what the machinery does under load. And we will end at the answer the industry actually reached, which is not a better revocation mechanism at all: it is to make certificates expire so quickly that revoking them stops mattering.

Two boundaries, stated once. This chapter is not about the handshake in which a certificate is presented, which is chapter 29, “The Handshake”. It is not about the public logs that record every certificate ever issued, which is chapter 31, “Certificate Transparency”, although those logs turn out to be where the modern revocation systems get their raw material. And it is not about what happens when an authority is caught misbehaving badly enough to be removed entirely, which is chapter 35, “When a Certificate Authority Fails”.

The plain version#

The pass that cannot be unprinted#

Picture a large office building on the seafront in Kochi. Thousands of people work in it. At the entrance there is a booth with a guard, and nobody gets past the booth without a pass.

The passes are printed by a small office on the ground floor. Each pass has a number on it, a name, and a stamped seal pressed into the card so that nothing on it can be altered afterwards without the alteration showing. The guard’s whole job is to look at the seal. If the seal is intact and the date on the card has not gone by, the holder walks in.

Reshma works on the fourth floor. Her pass is number 4471 and it is good for two hundred days. On day three, her bag is stolen on the ferry, with the pass in it.

Now here is the problem, and it is the entire problem of this chapter. The building cannot un-print the card. The card exists. It is in somebody else’s pocket, and it is a genuine card with a genuine seal and a date that has not passed. Every test the guard is able to perform, that card passes. The building’s own machinery, working exactly as designed, will let a thief in every morning for the next one hundred and ninety-seven days.

The card was never the security. The security was the assumption that only the right person would hold it, and that assumption has just failed. All that follows is the building patching over a card it can no longer reach.

The sheet pinned in the booth#

The obvious fix is a list. The pass office writes down 4471 on a sheet of paper headed “cancelled”, and pins the sheet inside the guard’s booth. From now on, the guard checks the seal, checks the date, and then reads down the sheet to see whether the number appears. That is a complete and correct solution, and versions of it have been used since long before computers.

It also has three faults, and it is worth being precise about them, because these three faults are the whole history of the subject.

The first is that the sheet only grows. A number goes on it the day the pass is cancelled and comes off only the day that pass would have expired anyway. With two hundred day passes and ten thousand people losing bags at a normal rate, the sheet is not a sheet but a bound volume, and the guard reads a bound volume while a queue forms. Multiply by the whole world and it is a library.

The second is delay. The sheet is reprinted on a schedule, say every four days, so a pass cancelled on Tuesday may not appear in the booth until Saturday. For four days the guard checks a list that is confidently, correctly, uselessly out of date, and Reshma’s stolen pass works all week.

The third fault is that there is more than one booth. Six entrances, a car park barrier and a service door each need their own current copy, and somebody must carry paper to all of them, forever.

Telephoning the office instead#

So the building tries the other obvious thing. Rip the sheet off the wall and give each guard a telephone. When a card is presented, the guard rings the pass office and asks one question: is 4471 still good.

This fixes the size problem completely. The office holds the volume and the guard asks about one number. It mostly fixes delay too: the office knows within minutes of a cancellation, so the answer is fresh.

But it introduces three new faults, and again these are exactly the faults that played out in the real system.

The first is that every visitor now waits for the call. The guard dials, the office looks it up, the visitor goes in. It is not a long wait, but it happens on every entry, forever, at the worst possible moment: when somebody is standing at the door wanting to get on with their day.

The second is that the pass office now knows everything. It learns that Reshma’s pass was presented at the seafront entrance at 09:14, at the car park barrier at 13:02, and at the service door at 19:40. It did not previously know any of that. It has no need for it. But it is now, unavoidably, a record of where a person went and when, held by an outside company that was only ever supposed to print cards.

The third fault is the one that matters most. Telephone lines fail. The office closes at night. The line is engaged. Someone digs up the road. And when the guard picks up the handset and hears nothing at all, the guard has to decide what to do with the person standing in front of them.

What the guard does when the telephone is dead#

There are exactly two policies available, and neither is good.

The strict policy is: no answer, no entry. A cancelled pass can never get in. But the building also stops working entirely every time the telephone line does, which is often, for reasons that have nothing to do with security. One cut cable and ten thousand people stand in the rain.

The relaxed policy is: no answer, let them in. The building keeps working through every outage, nobody complains, and deliveries arrive.

Every building in the world chose the relaxed policy, and you can see exactly why. But look at what it means. A thief who wants to use Reshma’s stolen pass does not need to defeat the seal, or forge a date, or bribe anyone. The thief needs to make the telephone not work. Cut the line, jam the exchange, stand at the one entrance whose handset is broken. The check that was supposed to stop a stolen pass is switched off by the very person it was built to stop.

There is a line about this quoted for over a decade, from a note written in February 2012 by Adam Langley, then working on Google Chrome. A check that fails open like this, he said, is like a seat belt that snaps when you crash: it works ninety-nine per cent of the time and is worthless, because it only works when you do not need it.

That single observation is why the rest of this chapter exists.

The note the visitor carries#

Somebody proposes a clever fix. Instead of the guard telephoning the office, make the visitor bring the answer with them.

Each morning, before leaving home, Reshma calls the pass office herself and asks it to write out a small dated slip: “pass 4471 was in good standing at 07:30 this morning, signed, the pass office”. The office presses its seal on the slip so it cannot be faked. Reshma hands the guard her card and the slip together.

This is genuinely elegant. The guard makes no telephone call, so there is no wait and no outage. The office learns nothing about where Reshma went, because it heard only from Reshma, its own customer, whose name it already knows. The slip is sealed, so she cannot forge a good one for a cancelled card.

There is one hole, and the hole sank the whole idea. If Reshma simply does not bring a slip, what does the guard do? If the guard shrugs and lets her in anyway, then a thief holding the stolen card also simply does not bring a slip, and we are exactly where we started. The fix only works if a missing slip is a refusal.

So a second idea is added: some cards carry an extra mark saying “the holder must always present a slip; if there is none, turn them away”. Now the rule cannot be dodged by omission.

That is the right design. Almost nobody used it. The reason is dull and human: the mark makes your card fragile. If the pass office’s slip printer is down for an hour on the morning you needed to get to work, your card, which is perfectly valid, is refused at the door. Most people quite reasonably decided they would rather have a card that always works than a card that is safer when stolen. And most guards never bothered to implement the rule, so people who did take the extra mark often got no benefit from it anyway.

The courier from head office#

Here is the approach that finally worked, and it is a return to the sheet on the wall with better logistics.

Head office notices that it can see every cancellation across every building in the city, because the pass offices are all obliged to publish their cancelled lists. So head office collects all of them, several times a day, and compresses the whole thing into a very small booklet - not a list of numbers, but a cleverly compressed summary that lets a guard test any number in a fraction of a second and get the right answer. A courier drops a fresh booklet at every booth twice a day.

Now the guard makes no telephone call. There is no wait, no outage, no privacy leak, and no dependence on the visitor bringing anything. The guard opens the booklet, tests the number, and knows.

The catch is that somebody must do the collecting, compressing and couriering for the whole city, every day, forever, and only a very large organization can. In the real system that organization is a browser maker. The booklet is small: in Firefox, as of 2025, about a four megabyte snapshot every forty-five days plus updates in between, roughly three hundred kilobytes a day.

Making the pass expire before it matters#

And then somebody asks the question that ends the argument. Why are we issuing two hundred day passes at all?

If a pass is good for seven days and is re-printed automatically every few days without anybody thinking about it, then a stolen pass is worth at most a few days of misuse. The cancelled list still exists, but it barely matters, because a card that stops working on its own next Tuesday does not need to be hunted down.

This is not a better cancellation mechanism. It is an admission that cancellation does not work, and a decision to make the window small enough that the failure is survivable. It is also, as of August 2026, exactly the direction the real system is moving in, on a published schedule with dates on it, and the rest of this chapter will give you those dates.

Where the plain version stops being true#

There is no single pass office, and nobody holds every list#

The analogy has one pass office and one list. The real system has hundreds of issuing authorities, each publishing its own cancellations in its own place, at its own moment, in its own file. A piece of software that wants to know whether a certificate is cancelled must first work out which authority issued it, then find where that authority publishes, then fetch from there.

That is not a small detail. It means there is no “the list”. A browser cannot simply download revocation, the way it downloads a software update, because revocation is scattered across every authority in the world and each one only knows about its own certificates. Mozilla’s root store, as reported in the 2026 study of the CRLite deployment, points at roughly three thousand active revocation lists across the whole public system. The only way to get one answer is for somebody to visit all three thousand places and stitch the results together, which is precisely what the modern systems do.

The honest version: revocation on the public web is not a lookup, it is an aggregation problem, and the aggregation is done by browser vendors as a public service that nobody pays them for.

“Cancelled” is a claim by one party, not a fact about the world#

In the story, the pass office cancels a pass because the pass was stolen. The list therefore looks like a record of reality. It is not. It is a record of what one company decided, for reasons of its own, and the reasons are often administrative rather than dangerous.

Look at the reason codes the public web actually permits, which we will list properly later. Only one of them, keyCompromise, means “somebody may have the private key”. Others mean the subscriber asked for a new certificate, or the authority found a paperwork error in its own issuance, or the website simply shut down. A very large share of all revocations are of this second kind: no attacker, no danger, just tidying up. Google’s Chrome team has said since 2012 that this is why they exclude most revocations from what they push to users, and the trade-off is deliberate.

This cuts the other way too. A certificate can be dangerous and not be on any list, because nobody noticed the key was stolen. Absence from a revocation list means “no authority has told us to distrust this”, which is a much weaker statement than “this is safe”.

The guard almost never looks, and that is the design#

The plain version implies that checking happens and sometimes fails. For most of the web, most of the time, checking does not happen at all.

Google Chrome states plainly in its own documentation that online revocation checks are not generally performed. It does not telephone the pass office. It consults a small pushed list and, if the certificate is not on it, proceeds. Chrome has behaved this way since 2012 and has never gone back.

So when you read that “browsers soft-fail”, it is worth separating two different things. Soft-fail is what happens when a check is attempted and does not come back. But the more common case in Chrome is that no check is attempted, so there is nothing to fail. Firefox is the outlier here: since Firefox 137 it has consulted a complete local filter of every known revocation, and it turned online status checking off entirely in Firefox 142, released in August 2025.

The honest version: for most of the last decade, for most users, a revoked certificate on a normal website continued to work exactly as if it had never been revoked, and nothing on the screen said so.

Cancelling is not free, and the bill lands on a bystander#

In the story, cancelling a pass costs the office a line of typing. In reality, cancelling a certificate imposes costs on people who did nothing wrong.

When a large hosting provider revoked its certificates after the Heartbleed disclosure in April 2014, one authority’s revocation list grew from about two kilobytes to about 4.7 megabytes, measured by the researchers behind “The Matter of Heartbleed”. Everybody in the world who then downloaded that list paid for it in bandwidth and time, including people who had never visited any affected site. There is no mechanism by which the party causing the revocation pays for its distribution.

Worse, revocation can itself be an outage. In July 2024 an authority found a validation defect and, under rules allowing twenty-four hours and no extensions, had to revoke tens of thousands of live certificates belonging to blameless customers. One of them went to court to stop it, and we will come back to that case with the numbers.

The telephone leak is worse than “the office knows”#

The plain version says the pass office learns where Reshma went. The real leak is sharper than that, and the wording matters because people wave it away.

An online status check discloses, to a third-party company, the identity of the site being visited, the visitor’s network address and the time, at the moment of the visit, in plaintext by design. The protocol has no confidentiality of its own, and the request is ordinarily carried over unencrypted HTTP, so anybody on the path sees it too.

Let’s Encrypt, announcing in December 2024 that it would end the service, put it in one sentence: the authority operating the responder immediately becomes aware of which website is being visited from that visitor’s particular network address. It added that it cannot promise never to be compelled to retain it.

You are usually revoking for a compromise nobody detected#

The story has a clean trigger: the bag was stolen and Reshma knows it. Key compromise in the real world is usually silent. A private key sitting on a server can be read by an attacker who leaves no trace, and the owner may never learn it happened.

This changes the meaning of revocation completely. Revocation only helps in the subset of cases where the compromise is discovered, discovered in time, and reported. Heartbleed is the canonical example precisely because it was the rare case where everybody discovered simultaneously that their keys might have leaked. The measured response, as we will see, was still poor.

The honest version: revocation is a remedy for detected compromise, and detection is the rare part. A mechanism that only helps after you find out is structurally weaker than one that limits the damage whether or not you find out, which is what short lifetimes do.

The pushed booklet does not cover everything#

The courier story implies the booklet is complete. In practice, coverage is a number, and the number is not one hundred per cent.

Chrome’s pushed list is explicitly a selection: it holds emergency blocks plus some ordinary revocations, and the 2026 CRLite deployment study measured it as covering only a small fraction of all known revocations, around one per cent by one count in Mozilla’s own August 2025 write-up, which cited roughly thirty-five thousand entries against about four million active revocations. Firefox’s filter aims at completeness and the same study measured effective coverage at 87.63 per cent in telemetry, with the shortfall split between clients that had not yet fetched a usable filter and certificates the aggregator had not yet seen.

Those are good numbers, and far better than what came before. They are not the totality the analogy implies.

Short passes do not delete revocation, they change whom it protects#

The last move in the plain version sounds like an ending: make the pass expire quickly and stop worrying. That is too neat.

Shortening lifetimes does not remove the need to revoke; the rules still require it for most certificates, and an authority that misissues must still clean up. What it does is change the shape of the risk. With a seven day certificate, the maximum exposure from an undetected key compromise falls from a year to a week, and it falls whether or not anybody notices. That is a real and large gain, and it is the reason the industry chose this road.

But it moves work rather than removing it. A certificate replaced every week must be replaced automatically, so every organization now depends on issuance machinery running correctly all the time. Failure moves from “a stolen key stays useful for a year” to “our renewal job broke and the site went down at three in the morning”. Experts differ on the trade. The dominant view among browser and authority engineers is that it is clearly worth it, because automation failures are visible and fixable while silent compromise is not; a minority of enterprise operators argue it merely relocates risk into change management.

The technical version#

Why a certificate gets cancelled, and the two clocks#

Revocation exists for three families of reason, and it is worth keeping them separate because they behave differently.

The first is key compromise: the private key matching the certificate’s public key is, or may be, in someone else’s hands. This is the case the whole mechanism was built for. It is also the case where revocation helps least, because compromise is usually silent.

The second is misissuance: the certificate should never have been issued in the form it was. The authority validated the wrong thing, encoded a field incorrectly, failed to check the domain’s issuance policy record, or produced a certificate that breaks a rule in the industry’s own requirements. Nobody is attacking anybody. The certificate is simply not compliant, and the rules say it must go.

The third is change of control: the subject of the certificate is no longer entitled to it. A domain name is sold or transferred, a company is wound up, a hostname is decommissioned. The certificate is not forged and the key is not stolen, but the person holding it is no longer the person the name belongs to. This is the quiet one, and it is a direct argument for short lifetimes: if a domain changes hands, the previous owner’s certificate remains cryptographically perfect until it expires.

On the public web these are not matters of taste. The CA/Browser Forum Baseline Requirements, in section 4.9.1.1, list sixteen numbered triggers across two deadlines. Five of them must be acted on within twenty-four hours. The remaining eleven should be acted on within twenty-four hours and must be acted on within five days. Both clocks start when the authority becomes aware. The version of the document in force as of August 2026 is 2.2.9, effective 6 August 2026.

That table is a selection; the full sixteen are in section 4.9.1.1. Two details in it are easy to miss and matter enormously. First, the twenty-four hour clock has no extension mechanism: an authority that misses it has an incident to disclose. Second, the requirements explicitly say the authority “MAY support revocation of Short-lived Subscriber Certificates” and exempt them from both clocks, which is the single most important sentence in this chapter and we will return to it.

Suspension, incidentally, does not exist on the public web. X.509 has a reason code called certificateHold meaning “paused, may come back”, and Baseline Requirements section 4.9.13 forbids it: the repository must not include entries indicating a certificate is suspended. Private authorities may still use it, and some do.

The certificate revocation list, field by field, with a real one#

A certificate revocation list is defined in RFC 5280, section 5. It is an X.509 v2 CRL, and it is a signed object in exactly the way a certificate is: a body, an algorithm identifier and a signature over that body.

CertificateList ::= SEQUENCE {
    tbsCertList          TBSCertList,
    signatureAlgorithm   AlgorithmIdentifier,
    signatureValue       BIT STRING }

TBSCertList ::= SEQUENCE {
    version              Version OPTIONAL,
    signature            AlgorithmIdentifier,
    issuer               Name,
    thisUpdate           Time,
    nextUpdate           Time OPTIONAL,
    revokedCertificates  SEQUENCE OF SEQUENCE {
        userCertificate      CertificateSerialNumber,
        revocationDate       Time,
        crlEntryExtensions   Extensions OPTIONAL
        } OPTIONAL,
    extensions       [0] EXPLICIT Extensions OPTIONAL }

Note what a CRL entry contains and, more importantly, what it does not. It contains a serial number, a date, and optional per-entry extensions. It does not contain the subject name, the domain, the public key, or anything else that would let you recognize the certificate by sight. A CRL is a list of numbers scoped to one issuer, and the scoping is implicit: the entries mean nothing except in combination with the issuer field at the top.

To make this concrete, here is a real one. For this chapter I built a laboratory certificate authority with OpenSSL 3.0.13, issued a certificate for the name pay.kedbyte-lab.example with a two hundred day validity - the current public maximum - revoked it with reason keyCompromise, and generated the list. Every value below is genuine output from that authority, reflowed to fit the page. It is a laboratory authority, not a public one, so nothing here is trusted by any browser.

Certificate Revocation List (CRL):
    Version 2 (0x1)
    Signature Algorithm: sha256WithRSAEncryption
    Issuer: C = IN, O = KedByte Laboratory CA,
        CN = KedByte Laboratory Issuing CA R1
    Last Update: Aug 18 00:23:40 2026 GMT
    Next Update: Aug 22 00:23:40 2026 GMT
    CRL extensions:
        X509v3 CRL Number:
            4096
Revoked Certificates:
    Serial Number:
        403DF8D11F4795D31135DCBDA5F9012A6709E328
        Revocation Date: Aug 18 00:23:40 2026 GMT
        CRL entry extensions:
            X509v3 CRL Reason Code:
                Key Compromise
    Signature Algorithm: sha256WithRSAEncryption
    Signature Value:
        a5:85:b1:1f:01:33:44:e6:10:24:b8:7c:27:4a:5f:
        14:b1:8f:f6:b3:64:70:39:89:4b:05:1d:d7:5a:12:
        43:1d:e6:b9:a2:f3:66:3c:07:d8:07:30:58:1d:1f
        (signature truncated for the page)

“Last Update” in the OpenSSL printout is the field RFC 5280 calls thisUpdate. Together with nextUpdate it defines the window in which this list is the current answer. Note that the window here is four days, which is the shortest the Baseline Requirements permit for an authority whose certificates carry no online responder pointer. A client that fetched this list one minute after publication and cached it until nextUpdate would be working from information up to four days stale, and that is not a bug, it is the specification.

The reason codes come from RFC 5280 section 5.3.1. The public web permits a subset, listed in Baseline Requirements section 7.2.2.

There is no value 7; the enumeration skips it. Since 15 July 2023 the Baseline Requirements have required a reason code on public CRL entries in all but narrow cases, chiefly where the reason genuinely is unspecified, which is why modern public lists are far more informative than they were a decade ago.

Four CRL extensions are worth naming. CRL number, RFC 5280 section 5.2.3, is a strictly increasing counter so a client can tell a newer list from an older one. Issuing distribution point, section 5.2.5, marks a list as covering only part of an issuer’s certificates, and is what makes sharding legal; the Baseline Requirements say a partitioned list must carry it and that its URL must byte-for-byte match the one in the certificate. Delta CRL indicator, section 5.2.4, marks a list that carries only changes since a named base list, and freshest CRL, section 5.2.6, points at where the deltas live. Deltas were the 1999-era answer to CRL size and they are widely implemented inside enterprise software and almost unused on the public web.

One per-entry extension is a genuine trap. Invalidity date, section 5.3.2, is the date the key is believed to have been compromised, which may be earlier than the revocation date. The public rules deliberately break with RFC 5280 here: Baseline Requirements section 7.2.2 says an authority should backdate the revocationDate itself when it learns the key was compromised earlier, because TLS implementations treat revocationDate as the moment the certificate became untrustworthy and mostly ignore invalidityDate.

The arithmetic that broke the CRL#

The design is sound. The problem is size, and the numbers are easy to get.

On the laboratory authority above I issued and revoked two hundred more certificates and measured the file. One entry produced a 493-byte list. Two hundred and one entries produced an 11,095-byte list. The marginal cost of a revocation entry, with a twenty-byte serial number and a reason code, is therefore 53 bytes.

1 entry     ->     493 bytes
201 entries ->  11,095 bytes
marginal    ->      53 bytes per revocation
gzip -9 of the 201-entry list -> 4,868 bytes

Now scale it. The 2026 study of the CRLite deployment measured roughly four million active revocations across the public web in September 2024, rising to about 6.1 million during an incident in August 2025. Four million entries at 53 bytes is about 212 megabytes of revocation data, before any consideration of how it is split up or how often it changes. Compression helps less than the laboratory figure suggests, because real serial numbers are random by requirement and random data does not compress; most of the saving above came from the repeated dates and structure.

Let’s Encrypt described the same wall from the issuer’s side in a post of 7 September 2022. Holding over two hundred million active certificates, it calculated that a single list covering a total revocation event would exceed eight gigabytes, and it therefore split its revocation data into 128 shards with a fixed assignment so that a certificate stays in the same shard across reissues.

The publication rules make the staleness explicit. Baseline Requirements section 4.9.7 requires a new list at least every seven days if the certificates carry an online responder pointer, at least every four days if they do not, and within twenty-four hours of recording any revocation. So the worst-case delay between an authority deciding a certificate is dead and a client that refreshes on schedule learning about it is measured in days. Microsoft’s root program recommends that a published list not exceed ten megabytes, whether full or partitioned.

OCSP: the request and the response, computed by hand#

The Online Certificate Status Protocol was the answer to size. Instead of downloading the list, ask about one certificate. It was first standardized as RFC 2560 in June 1999 and is now RFC 6960, published June 2013, which also obsoleted RFC 6277 on algorithm agility.

The request is small because it identifies a certificate without containing it. RFC 6960 section 4.1.1 defines the identifier:

CertID ::= SEQUENCE {
    hashAlgorithm    AlgorithmIdentifier,
    issuerNameHash   OCTET STRING,
    issuerKeyHash    OCTET STRING,
    serialNumber     CertificateSerialNumber }

issuerNameHash is a hash of the DER encoding of the issuer’s distinguished name, exactly as it appears in the certificate. issuerKeyHash is a hash of the issuer’s public key bit string, not including the tag and length. The default hash is SHA-1, and it is used here purely as an identifier, not as a security property, which is why its weakness against collisions does not matter.

Here is that computed by hand against the laboratory authority. The issuer name occupies ninety bytes of DER inside the certificate, and its SHA-1 is:

issuer Name DER length: 90 bytes
sha1(issuer Name DER)
  = 45B9F123ED1B5DFB93234D996B20466897737A9D

And here is the request OpenSSL built for the same certificate, printed with the -req_text option. The name hash matches the one computed above, which is the point of doing it by hand.

OCSP Request Data:
  Version: 1 (0x0)
  Requestor List:
    Certificate ID:
      Hash Algorithm: sha1
      Issuer Name Hash:
        45B9F123ED1B5DFB93234D996B20466897737A9D
      Issuer Key Hash:
        0D4DC42DA65D06BDD368B4446D27A7EBDA4BEEB4
      Serial Number:
        403DF8D11F4795D31135DCBDA5F9012A6709E328

The whole request is 87 bytes of DER. That is the case for the protocol in one number: 87 bytes against 212 megabytes.

The response is signed, and its shape is defined in RFC 6960 section 4.2.1. Running the laboratory responder and asking it about the revoked certificate gives this, again genuine and reflowed:

OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Responder Id: CN = KedByte Laboratory OCSP Responder
Produced At: Aug 18 00:24:01 2026 GMT
Certificate ID:
  Hash Algorithm: sha1
  Serial Number:
    403DF8D11F4795D31135DCBDA5F9012A6709E328
Cert Status: revoked
Revocation Time: Aug 18 00:23:40 2026 GMT
Revocation Reason: keyCompromise (0x1)
This Update: Aug 18 00:24:01 2026 GMT

That response, including the responder’s own certificate so the client can verify the signature, is 1,417 bytes.

There are only three possible statuses, and the difference between two of them is the most misunderstood point in the protocol. good means the responder is not aware of the certificate being revoked. revoked means it is. unknown means the responder cannot say anything about this certificate at all, usually because it is not authoritative for that issuer. RFC 6960 section 2.2 is explicit that a “good” response does not necessarily mean the certificate was ever issued or that the time is within its validity period. It means one thing only: not revoked, as far as this responder knows.

That looseness caused a real attack, and the rules closed it. Baseline Requirements section 4.9.9 now states that a responder for an unconstrained authority must not return “good” for a serial number never assigned. Before that rule, an attacker forging a certificate with an invented serial could get a cheerful “good” from the real authority’s own responder.

Four times appear in the response and they mean four different things.

The public rules bound them. A response for a subscriber certificate must have a validity interval of at least eight hours and at most ten days. Since 15 January 2025 an authoritative response must be available within fifteen minutes of issuance, which closed the window in which a brand new certificate returned “unknown”. The gap between producedAt and thisUpdate exists because of pre-production: RFC 6960 section 2.5 explicitly permits an authority to sign responses in advance and serve them from a cache, which is how a responder handles a hundred thousand requests a second without doing a hundred thousand signatures a second.

Pre-production has a cost, and RFC 6960 section 5 names it: a pre-signed response is replayable. Someone who captures a “good” response can serve it back until nextUpdate even if the certificate has since been revoked. The counter is the nonce extension, section 4.4.1, in which the client sends a random value that the responder must echo inside the signature. Nonces were updated by RFC 8954 in November 2020 and again by RFC 9654 in August 2024, which raised the maximum nonce length from 32 to 128 octets. In practice high volume responders do not process nonces, because a nonce makes every response unique and therefore uncacheable. RFC 5019, the Lightweight OCSP Profile from September 2007, formalized that trade: it tells high-volume deployments to use HTTP GET so responses cache in ordinary web caches, and to omit nonces.

The privacy leak, and the day OCSP began to die#

Every property that made OCSP work also made it a surveillance channel.

When your software checks a certificate for a website, it sends a request to a server operated by the certificate authority, in plaintext HTTP, containing the serial number that identifies that exact site, from your address, at that moment. The authority learns that somebody at your address is visiting that site. So does anybody watching the network. The certificate authority did not ask for this data and mostly does not want it, but it has it, and it can be compelled to keep it.

The volume tells you how much information that is. Let’s Encrypt reported that at peak in 2025 it was answering approximately 340 billion status requests per month, more than 140,000 per second through its content delivery network. That is a complete, real-time, per-site view of a large fraction of web browsing, sitting inside a non-profit that never wanted it.

The industry unwound it in a specific and dateable sequence.

Ballot SC-063v4, “Make OCSP Optional, Require CRLs, and Incentivize Automation”, passed the CA/Browser Forum’s server certificate working group in July 2023 by 28 votes to 1 among issuers and unanimously among browsers, with effect from 15 March 2024. It did three things at once: it made responders optional, it made published revocation lists mandatory for every public authority, and it created a defined class of short-lived certificate that needs neither. Microsoft’s root program followed in October 2024. Let’s Encrypt announced its timeline on 5 December 2024 and switched its responders off on 6 August 2025.

As of August 2026, an authority may still run a responder and some do, particularly for enterprise customers whose middleboxes expect one. But the default direction of the public web is that online status checking is a legacy mechanism being retired, and the mandatory mechanism is the very thing that OCSP was invented to replace.

Stapling, and the extension that was meant to fix everything#

Stapling moves the status check off the client’s critical path. The server fetches a signed status response for its own certificate, on its own schedule, and hands it to the client inside the handshake. The client verifies the signature against the certificate authority’s key and is done. No extra connection, no delay, no leak, no dependence on a responder being reachable from wherever the user happens to be.

The mechanism is a TLS extension. The client advertises status_request, first defined in RFC 4366 in April 2006 and carried forward in RFC 6066 in January 2011, and the server returns a response. RFC 6961, June 2013, added status_request_v2 so that a server could staple responses for the whole chain rather than only the leaf. In TLS 1.3 the machinery moved: the response travels as an extension inside the Certificate message rather than as a separate CertificateStatus message. Chapter 29 covers that message flow.

Stapling alone fixes the performance and privacy problems, not the security one. If a client asks for a stapled response and gets nothing, it faces the same choice as before: check online, or shrug. An attacker holding a stolen key simply staples nothing.

The fix for that is RFC 7633, “X.509v3 Transport Layer Security (TLS) Feature Extension”, published October 2015 and universally called must-staple. It is a certificate extension, OID 1.3.6.1.5.5.7.1.24, that lists TLS features the server has committed to using. Put status_request in it and the certificate now says, permanently and unforgeably: any client seeing this certificate without a stapled status response must reject the connection. Section 4.3.3 of that RFC states the rule in those terms.

That is a correct design. It failed in the market, and there are measurements that show exactly how.

Chung and colleagues published “Is the Web Ready for OCSP Must-Staple?” at the Internet Measurement Conference in 2018, using scans between April and September of that year. Their findings, in order of how badly each one hurts:

The extension was used by two hundredths of one per cent of certificates, almost all from a single issuer, and even ordinary stapling was running on only around a third of popular sites. The browsers did not cooperate either: the study found Firefox alone enforced must-staple on the desktop, while others did not verify that a promised response had arrived. An extension only one browser enforces protects only that browser’s users.

There were also two mundane engineering causes. Apache and nginx, which between them served most of the web, did not prefetch status responses but fetched lazily after a cache miss, so the first visitor after an expiry got a slow or failed handshake. And must-staple turns a responder outage into a site outage. Operators weighing a rare key compromise against routine downtime chose uptime every time, and it is hard to say they were wrong.

Let’s Encrypt closed the chapter on 30 January 2025 by refusing new issuance requests carrying the must-staple extension, ahead of turning off its responders entirely.

Soft-fail: what your browser actually does#

Soft-fail is the policy of treating a failed revocation check as though it had succeeded. It is not a bug and it was never accidental. It is the only policy that keeps browsers usable, and every major browser adopted some form of it.

The reason is that revocation checks fail constantly for innocent reasons. Hotel and airport networks intercept traffic before you log in, so the first check on a captive portal fails by construction. Corporate firewalls block outbound requests to unfamiliar hosts. Responders have outages, as the 2018 measurement found for over a third of them. If a failed check meant a refused connection, the web would break several times a day for users with no attacker anywhere near them.

But the consequence is the one Adam Langley wrote down on 5 February 2012 in his note on Chrome’s approach, and it is worth quoting exactly: soft-fail revocation checks are like a seat belt that snaps when you crash; even though it works ninety-nine per cent of the time, it is worthless, because it only works when you do not need it. An attacker capable of intercepting a connection is by definition capable of dropping the status request that would have exposed them.

client needs the status of serial S
    |
    +-- local filter covers S?
    |        yes -> answer now, no network, no leak
    |        no
    |
    +-- certificate carries a responder pointer?
    |        no  -> accept
    |        yes
    |
    +-- response arrives before the timeout?
             yes -> use it, honour revoked
             no  -> ACCEPT ANYWAY  (soft-fail)

Here is what the major clients do as of August 2026. The details are implementation choices, not standards, and they change.

Chrome’s own documentation states that online checks are not generally performed. Firefox enabled its complete local filter for all desktop users in Firefox 137 and disabled online status checking in Firefox 142, released in August 2025. Apple’s and Microsoft’s platform verifiers still perform online checks with a soft-fail policy and short timeouts, and both maintain additional out-of-band blocklists for emergencies. [UNVERIFIED: the precise current default revocation policy of Safari and of the Windows chain engine as of August 2026]

There is one place where hard-fail is universal and uncontroversial: intermediate and root certificates. Those are few, long-lived and catastrophic when compromised, so every browser ships a blocklist of them and enforces it absolutely. Mozilla calls its list OneCRL; Chrome folds the same function into its CRLSet. Neither depends on the network.

Pushing the answer to the client: CRLSets, OneCRL and CRLite#

If online checking cannot work, the answer must be shipped to the client in advance. Three systems do this, and they differ in ambition.

authority decides a certificate is revoked
                  |
   +--------------+--------------+
   |              |              |
publishes      answers        (certificate is
a CRL          OCSP           logged publicly)
   |              |              |
   |              |              |
aggregator crawls every CRL, cross-checks the
set of issued certificates from the logs, and
builds one compact filter
   |
browser vendor signs and pushes the filter
   |
client answers any query locally in microseconds

CRLSet is Google’s. It has existed since 2012. Chrome crawls revocation lists disclosed to the common certificate authority database and discovered through the public certificate logs, selects a subset of the revocations, and pushes the result through the browser’s component updater. The selection is the point: Chrome is explicit that CRLSets are primarily an emergency blocking mechanism, not a complete revocation feed. Mozilla’s August 2025 write-up put the coverage at roughly thirty-five thousand entries against about four million active revocations, which is on the order of one per cent. The 2017 CRLite paper measured CRLSet traffic at about 250 kilobytes per day.

OneCRL is Mozilla’s equivalent for intermediate certificates only. The same 2017 paper measured it at 357 entries and 34 kilobytes per day. It is small because it is meant to be: a list of certificate authority intermediates that must never be trusted again.

CRLite is the ambitious one, published by James Larisch, David Choffnes, Dave Levin, Bruce Maggs, Alan Mislove and Christo Wilson at the IEEE Symposium on Security and Privacy in 2017 as “CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers”. The insight is that you do not need to send the client a list, only something that answers membership questions correctly. The certificate logs give you the set of all issued certificates and the revocation lists give you the revoked ones, so you can build a cascade of Bloom filters in which each level corrects the false positives of the level above. The result answers every query about every known certificate with no false positives at all, in a fraction of the space.

The original paper reported a 10 megabyte structure covering the revocation status of over 30 million certificates, with daily updates of about 580 kilobytes. Mozilla then spent years turning that into a shipping product, and the numbers moved.

The size reduction came from an encoding called Clubcards, presented at the same conference in 2025 and reported as 54 per cent smaller than the original construction. Firefox 132 added support for it in October 2024, and Firefox 137 turned CRLite on for all desktop users. The effect was measurable in the handshake: Mozilla reported median connection time falling from 56.4 milliseconds to 39.9 milliseconds as coverage rose, because online status requests had been blocking the handshake for around 100 milliseconds at the median. The average client downloads about 300 kilobytes of revocation data per day, as a roughly 4 megabyte snapshot every 45 days plus deltas.

The 2026 study of the deployment, by Nehal Fooda and colleagues, measured effective coverage at 87.63 per cent in ninety days of telemetry, with a 1.05 per cent gap from clients that had not yet fetched a usable filter and 11.32 per cent from certificates outside what the aggregator had collected. A query costs 235 to 270 nanoseconds per filter and about 21 microseconds across the full set the client holds.

The trade is worth naming. This design gives complete, private, instant answers, and in exchange makes revocation depend on a browser vendor running a crawling and publishing pipeline for the whole internet. That is a centralization the older mechanisms did not have.

Two mass revocations: April 2014 and July 2024#

Heartbleed was the stress test nobody designed. CVE-2014-0160 was disclosed on 7 April 2014: a bug in OpenSSL’s implementation of the TLS heartbeat extension allowed a remote attacker to read memory from a server, including, potentially, its private key. Every affected operator had to assume compromise. This is the one situation the whole revocation apparatus exists for, applied to a large fraction of the web at once.

Durumeric and colleagues measured the response in “The Matter of Heartbleed”, presented at the Internet Measurement Conference in November 2014, starting with a scan 48 hours after disclosure. Their figures are the ones to remember.

Read the second and third rows together. In the month after the most widely publicized key-compromise event in the history of the web, roughly nine in ten known-vulnerable sites did not replace their certificates at all, and one in seven of those that did kept the same private key, gaining nothing.

A second paper at the same conference, by Liang Zhang and colleagues, looked at reissue and revocation specifically. Of 107,712 vulnerable certificates they identified, only 26.7 per cent had been reissued by 30 April 2014. Only about 40 per cent of the certificates reissued because of Heartbleed were subsequently revoked, meaning the majority of replaced certificates left their predecessors valid and outstanding. About 4.1 per cent of reissues reused the same key. And critically for assigning blame, 95 per cent of certificate authorities signed a fresh revocation list within 24 hours: the machinery was not the bottleneck, the humans were.

Ten years later the industry ran the experiment again from the other end. On 28 July 2024 DigiCert discovered that a defect in how it had validated domain control had affected 83,267 certificates. The twenty-four hour rule applied, with no extensions permitted. Customers, many of them large and none of them at fault, were told to replace live production certificates overnight. One, the healthcare payments company Alegeus Technologies, went to court in the United States on 29 July 2024 seeking a temporary restraining order to stop the revocation, arguing that millions of health plan participants would lose access to funds. Censys observed 33,201 affected certificates still live on public hosts on 30 July, of which only 1,652 had been revoked; by 6 August that had risen to 26,061 of 26,373 still-active certificates.

The two events point the same way from opposite sides. In 2014 the system could not get people to revoke fast enough. In 2024 it could, and the speed itself became the emergency. Neither is fixed by a better revocation protocol. Both are fixed by not needing one.

Short-lived certificates and the road to 47 days#

The structural answer is to shrink the window. If a certificate lives for seven days, then an undetected key compromise is worth at most seven days of misuse, whether or not anybody notices, whether or not any list is published, whether or not any client checks anything.

The Baseline Requirements now define a Short-lived Subscriber Certificate in section 1.6.1: for certificates issued on or after 15 March 2024 and before 15 March 2026, a validity period of ten days or less, 864,000 seconds; for those issued on or after 15 March 2026, seven days or less, 604,800 seconds. Certificates in that class are exempt from the revocation clocks in section 4.9.1.1, and section 7.1.2.11.2 makes the CRL distribution point extension optional for them. They may carry no revocation information at all, because their expiry is the revocation.

Alongside that runs the schedule everyone talks about. Ballot SC-081v3, “Introduce Schedule of Reducing Validity and Data Reuse Periods”, passed on 11 April 2025 by 25 issuer votes to none, with five abstentions, and four browser votes to none. It writes a staircase into section 6.3.2.

As of August 2026 the first step is in force: the maximum lifetime of a publicly trusted TLS certificate is 200 days, and domain validation evidence may be reused for at most 200 days. The laboratory certificate earlier in this chapter was issued for exactly 200 days for that reason.

The right-hand column matters as much as the left. Reuse of validation evidence is what lets an authority issue a new certificate without rechecking the domain, so shortening it is what makes lifetime reduction meaningful against change of control. By March 2029, evidence that you control a domain goes stale in ten days.

None of this works without automation, which is why the ballot was framed as incentivizing it. The machinery is ACME, RFC 8555, covered in chapter 28, plus one extension worth naming here: ACME Renewal Information, published as RFC 9773 in 2025, which lets the authority tell each client a suggested renewal window. That is the missing piece for mass revocation. An authority that has misissued can shorten the suggested window for exactly the affected certificates and have most of them replaced quietly, instead of revoking eighty thousand in a day and taking its customers down with them.

The honest position on the endgame: 47 days is a step, not a destination. Several browser and authority engineers have argued publicly for lifetimes measured in days, at which point revocation of subscriber certificates becomes genuinely unnecessary. As of August 2026 that is a stated direction rather than a rule, and the rule stops at 47 days from March 2029.

Revocation inside a private PKI, where the constraints invert#

Everything above is about the public web, where an authority serves strangers it cannot contact and clients it does not control. Inside one organization, running its own certificate authority for its own servers, devices and people, almost every constraint flips, and the correct engineering flips with it.

Start with size, which was the killer on the public web. A company with fifty thousand certificates has a revocation list of a few thousand entries, which at the 53 bytes per entry measured earlier is a few hundred kilobytes. The arithmetic that destroyed public CRLs does not arise, and a full list fetched by every client every few hours is entirely reasonable.

Next, freshness. Windows Active Directory Certificate Services, which is the most widely deployed private authority, supports the delta CRL mechanism of RFC 5280 section 5.2.4 properly, and a common configuration is a base list published weekly with a delta published daily or more often. Deltas are close to unused on the public web and genuinely useful here.

Now the important one: you can hard-fail. Browsers cannot refuse a connection on a failed check because they serve the general public on hostile networks. Your internal services do not. If a payroll application requires a client certificate from a company laptop on the company network, a failed revocation check is a legitimate reason to refuse: there is no captive portal, and if the check cannot complete you have a network fault you want to know about. In Windows this is the chain-building flag that treats an offline distribution point as a failure rather than as an unknown; in OpenSSL-based stacks it is whether the crl_check and crl_check_all verification flags are set.

Client certificates are where private revocation earns its keep. A departing employee’s laptop, or a device reported stolen, is exactly the case the mechanism was designed for: the population is small, the relying party is your own software, and you can make the check mandatory. Revoke, publish, and be confident it took effect.

There are two traps, and both cause outages regularly.

The first is reachability of the distribution point. The URL in the CRL distribution points extension must resolve and be fetchable from every network where a certificate will be validated. Certificates minted internally and then used by workloads in a cloud network, or by a partner across a link, routinely name a URL that exists only inside head office. The result is the worst of both worlds: every validation stalls for the client’s timeout, then either fails or silently soft-fails. Test the fetch from every network segment, not from your laptop.

The second is the expiry of the list itself. A list past its nextUpdate is not merely stale, it is invalid, and a strict verifier will reject every certificate under that issuer. Offline root authorities are the classic victim: the root is powered off in a safe, so its list must be generated by hand before the last one lapses. The Baseline Requirements demand a fresh list from a certificate-issuing authority at least every twelve months for exactly this reason.

The modern workload world sidesteps most of this. SPIFFE and its implementation SPIRE issue identity documents with lifetimes of minutes to hours and rotate them continuously, and the documentation is explicit that revocation lists are largely unnecessary at those lifetimes; a compromised trust anchor is handled by pushing a new trust bundle. That is the private version of the conclusion the public web reached, arrived at independently.

A short decision guide, and how to check your own#

For a public-facing service, the honest advice as of August 2026 is: do not plan around revocation working. Automate issuance so replacement is routine rather than an incident, keep lifetimes short, subscribe to renewal information so your authority can pull you forward when it needs to, and rehearse replacing every certificate you own under time pressure. Section 5.7.1.2 has obliged authorities to hold and annually test a mass revocation plan since 1 December 2025; you should hold the customer-side mirror of it.

For a private authority, do the opposite of the public web: pick exactly one distribution mechanism, make the check mandatory, and monitor it. A revocation check that is configured but not enforced is worse than none, because it costs latency and buys nothing.

Three commands will tell you where you stand on any certificate you can reach.

  # what revocation information does this certificate name
openssl x509 -in cert.pem -noout \
  -ext crlDistributionPoints,authorityInfoAccess

  # fetch and read the list it points at
curl -sO http://crl.example/issuer.crl
openssl crl -inform DER -in issuer.crl -noout -text \
  | head -20

  # ask a responder about one certificate
openssl ocsp -issuer chain.pem -cert cert.pem \
  -url http://ocsp.example -resp_text -no_nonce

  # does this server staple a response in the handshake
openssl s_client -connect example.com:443 -status \
  -servername example.com < /dev/null | head -30

If the first command prints a distribution point but no responder pointer, you are looking at a certificate issued under the post-2024 rules. If it prints neither, check the validity period: you may be holding a short-lived certificate that is exempt from both.

30.98 Common wrong ideas#

Wrong: A revoked certificate stops working. Right: A revoked certificate is cryptographically unchanged and will verify perfectly; it stops working only for clients that both obtain the revocation information and choose to act on it, and for most of the last decade most clients did neither.

Wrong: My browser checks every certificate against the issuing authority. Right: Chrome states in its own documentation that it does not generally perform online revocation checks, and Firefox turned online checking off in Firefox 142 in August 2025; both now answer from a list pushed to your machine in advance, which is faster, more private and, in Firefox’s case, far more complete.

Wrong: Soft-fail is a bug that browsers should fix. Right: Soft-fail is the only policy compatible with captive portals, corporate firewalls and responder outages that affected over a third of responders in 2018 measurements; the correct fix was not hard-fail but removing the network dependency altogether, which is what pushed filters do.

Wrong: OCSP is more secure than a revocation list because it is live. Right: Public responders serve pre-produced responses signed in advance and valid for up to ten days, exactly as RFC 6960 section 2.5 permits, so the freshness advantage is far smaller than it appears, and the protocol adds a plaintext disclosure of your browsing to a third party.

Wrong: A “good” OCSP response means the certificate is valid. Right: RFC 6960 section 2.2 says a “good” response only means the responder has no record of revocation; it does not assert that the certificate was ever issued, nor that the current time falls inside its validity period, and a rule had to be added forbidding “good” answers for serial numbers never assigned.

Wrong: OCSP stapling with must-staple solved this years ago. Right: Must-staple was standardized in RFC 7633 in October 2015 and measured at 0.02 per cent of certificates in 2018, with only Firefox enforcing it on desktop; it made sites fragile against responder outages, so operators declined it, and Let’s Encrypt stopped issuing it on 30 January 2025.

Wrong: Heartbleed proved that revocation works, because everyone revoked. Right: Measurements published in 2014 found that only 10.1 per cent of known-vulnerable sites replaced their certificates within a month, 14 per cent of those reused the same private key, and only about 40 per cent of Heartbleed-driven reissues were followed by a revocation at all.

Wrong: Shorter certificate lifetimes are a commercial move by certificate authorities. Right: The lifetime schedule was proposed and passed with browser support and near-unanimous authority support in April 2025, it reduces authority revenue per validation rather than increasing it, and its security rationale is precise: it caps exposure from undetected compromise and from domain transfer without depending on anyone noticing.

Wrong: Short-lived certificates mean revocation has been abolished. Right: Revocation remains mandatory for ordinary certificates and for intermediate authorities, and browsers still enforce blocklists of compromised intermediates absolutely; what changes is that certificates of seven days or less are formally exempt and need carry no revocation information at all.

Wrong: Inside a company, revocation is just as broken as on the web. Right: Almost every public-web constraint is absent internally, so mandatory checking is achievable and worthwhile; the failures that do occur are nearly always an unreachable distribution point or a list left to expire.

30.99 Chapter summary in 20 lines#

1. A certificate cannot be recalled once signed, so revocation is a separate mechanism bolted on to announce that a valid-looking certificate is dead.
2. Certificates are revoked for key compromise, for misissuance by the authority, and for change of control such as a domain changing hands.
3. The CA/Browser Forum Baseline Requirements section 4.9.1.1 sets two clocks: twenty-four hours for five triggers, five days for eleven more.
4. A certificate revocation list, defined in RFC 5280 section 5, is a signed list of serial numbers with dates and optional reason codes, nothing more.
5. Measured on a laboratory authority, each revocation entry costs about 53 bytes, so roughly four million active public revocations imply about 212 megabytes of raw list data.
6. Lists are republished on a schedule of four to seven days, so a client working from a valid cached list can be days behind reality by design.
7. OCSP, RFC 6960, replaced the download with a question about one certificate: an 87-byte request and a 1,417-byte signed answer in our test.
8. An OCSP response can say good, revoked or unknown, and “good” means only that the responder knows of no revocation, not that the certificate is fine.
9. Every online status check tells a third-party company which site you are visiting, from which address, at what moment, in plaintext.
10. Let’s Encrypt was answering about 340 billion status requests a month before it shut its responders down on 6 August 2025.
11. Ballot SC-063 made responders optional and published lists mandatory for the public web with effect from 15 March 2024.
12. Stapling moves the check to the server and fixes the delay and the leak, but not the security hole, because a missing staple is not an error.
13. RFC 7633 must-staple closes that hole and was measured at 0.02 per cent of certificates in 2018, with only Firefox enforcing it on desktop.
14. Soft-fail means a failed check is treated as a pass; it is deliberate, and it makes the check useless against exactly the attacker it was built for.
15. Chrome pushes a selective list covering on the order of one per cent of revocations; Firefox pushes a complete filter and checks nothing online.
16. CRLite, from the 2017 IEEE Symposium on Security and Privacy paper, encodes every known revocation in a filter cascade with no false positives.
17. In Firefox as of 2025 that is about 300 kilobytes of revocation data per day and a measured drop in median connection time to 39.9 milliseconds.
18. After Heartbleed only 10.1 per cent of known-vulnerable sites replaced certificates within a month and 14 per cent of those reused the same key.
19. In July 2024 DigiCert had to revoke 83,267 certificates in twenty-four hours, and a customer sought a court order to stop it.
20. The industry’s real answer is shorter lifetimes: 200 days from 15 March 2026, 100 days from 15 March 2027, and 47 days from 15 March 2029.

Chapter sources: RFC 5280 sections 5.1 to 5.3 for the CRL, its extensions and the reason codes; RFC 6960 of June 2013 for OCSP, in particular section 2.2 on response semantics, section 2.5 on pre-produced responses, sections 4.1.1 and 4.2.1 for the request and response structures, section 4.4.1 for the nonce and section 5 for replay, with RFC 2560 of June 1999 which it obsoleted, RFC 5019 of September 2007 for the lightweight profile, and RFC 8954 of November 2020 and RFC 9654 of August 2024 for the nonce extension; RFC 4366 of April 2006 and RFC 6066 of January 2011 for status_request, RFC 6961 of June 2013 for status_request_v2, RFC 7633 of October 2015 for must-staple, RFC 8555 for ACME and RFC 9773 of 2025 for ACME Renewal Information; the CA/Browser Forum Baseline Requirements version 2.2.9 effective 6 August 2026, sections 1.6.1, 4.9.1.1, 4.9.7, 4.9.9, 4.9.13, 5.7.1.2, 6.3.2, 7.1.2.11.2 and 7.2.2, with ballot SC-063v4 of July 2023 and ballot SC-081v3 passed 11 April 2025; the Microsoft Trusted Root Program requirements on CRL and OCSP; the Chromium security documentation on CRLSets; Adam Langley, “Revocation checking and Chrome’s CRL”, 5 February 2012; Larisch, Choffnes, Levin, Maggs, Mislove and Wilson, “CRLite: A Scalable System for Pushing All TLS Revocations to All Browsers”, IEEE Symposium on Security and Privacy 2017, and the Clubcards paper at the same symposium in 2025; Fooda and colleagues, “Comprehensive Revocation Checking at Scale: the Deployment of CRLite in Mozilla Firefox”, ACM SIGCOMM 2026; the Mozilla Hacks article on CRLite of August 2025; Chung and colleagues, “Is the Web Ready for OCSP Must-Staple?”, IMC 2018; Durumeric and colleagues, “The Matter of Heartbleed”, IMC 2014, and Zhang and colleagues, “Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed”, the same conference; the Let’s Encrypt posts of 7 September 2022, 23 July 2024, 5 December 2024 and 6 August 2025; the Censys analysis of the DigiCert validation incident of July and August 2024; and the SPIFFE project documentation. Laboratory values were generated with OpenSSL 3.0.13 on 18 August 2026 on a private authority trusted by nothing.