第 6 章，共 8 章
CRLs, OCSP, stapling and transparency, and why revocation is only as good as the client's behaviour.
约 11 分钟阅读
A certificate has an expiry date, but nothing about the certificate lets its owner or its CA take it back early. If the key is stolen, or an employee leaves, or a CA makes a mistake, you need a way to tell the world that a still-unexpired certificate must not be trusted.
Three mechanisms exist, and each trades freshness against cost. None is free, which is why practice varies so much between organisations.
| Mechanism | How it works | Strength | Weakness |
|---|---|---|---|
| CRL | CA publishes a signed list of revoked serial numbers | Simple, cacheable, verifiable offline | Grows large, goes stale between publications |
| Delta CRL | A smaller list of changes since the last full CRL | Keeps clients fresher | More moving parts to publish |
| OCSP | Client asks the CA about one certificate | Per-certificate freshness | Extra request per connection, and a privacy leak |
| OCSP stapling | The server fetches the OCSP answer and sends it along | Fresh and private, no client request | Server must keep the staple current |
Certificate Transparency (CT) is not a revocation mechanism. It is a public, append-only log of certificates issued. Anyone can audit it, which makes unauthorised issuance detectable after the fact — and, in some clients, makes a certificate without a signed log entry unusable.
If a certificate is valid for 47 days and renews automatically, the window in which a stolen key is useful is much smaller, so the pressure on revocation checking drops. That is one reason maximum TLS lifetimes keep shrinking.
It does not, however, remove the need for revocation entirely. Client certificates, code signing and internal PKI still rely on it — and a compromised CA requires distrust, which is a stronger action than revoking one certificate.