IM Engineer Study Notes
← Back to list
Security & Privacy
#인증서폐기#CRL#OCSP#OCSP Stapling#PKI
Last updated · 2026-10-24

Certificate Revocation Checking (CRL, OCSP, OCSP Stapling)

1. Overview

A. Definition

Certificate Revocation is the act by which the issuing Certificate Authority (CA) declares a public-key certificate (X.509) "invalid" when, for some reason, it can no longer be trusted even though its validity period has not yet expired. Revocation Checking is the procedure of confirming, before trusting a certificate, whether "this certificate is not on a revocation list," and its representative mechanisms are the CRL (Certificate Revocation List), OCSP (Online Certificate Status Protocol), and OCSP Stapling, which supplements OCSP in terms of performance and privacy.

In a Public Key Infrastructure (PKI), a certificate is assumed to be valid for its "validity period (notBefore~notAfter)," but in reality incidents occur before that period ends, such as a private key being leaked or issuance information changing. At that point the validity period alone offers no way to withdraw trust, so PKI provides "revocation" as an active means of withdrawing trust separate from the "validity period." That is, certificate validation is completed by two axes—signature-chain validation (trust path) and revocation checking (whether withdrawn)—and if revocation checking is missing, a fatal gap arises in which a fake server signed with a stolen key is trusted as legitimate.

The essential difficulty of revocation checking lies in the conflict between "real-time currency" and "scalability and privacy." Trust withdrawal is only effective if the fact of revocation is conveyed as quickly as possible to verifiers worldwide (browsers and clients), but having billions of clients query hundreds of millions of certificates on every connection simultaneously causes network and CA load and latency, together with the privacy problem of "who is connecting to which site" being exposed to the CA. CRL, OCSP, Stapling, CRLite, and so on, discussed below, are all results of compromising this conflict in different ways.

B. Background and Necessity

Early PKI standards (RFC 5280, etc.) first defined the CRL as a revocation mechanism. A CRL is a method in which the CA periodically distributes a signed "blacklist" that gathers the serial numbers of revoked certificates; it had the advantages of a simple structure and support for offline validation. However, as the scale of the Internet grew, CRL files themselves reached several MB and became hard to download each time, and a timeliness limitation emerged in which it took hours to days for the latest revocation information to be reflected.

To supplement this, OCSP, standardized as RFC 6960, appeared. OCSP reduced transmission volume and latency by querying and responding to the status of only one specific certificate in real time. But OCSP gave rise to a privacy problem in which the client's intended destination site is exposed directly to the CA, and an availability problem in which connection delay occurs when the OCSP responder is slow or down. Moreover, because most browsers, upon responder failure, choose Soft-fail—"letting it through for now" rather than "blocking safely"—a fundamental limitation emerged whereby an attacker who merely blocks OCSP traffic can neutralize revocation checking.

Against this background, OCSP Stapling, in which the server receives the response on the client's behalf and carries it in the TLS handshake; CRLite and CRLSets, in which the browser downloads compressed revocation information in advance; and the short-lived certificate strategy, which lowers dependence on revocation by shortening the validity period itself, were proposed in turn. From the perspective of a professional engineer, revocation checking should be understood as "a design problem with no perfect single solution, trading off security, performance, privacy, and availability to fit the situation."

In particular, because revocation checking touches the very root of Internet trust that is TLS and PKI, it has a ripple effect whereby a design change by one CA or one browser immediately affects billions of connections worldwide. Therefore the choice of revocation mechanism is treated not as a performance-optimization problem of a specific service but as an ecosystem-level governance problem decided jointly by standards bodies (IETF, CA/Browser Forum) and the major browsers and CAs. Let's Encrypt's recent abolition of OCSP and the vote to shorten validity periods change the operating practices of the whole industry for this very reason, and practitioners must continually track such upstream standards changes and reflect them proactively in their own certificate operations.

2. The Overall Structure of Revocation Checking and Revocation Reasons

Certificate revocation checking consists of a three-layer flow: issuance (CA)–distribution (validation infrastructure)–validation (client). The overall structure diagram below shows the process by which, after the CA declares a revocation, that information reaches the verifier via the CRL, OCSP, and Stapling paths. Whichever path is used, the starting point is the CA's revocation declaration, and the difference lies in "who fetches the revocation information, when, and how."

flowchart TD
  CA["Certificate Authority(CA) - revocation declaration·signing"]
  REPO["Revocation store(CRL distribution point·OCSP Responder)"]
  SERVER["Target server(TLS endpoint)"]
  CLIENT["Verifying client(browser)"]
  CA -->|"register revoked serial number"| REPO
  REPO -->|"① download full CRL list"| CLIENT
  REPO -->|"② OCSP single query·response"| CLIENT
  REPO -->|"③ server pre-fetches OCSP response"| SERVER
  SERVER -->|"③ attach response to TLS handshake(Stapling)"| CLIENT
  CLIENT -->|"judge revocation then trust·block"| CLIENT
  style CA fill:#e8f0fe,stroke:#2f6fed,stroke-width:1px
  style REPO fill:#eafbea,stroke:#2f9e44,stroke-width:1px
  style CLIENT fill:#fef3e8,stroke:#ed8f2f,stroke-width:2px

A. Situations Requiring Revocation (Revocation Reasons)

Revocation does not happen arbitrarily but is grounded in explicit reason codes (reasonCode). The most serious reason is key compromise (keyCompromise), where the private key corresponding to the certificate has been leaked or stolen. In that case an attacker can impersonate a legitimate server with that key, so immediate and broad withdrawal of trust is needed. A representative case is 2014, when the Heartbleed vulnerability in OpenSSL revealed that numerous server private keys could be exposed from memory, triggering large-scale reissuance and revocation worldwide and causing CRLs to balloon.

Other CA-operational reasons include change of issuance information (affiliationChanged), cascading revocation following revocation of a superior certificate, subscriber cessation of operations (cessationOfOperation), and misissuance (CA policy violations such as insufficient domain validation). In fact, when a certificate that a CA issued by wrongly validating domain ownership is discovered, under CA/Browser Forum rules the CA must mandatorily revoke that certificate within a set deadline (usually 24 hours to 5 days). Thus revocation is not only about security incidents but is also an institutional device that secures the accountability of the CA trust system.

Among revocation reasons, especially important is revocation of a superior (intermediate or root) CA certificate. When a superior certificate in the trust chain is revoked, all subordinate certificates issued beneath it lose trust at once, so the scope of impact spreads not to a single server but to all of the CA's subscribers. Actual cases in which an intermediate CA was ejected and distrusted from root stores due to CA operational violations show that revocation is a problem of risk management for the entire trust ecosystem beyond an individual certificate issue. Therefore an organization must make even the trustworthiness and operational track record of the CA it depends on a variable in its revocation response plan.

B. Basic Principles of Revocation Checking

Following the certificate chain, the verifier performs for each certificate both (1) "static validation" such as signature, validity period, and name constraints, and (2) "dynamic validation," namely whether it has been revoked. Inside a certificate are two extension fields that indicate where to obtain revocation information. CDP (CRL Distribution Points) points to the URL from which to fetch the CRL, and the OCSP entry of AIA (Authority Information Access) points to the URL of the OCSP responder. The verifier follows these pointers to look up the revocation information, then judges whether the target certificate's serial number has been revoked.

The core design issue here is "what to do if the lookup fails." "Hard-fail" is a safety-first policy that blocks the connection if revocation information cannot be confirmed, while "Soft-fail" is an availability-first policy that allows the connection for now. Most commercial browsers have adopted Soft-fail for reasons of user experience and availability, which leaves a structural weakness whereby an attacker who merely blocks revocation-lookup traffic can let even a revoked certificate through. This very weakness is the direct motive for the emergence of OCSP Stapling and browser-embedded revocation lists (CRLite, etc.).

The reason Soft-fail became widespread is, paradoxically, "the instability of the revocation infrastructure itself." If Hard-fail is applied when an OCSP responder or CRL distribution point is down, a large-scale outage can occur in which users worldwide cannot connect even to a legitimate server because revocation lookup is impossible. As experience accumulated of past OCSP outages at major CAs causing widespread connection failures, browsers leaned toward Soft-fail to avoid "availability incidents caused by revocation-checking failure." This choice is a realistic compromise that concedes some security, and to fill that gap the trend of separating validation from network lookup (Stapling and embedded forms) has grown stronger.

3. Revocation Checking Mechanisms

The three mechanisms differ in the division of responsibility for "who fetches the revocation information and delivers it to whom." The detailed diagram below shows the flow in which, during a TLS handshake with OCSP Stapling applied, the server receives the OCSP response on behalf of the client and attaches it. The core difference is that the step in which, under ordinary OCSP, the client queries the responder directly is performed in advance by the server instead.

sequenceDiagram
  participant R as OCSP Responder(CA)
  participant S as Web server
  participant C as Client(browser)
  S->>R: pre-query own certificate status(periodic)
  R-->>S: signed OCSP response(with validity period)
  Note over S: cache the response(prepare Staple)
  C->>S: TLS ClientHello(status_request extension)
  S-->>C: certificate + attached OCSP response(Stapled)
  Note over C: revocation confirmed by server connection alone
  C->>C: trust·block after signature·validity check

A. CRL (Certificate Revocation List)

A CRL is a list, signed with the CA's private key, that gathers the serial numbers, revocation times, and reasons of certificates the CA has revoked. The verifier downloads the CRL from the URL pointed to by the CDP and caches it, then checks whether the target certificate's serial number is in the list. Because it is signed, tampering is impossible, and once fetched it allows offline validation until the next update (nextUpdate), which is a great advantage.

Its drawbacks are scale and timeliness. A large CA's CRL may contain hundreds of thousands to millions of entries, reaching several MB in file size, and the cost for a client to download and parse all of it is high. Also, a CRL is usually updated on a cycle of hours to days, so there exists a lag in which a just-revoked certificate is not reflected in the list until the next issuance. To mitigate this there are techniques such as the Delta CRL, which contains only changes, and the Partitioned CRL, which splits into segments, but fundamentally the structural burden of "distributing the entire list" remains.

The scale problem becomes even more stark in incident situations. During Heartbleed in 2014, hundreds of thousands of certificates became revocation targets in a short period, causing some CAs' CRLs to grow rapidly and revealing that the cost of every client downloading them each time is unrealistic. This experience led to reconsidering the very premise that "the client downloads revocation information directly and in full," and became the design motive for the subsequently emerging browser-embedded (CRLite) and server-driven (Stapling) approaches.

Even so, the CRL is drawing attention again recently. A representative case is Let's Encrypt terminating its OCSP service in August 2025 and switching to providing revocation information only via CRLs. Instead of the client fetching an enormous CRL directly, by combining with the CRLite and CRLSets approaches in which the browser collects and compresses the CRLs of all CAs and embeds them, it is evolving in a direction that preserves the CRL's "offline and privacy" advantages while supplementing its "size" drawback. That is, the CRL survives as a "distribution unit," and its role is being redefined so that "network lookup at validation time" disappears.

B. OCSP (Online Certificate Status Protocol)

OCSP is a protocol in which the verifier queries the OCSP responder about the status of only a single certificate and receives a "good / revoked / unknown" response in signed form. Because there is no need to fetch the entire list, transmission volume is small, and it can respond closer to the latest state than a CRL. It operates over HTTP, and the response also has its own validity period, so it is reused at the responder or an intermediate cache.

However, OCSP has three structural weaknesses. First, privacy: because the client queries the CA about the certificate of the site it intends to connect to, the CA (or an observer on the path) can learn "who visits which site." This privacy risk was precisely the core reason Let's Encrypt abolished OCSP. Second, performance: a round-trip query to a third-party responder is needed on every new connection, increasing TLS handshake latency. Third, availability and security: when the responder is slow or down, revocation checking is effectively neutralized by Soft-fail. The attempt to mitigate these three weaknesses at once is OCSP Stapling.

Viewing the performance aspect numerically makes the problem clear. If an OCSP round-trip to a third-party responder takes tens to hundreds of milliseconds depending on network conditions, this is added directly to the overall TLS handshake latency. If hundreds of millions of users worldwide perform this round-trip on every new connection, an enormous volume of queries per second floods the responder, sharply raising the cost of ensuring availability and worsening users' perceived response speed. In the end, the paradox emerges that OCSP's design premise of "querying every time for real-time currency" becomes, in large-scale environments, a bottleneck for performance and availability instead.

C. OCSP Stapling

OCSP Stapling (the TLS Certificate Status Request extension) is a technique that moves the agent of the revocation-status query from the client to the server. The web server periodically fetches and caches in advance the OCSP response for its own certificate, then, during the TLS handshake with the client, attaches ("staples") that signed response along with the certificate. The client confirms the revocation status by connecting to the server alone, so it makes no separate query to the CA.

This transfer improves the three weaknesses simultaneously. Because the client does not query the CA directly, privacy is protected; the round-trip query disappears, reducing latency; and because the server reuses one response for countless clients, the CA responder's load decreases greatly. For example, if the OCSP response validity period is several days, the server can fetch the response only once during that period, cache it, and reuse it for millions of handshakes, effectively lowering the query volume to the CA from "the number of connections" to "the number of servers × the refresh cycle."

However, it has no effect unless the server configures Stapling, and the limitation remains that an attacker can revert to Soft-fail by "dropping" the stapled response. Also, if the server cache's response has expired but refresh fails, it may present a stale response or Stapling may break, so stable OCSP-response refresh operation on the server side is a prerequisite. What institutionally prevents this "drop-and-revert" weakness is the following Must-Staple.

D. Supplementary and Alternative Techniques (Must-Staple, CRLite, Short-lived Certificates, CT)

OCSP Must-Staple is an extension that puts a flag in the certificate stating "this certificate must be presented together with a stapled OCSP response," so that if the response is dropped the client hard-fails and blocks the connection. It fills the hole of Soft-fail, but server and CA support is limited and operational difficulty is high, so it did not come into wide use.

The browser camp drew revocation lookup entirely inside the client. Chrome's CRLSets is a method in which Google selects and aggregates important revocation entries and pushes them to the browser, while Firefox's CRLite is a method that compresses the revocation information of all CAs into a Bloom filter cascade and embeds it at the level of several MB. Both judge revocation locally without a network lookup at connection time, thereby securing privacy, performance, and availability simultaneously. However, depending on the selection and refresh cycle there may be limits to completeness and timeliness.

The engineering core of CRLite is a filter cascade structure that, in a state of knowing both "what is revoked" and "what is not revoked," stacks Bloom filters in multiple stages to repeatedly eliminate false positives. Doing so compresses hundreds of millions of revocation states losslessly into several MB while guaranteeing that the lookup result is deterministic (a definite good/revoked). This is a case of using a probabilistic data structure not for "approximate judgment" but for "exact judgment," a good example of solving the security problem of revocation checking with a computer-science approach of data structures and compression. However, since it presupposes a backend pipeline that gathers all CAs' fresh revocation information and periodically builds and distributes it, this method also carries the realistic constraint that only large-scale browser vendors can shoulder it.

The most fundamental trend is shortening the certificate validity period. If the validity period is short, risk can be resolved naturally by "soon-to-expire" rather than by revocation, lowering dependence on revocation. In April 2025, through the SC-081 vote, the CA/Browser Forum resolved to reduce the maximum validity period of publicly trusted TLS certificates in stages to 200 days in March 2026, 100 days in March 2027, and 47 days in March 2029. This presupposes automated certificate management (ACME) and means a shift of the center of gravity of revocation checking from "after-the-fact withdrawal" to "beforehand expiration." Meanwhile, Certificate Transparency (CT) is a supplementary axis that detects misissuance "after the fact" separately from revocation, making all issuance logs public so that CA misissuance can be detected.

4. Comparison of Techniques and Practical Application

The three mechanisms are not in a hierarchy of superiority but are options depending on the application environment. The core of the comparison is "location of the network lookup," "privacy," "timeliness," and "behavior upon failure," and these differences become the very basis for practical deployment. For example, a large-scale public web service catches latency and privacy with Stapling, while an environment where constant connection is difficult, such as a closed network or IoT, uses the CRL, which allows offline validation.

Category CRL OCSP OCSP Stapling
Lookup agent client(full list) client(single) server receives on behalf
Volume/latency large(several MB) small(single, round-trip) small(included in handshake)
Privacy good(destination not exposed) weak(exposed to CA) good
Timeliness low(periodic update) high high(within response validity)
Offline validation possible not possible depends on server cache
Main limitation size·lag privacy·availability server config·response drop

Looking at practical cases, global CDNs and large portals enable OCSP Stapling by default at the TLS endpoint, removing CA queries from hundreds of millions of handshakes. Conversely, Let's Encrypt abolished OCSP in 2025 and switched to a CRL + browser-embedded approach, which is the design judgment that "eliminate the privacy risk of individual queries, and delegate the distribution of revocation information to the browser's CRLite." Meanwhile, in high-assurance environments such as finance and public services where Hard-fail is required, Must-Staple or a dedicated validation server is placed to enforce "block upon validation failure." Thus the revocation strategy varies with the service's risk tolerance, connectivity, and scale.

An environment with constrained connectivity forces yet another choice. Closed networks, OT (operational technology), and IoT devices find it hard to access an external OCSP responder constantly, or even if they can, the latency and power cost is high. In such environments it is realistic to periodically push the CRL, which allows offline validation, to the device, or to operate a private CA outright with a short validity period to lower dependence on revocation. Conversely, for transactions such as payment and authentication where even a single missed revocation leads directly to monetary and legal loss, one chooses the principle of "do not proceed unless confirmed" by combining Hard-fail with Stapling, even at some sacrifice of performance. In the end, even with the same three mechanisms, the result is an entirely different deployment depending on the combination of risk, connectivity, and cost, and this judgment is precisely the design capability of a security architect.

5. Deep Dive — The Paradigm Shift in Revocation Checking

Revocation checking has been rapidly reorganized in three directions over the past few years. The first is a move toward privacy first. Let's Encrypt's abolition of OCSP (2025.08) is a symbolic event that put front and center the principle that "revocation lookup must not hand the user's browsing history to the CA," and it is influencing other CAs as well. The evaluation criterion of revocation checking has expanded from "real-time currency" to "real-time currency + privacy."

The second is a move toward short-lived certificates and automation. As validity periods shrink to 47 days by 2029 under the CA/Browser Forum's SC-081 (2025.04), the model that removed risk by relying on revocation changes to a model of "issue short and replace often." This means that ACME-based automated issuance, distribution, and replacement becomes the premise of operation, and manual certificate management becomes effectively impossible. Revocation does not disappear, but its character changes into a "last-resort safety device."

The third is internalizing validation responsibility into the client. The approach in which the browser compresses and pre-embeds revocation information, as with CRLite and CRLSets, removes the network lookup at connection time itself, catching all three hares of performance, privacy, and availability. The engineering progress of compressing hundreds of millions of revocation items into several MB with a probabilistic data structure such as the Bloom filter cascade underpins this. At the professional-engineer level, it is important to read these three trends as "the process of rearranging revocation, an after-the-fact control, into beforehand control (short-lived issuance) and distributed control (client embedding)."

6. Considerations and Implications

First, the fail policy must be designed explicitly to match the risk level. Soft-fail is realistic for a public service where availability matters, but one must recognize that it is itself a security gap and fill that gap with Stapling, Must-Staple, and embedded revocation. An environment where integrity is paramount, such as finance and defense, should choose Hard-fail but also secure high availability of the revocation infrastructure. "Leaving the behavior upon failure to the default" is the most dangerous.

Second, the revocation strategy cannot be separated from Certificate Lifecycle Management. In the era of 47-day validity, operation collapses without an ACME-based system of automated issuance, replacement, and monitoring. An organization must proactively establish a CLM platform that integrates certificate inventory, expiry alerts, automatic renewal, and failure response, unifying revocation response and replacement response into a single pipeline.

Third, privacy and regulatory compliance must be included as design elements. As with OCSP's browsing-history exposure problem, a security mechanism itself can create a privacy risk. From the perspective of privacy regulation (GDPR and Korea's Personal Information Protection Act), it is advisable to check whether the revocation-checking path exposes users' behavioral information to third parties, and to give priority to Stapling and client-embedded approaches.

Fourth, revocation must be operated as part of a PKI, observation, and response system, not as a standalone control. It becomes effective only when linked with CT log monitoring that detects misissuance early, and an incident-response (IR) procedure that enables rapid revocation and reissuance upon key compromise. In the long term, because the switch of certificate algorithms in tandem with the post-quantum cryptography (PQC) transition may trigger large-scale reissuance and revocation, prospective investment is needed to secure the processing capacity and automation level of the revocation infrastructure in advance.

Fifth, changes in standards and browser policy must be managed as a variable, not a constant. External ecosystem decisions, such as the abolition of OCSP and the shortening of validity to 47 days, are fundamentally changing organizations' certificate operations. To avoid dependence on a specific CA or a specific revocation method, one must have a multi-CA strategy and standards-based automation (ACME), and operate a governance process that periodically reviews the roadmaps of the CA/Browser Forum and the major browsers. This is a professional-engineer-level strategic task of managing the risk of the "Trust Supply Chain" beyond a technology choice.

References

In one line: Certificate revocation checking confirms trust withdrawal within the validity period via CRL (full list), OCSP (single query), and OCSP Stapling (server-attached), and amid the conflict of privacy, performance, and availability the paradigm is shifting to OCSP abolition, short-lived certificates, and browser-embedded forms (CRLite).