skip to content

Revocation (CRL & OCSP)

12 roadmaps5 questions

Withdrawing a certificate before it expires, and why it rarely works: CRLs, OCSP, Must-Staple, and the soft-fail default that lets a revoked certificate through. Interviewers probe that gap.

part ofWeb protocols & securityoverview, primer and where to startread it →
on this pageshow

explore

questions

5

An end-entity certificate on a lift gate was revoked yesterday - what actually changed, and how would a client find out?

level: juniorimportance: must knowfreq 62%

answer

  1. the certificate bytes do not change
  2. published, not pushed
  3. a second signed statement by the issuer
  4. list or responder answer
  5. pointers: cRLDistributionPoints, id-ad-ocsp

basics

~20 s

Nothing in the certificate changed: the same bytes, the same issuer signature, the same notBefore and notAfter. The issuer publishes the withdrawal separately, as a signed revocation list or a signed responder answer, and a verifier learns of it only by fetching one.

solid answer

~40 s

A certificate is a signed statement binding a public key to a name for a fixed window. Revoking it does not alter that statement - the deployed file still parses and its issuer signature still verifies. What the issuing authority does is publish a second signed artefact: a revocation list enumerating withdrawn serial numbers, or a per-certificate status answer from a responder. The certificate points at where those live: `cRLDistributionPoints` for the list, `authorityInfoAccess` with the `id-ad-ocsp` access method for the responder. The check is the verifier's job and it is a separate network fetch, so a client that does not make it - or makes it and gets no answer - completes path validation and accepts the certificate exactly as before.

code

http · 11 lines
http
GET /crl/issuing-ca-3.crl HTTP/1.1
Host: crl.lift-pass.example
Accept: application/pkix-crl

HTTP/1.1 200 OK
Content-Type: application/pkix-crl
Content-Length: 41822
Last-Modified: Tue, 16 Sep 2026 03:00:12 GMT
Cache-Control: max-age=21600

<DER-encoded CertificateList>

go deeper

for a junior

Recall that revocation is a separate published statement, not an edit to the certificate, and that the certificate itself carries the address where that statement can be fetched.

for a middle

Explain the two artefacts - a signed list of withdrawn serial numbers, and a signed per-certificate answer - and which certificate extension points at each of them.

for a senior

Show that you treat revocation as best-effort: name the caching, the missing pointer and the failed fetch, and describe re-keying rather than revocation as the containment step after a key leak.

for a principal

Frame the trade the whole mechanism sits on: publication cannot be made reliable without making availability depend on a third party, which is why lifetime reduction, not better publication, is where estates end up.

## What a revoked certificate actually is An end-entity certificate is a signed statement by an issuing authority: *this public key belongs to this name, from `notBefore` to `notAfter`*. **Revocation is a second statement by the same authority saying the first should no longer be relied on.** It is published, not delivered. That distinction is the whole subject. The certificate installed on a lift gate's server is untouched by revocation: the same encoded bytes, the same issuer signature over the `TBSCertificate`, the same validity window printed inside it. A verifier that builds a path from that certificate to a trust anchor it already holds will find every signature in the path verifies and every name and constraint checks out. It accepts the certificate - unless it separately goes looking for the withdrawal statement and finds it. ## The two artefacts an issuer publishes RFC 5280 defines the list; RFC 6960 defines the query. They answer the same question with opposite shapes. | | revocation list | status responder answer | |---|---|---| | what it covers | every withdrawn, unexpired certificate in that list's scope | one certificate, named by a `CertID` | | pointer inside the certificate | `cRLDistributionPoints` | `authorityInfoAccess` with `id-ad-ocsp` | | size on the wire | grows with the issuer's withdrawal history | a few hundred bytes | | freshness | the issuer's publication schedule | `thisUpdate` and `nextUpdate` on the answer | | what the fetch reveals | nothing about which certificate you hold | the certificate, and therefore the site | | signed by | the issuing authority | the issuer, or a responder it authorised | Both are signed, and that matters: a verifier is not trusting the web server it is talking to, nor the host serving the list. It is checking a statement made by the same authority whose signature it already relied on for the certificate itself. ## Which "revocation" is being discussed Four different things get called revocation in one conversation, and only the first two are revocation in the RFC 5280 sense: - **an entry in a published revocation list** - the issuer has listed that serial number with a revocation date; - **a responder answering `revoked`** for that serial, with a `RevokedInfo` carrying the time it happened; - **an issuer dropped from a verifier's set of trust anchors**, so nothing beneath it builds a path any more - a different mechanism with a different owner; - **a request to the issuer asking it to revoke** - the administrative act that causes the first two, not the effect. A candidate who says "we revoked it" without saying which of these happened has not yet answered the question. ## Why the check so often has no effect Revocation is the part of public key infrastructure that most often does not work, and every reason is mundane: 1. **The fetch is optional in practice.** Many clients do not check by default, or check only the end-entity certificate and not the intermediates above it. 2. **The answer may not arrive.** The list host or the responder can be slow, unreachable, or blocked. A client that treats a failed check as a pass - the widespread default - accepts a revoked certificate. 3. **Everything is cached.** A list is valid until the issuer publishes the next one; a status answer is valid until its `nextUpdate`. A revocation that lands mid-window is invisible to anyone holding a fresh cached artefact. 4. **The certificate may carry no pointer.** RFC 5280 treats `cRLDistributionPoints` and `authorityInfoAccess` as optional extensions; public issuance profiles require at least one, but a private internal certificate may simply have neither, leaving a verifier nowhere to ask. ## What this means for an operator If a private key leaks, revoke - but do not treat revocation as containment. Assume the old certificate keeps working against some verifiers until `notAfter`, and act as if the attacker has a working certificate for that whole window: re-key, get a new certificate for the name, and keep the remaining lifetime of the compromised one as short as you can. The structural answers to this weakness - a server that delivers the status answer itself, a certificate that demands one, and lifetimes short enough that the question shrinks - all exist because publication alone was never enough.

  • A private key leaks and the certificate is revoked the same hour. Why is the incident not over?
    Because revocation only takes effect for verifiers that both look and get an answer. Clients that do not check, clients holding a cached list or a status answer that has not passed its `nextUpdate`, and clients whose check times out will all keep accepting the old certificate until its `notAfter`. Containment is re-keying and getting a new certificate for the name, with the compromised one's remaining lifetime treated as exposure.
  • What can a verifier do when a certificate carries neither a list pointer nor a responder pointer?
    Nothing, as far as status goes. RFC 5280 makes both extensions optional, so a certificate without them gives a verifier no location to fetch from. Path validation still succeeds on signatures, names and constraints, and the certificate is accepted on that basis alone. It is one reason public issuance profiles require at least one pointer, and one reason internal certificates are often effectively unrevokable.
  • Who signs the revocation artefact, and why does that matter?
    The issuing authority signs a revocation list; a status answer is signed by the issuer or by a responder the issuer authorised for that purpose. Because the verifier checks that signature, neither the host serving the list nor the server presenting the certificate can fabricate or edit a status. It also means an unsigned or wrongly signed artefact must be discarded rather than believed.

saying these in an interview costs you the question

  • Says revocation makes the certificate's issuer signature stop verifying
  • Thinks the authority pushes a withdrawal to the server holding the certificate
  • Assumes every client checks revocation on every connection
  • Treats expiry and revocation as the same state discovered the same way
  • Believes deleting the certificate from the server revokes it
  • Says a revoked certificate is rejected immediately everywhere
open as a page

Every gate on the mountain still admits a certificate the authority revoked last week - why is that the designed default, and what actually closes it?

level: seniorimportance: must knowfreq 70%

basics

~20 s

Because clients soft-fail: when a status check cannot be completed they proceed. An attacker positioned to intercept the connection can also drop the status query, so live checking stops an accident but not an adversary. What closes it is a certificate that demands a stapled answer, pre-distributed revocation data, or short lifetimes.

open as a page

An OCSP response arrives for one lift-pass certificate - what separates its protocol-level status from the certificate status it carries?

level: middleimportance: should knowfreq 44%

basics

~20 s

They are two different answers. OCSPResponseStatus reports whether the query itself worked - successful, malformedRequest, internalError, tryLater, sigRequired, unauthorized. Only a successful response carries a signed body with a per-certificate CertStatus of good, revoked or unknown.

open as a page

In TLS, what changes for revocation checking when the server fetches the signed OCSP answer itself and delivers it with its certificate?

level: middleimportance: should knowfreq 56%

basics

~20 s

The fetch moves off the client's path: the server queries the responder on a schedule and passes the responder-signed answer to the client. That removes a round trip, removes the privacy leak of the client naming the site to a third party, and survives a responder outage. It does not make an absent answer fatal.

open as a page

Why would an issuer publish a delta revocation list beside the full one, and what tells a validator the two belong together?

level: seniorimportance: nice to knowfreq 26%

basics

~20 s

A full list carries every unexpired withdrawal and only grows, which is expensive to re-fetch. A delta carries just the changes since a base list, and its critical deltaCRLIndicator extension names that base list's cRLNumber, so a validator can tell whether its cached base matches.

open as a page