Why HTTPS Certificate Revocation Still Fails: CRL, OCSP, and Modern Browser Challenges

Origin

After watching the drama "The Longest Day in Chang'an" the author dreamed of being a deputy in the Tang‑dynasty security bureau, which sparked a reflection on the tower‑based message‑passing system he had designed using RSA encryption and led him to wonder what would happen if an HTTPS private key were lost.

Questions

Who decides when an HTTPS certificate expires?

Who checks the certificate’s legality?

When is revocation triggered?

Does revocation affect performance?

How is a certificate revoked?

How does the client (browser) learn that a certificate has been revoked?

What does the HTTPS certificate validation process look like?

HTTPS Communication Process

The TLS handshake follows the TCP handshake and consists of four stages: (1) ClientHello/ServerHello exchange, (2) server sends its public‑key certificate for client validation, (3) optional client‑certificate exchange, and (4) key agreement and symmetric‑key exchange.

Abbreviations: RN – Random Number; PMS – Pre‑Master Secret; MS – Master Secret.

Certificate Integrity Verification

The client uses the CA’s RSA public key to decrypt the signature on the certificate; an invalid signature indicates tampering.

Certificate Validity Verification

Each certificate includes a start and end date set by the CA; if the current time falls outside this range the certificate is considered invalid.

Certificate Revocation Status Check

If a certificate must be revoked during its validity period, the CA notifies browsers of the revocation status. Browsers such as Chrome display NET::ERR_CERT_REVOKED and block access without offering a manual override.

Issuer Verification

Two roles exist: the issuer (the CA that holds the signing private key) and the subject (the entity whose public key is presented to the client). Browsers verify that the issuer field matches the subject field of the issuing certificate in the trust chain. Root certificates are self‑signed, so their issuer and subject are identical.

Domain/IP Scope Check

Intermediate CAs control the scope of a certificate, limiting it to specific domain names, wildcard domains, or fixed IP addresses. The DNS‑scope diagram shows how a certificate for

www.baidu.com

can cover multiple sub‑domains but not deeper levels like

a.b.example.com

when using a

.example.com

wildcard.

Policy Constraints

Legal‑policy checks are performed but are omitted here for brevity.

Certificate Revocation Detection Methods

Two main mechanisms are used:

1. Certificate Revocation Lists (CRL)

CA periodically publishes a list of revoked certificates. Browsers download the CRL from a public repository and check the certificate’s serial number against it. The drawback is the latency of CRL updates; a revoked certificate may remain trusted until the next CRL release, which can be hours, days, or weeks.

Statistical data from 2015 shows most CAs publish 30‑50 CRLs, while GoDaddy publishes over 300, with some CRLs exceeding 1 MB.

<code>[v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names
1.3.6.1.5.5.7.1.24 = DER:30:03:02:01:05
# For OpenSSL 1.1.0+ use the same block without the DER line</code>

2. Online Certificate Status Protocol (OCSP)

Browsers query an OCSP responder specified in the certificate’s extensions. The responder returns a signed status (good, revoked, unknown). OCSP provides near‑real‑time revocation information, avoiding the delay of CRLs, but each HTTPS request incurs an extra network round‑trip.

OCSP Advantages and Disadvantages

Advantage: Immediate revocation information; response size is small.

Disadvantage: Extra latency for every request and potential privacy leakage because the client reveals the certificate serial number to the OCSP server.

Derived Mechanisms

To mitigate OCSP’s drawbacks, browsers and servers use:

OCSP Stapling : The server obtains the OCSP response and includes (staples) it in the TLS handshake, eliminating the client‑side network request.

OCSP Must‑Staple : A certificate extension that forces the client to require a stapled OCSP response (hard‑fail if missing).

Browser Support for Certificate Revocation

1. Safari (macOS)

Since macOS 10.7 Safari relies on the system keychain and does not perform CRL or OCSP checks by default.

2. Internet Explorer (Windows)

Since Windows Vista, IE uses CryptoAPI to perform OCSP checks for both issuer and server certificates.

3. Firefox

All versions since 2010 support OCSP. Firefox 37 introduced OneCRL for intermediate‑certificate revocation, and newer versions offer multiple strategies (short‑lived certificates, OCSP stapling, OCSP Must‑Staple, plain OCSP with timeout, and CRLite).

4. Chrome

In 2012 Chrome stopped using CRL/OCSP and introduced its own CRLSet mechanism, which contains a limited set of revoked serial numbers (≈1 % of known revocations) and is updated infrequently, trading security for performance and privacy.

Summary

When a private key is compromised, revoking the certificate is the only mitigation, but browser support for revocation checks varies widely. Modern mechanisms such as OCSP stapling and Must‑Staple improve timeliness and privacy, yet hard‑fail vs. soft‑fail policies and network constraints still leave gaps in TLS security.