[{"data":1,"prerenderedAt":133},["ShallowReactive",2],{"$kqlZMUle5P6Te":3},{"code":4,"status":5,"result":6},200,"OK",{"blocks":7,"objectives":114,"title":125,"subheading":126,"intro":127,"related":128,"browser":125,"description":132},[8,15,20,25,29,34,38,42,46,50,54,58,62,66,70,74,78,82,86,90,94,98,102,106,110],{"content":9,"id":12,"isHidden":13,"type":14},{"level":10,"text":11},"h2","Certificate Revocation Explained","2ac6e0f2-6f54-4104-9ca4-ef7ed08789ca",false,"heading",{"content":16,"id":18,"isHidden":13,"type":19},{"text":17},"\u003Cp>An issued \u003Ca href=\"/ssl-certificates\">SSL/TLS certificate\u003C/a> is only valid for a clearly defined period, which has been shortening of late due to growing security concerns. That period is 200 days as of March 2026, but it will shorten further over the next couple of years. Ideally, there would be no need for a \u003Ca href=\"/learning/ssl/what-is-a-certificate-authority\">Certificate Authority (CA)\u003C/a> to intervene, but sometimes a certificate needs to be cancelled ahead of its designated \u003Ca href=\"/learning/ssl/certificate-expiration\">expiry\u003C/a>. The process of doing so is known as \u003Cstrong>certificate revocation\u003C/strong>.\u003C/p>\u003Cp>The unique challenge of certificate revocation is that SSL/TLS is widely distributed and cached across many client devices, including browsers and servers. Revoking a certificate does not mean it will stop working, and there needs to be an active monitoring mechanism in place so clients know it’s been cancelled. That’s where revocation checking comes into the picture.\u003C/p>","3b48018a-1da6-4365-b91a-632507a2f456","text",{"content":21,"id":24,"isHidden":13,"type":14},{"level":22,"text":23},"h3","Reasons for Certificate Revocation","1477a1f8-180a-48b9-ab70-acd73164ac49",{"content":26,"id":28,"isHidden":13,"type":19},{"text":27},"\u003Cp>There are several reasons why a CA might need to revoke an SSL/TLS certificate:\u003C/p>","c7345c76-eea8-41dd-aa6b-de08b640bdff",{"content":30,"id":32,"isHidden":13,"type":33},{"text":31},"\u003Cul>\u003Cli>Improper issuance process: certificates get revoked if the CA decides the verification process was mishandled.\u003C/li>\u003Cli>Private key compromise: if a private key is compromised in any way (e.g., stolen or leaked), the CA will revoke the certificate immediately.\u003C/li>\u003Cli>Organisation detail changes: if the organisation named in the certificate changes its legal structure or no longer controls the relevant domain, the CA will revoke the certificate.\u003C/li>\u003Cli>High-level CA compromise: Certificate Authorities themselves can and have been compromised in the past, which leads to bulk certificate revocation.\u003C/li>\u003C/ul>","2aa26282-872b-4c5c-9d68-7bae771817d8","list",{"content":35,"id":37,"isHidden":13,"type":14},{"level":10,"text":36},"Certificate Revocation Lists (CRLs)","93a84c77-d1da-4e09-972b-407c7ba91a12",{"content":39,"id":41,"isHidden":13,"type":19},{"text":40},"\u003Cp>Certificate Revocation Lists were the original revocation-signalling mechanism, consisting of signed lists of revoked certificate serial numbers that CAs would publish and distribute for reference. URLs linking to these lists were embedded in newly issued certificates via the CRL Distribution Point.\u003C/p>\u003Cp>Clients and browsers connecting to the CA’s server to receive an SSL/TLS certificate could also download and reference the CRL to check if the certificate appeared on the list. If it did, the connection would be rejected, preventing the revoked item from affecting the machine.\u003C/p>\u003Cp>In theory, CRLs did their job well enough, but were at a disadvantage due to the scale of the contemporary Internet. They could balloon up to a size of several megabytes, necessarily included unimportant data, increased page load times, could be out-of-date, and would end up being totally inaccessible if the CRL Distribution Point was down. It was these limitations that led to the establishment of OCSP.\u003C/p>","2d1b2283-cc2d-49e3-8f66-5593fd8660d2",{"content":43,"id":45,"isHidden":13,"type":14},{"level":10,"text":44},"Online Certificate Status Protocol (OCSP)","b6f49d6e-a800-4184-b80e-28718415dc1d",{"content":47,"id":49,"isHidden":13,"type":19},{"text":48},"\u003Cp>The Online Certificate Status Protocol was defined in RFC 6960 and is an Internet security protocol that allows a client to query a CA’s server about the status of a particular SSL/TLS certificate. The server in question is an OCSP Responder that provides one of three possible responses: good, revoked, or unknown.\u003C/p>\u003Cp>Whereas the entirety of an up-to-date CRL had to be embedded in a fresh certificate before, it now only includes an embedded URL referencing only that one SSL/TLS and nothing else. This is accomplished via the Authority Information Access (AIA) extension.\u003C/p>","f9f7211e-83b5-4f95-bd75-e57af1189eb8",{"content":51,"id":53,"isHidden":13,"type":14},{"level":22,"text":52},"How does the OCSP work?","551afac4-4dcd-473b-9761-2ed328486148",{"content":55,"id":57,"isHidden":13,"type":33},{"text":56},"\u003Cul>\u003Cli>The browser or client device connects to a web server and receives its SSL/TLS.\u003C/li>\u003Cli>The OCSP Responder’s URL is extracted from the SSL/TLS certificate.\u003C/li>\u003Cli>The browser queries the OCSP Responder to check the SSL/TLS’s serial number.\u003C/li>\u003Cli>The OCSP Responder returns a response: good, revoked, or unknown.\u003C/li>\u003C/ul>","33749b6c-8656-476b-8a2d-b69fada9cc42",{"content":59,"id":61,"isHidden":13,"type":19},{"text":60},"\u003Cp>Though basic OCSP queries do reveal some user information to the Certificate Authority, the efficiency gains were too substantial to be ignored. Specifically, baseline OCSP determines which websites the user is accessing, which is an obvious privacy concern because more information is collected. That’s where OCSP Stapling comes into the picture.\u003C/p>","330c7bca-7c0c-45f7-8b74-fc73bf59f46f",{"content":63,"id":65,"isHidden":13,"type":14},{"level":22,"text":64},"What is OCSP Stapling?","6fe29b44-b378-404b-8f6a-366390d39874",{"content":67,"id":69,"isHidden":13,"type":19},{"text":68},"\u003Cp>OCSP Stapling is a TLS handshake extension that makes the web server itself, rather than the client device, responsible for the OCSP checkup. The server periodically queries the Responder on its own behalf and staples the signed, time-stamped OCSP response to the TLS handshake.\u003C/p>\u003Cp>The effect is that, upon connecting to the server, the client receives both the certificate and a prefetch of the OCSP response in a single data exchange. This prefetch massively speeds up and simplifies the process, confirming the authenticity and recency of the certificate in a single step.\u003C/p>\u003Cp>In addition to performance gains, OCSP stapling also nullifies the aforementioned privacy concerns. With it, the browser can verify the stapled response using the CA’s public key without disclosing the user’s browsing information to the OCSP.\u003C/p>","73387773-1242-4e1a-9e8a-da4ba1e733e9",{"content":71,"id":73,"isHidden":13,"type":14},{"level":22,"text":72},"Advantages of OCSP","8a44325a-5ba4-4a99-b0db-2ce5512a0015",{"content":75,"id":77,"isHidden":13,"type":33},{"text":76},"\u003Cul>\u003Cli>SSL/TLS status is prefetched for the handshake; no extra client requests are necessary.\u003C/li>\u003Cli>CA only sees requests for prefetching from web servers, not from clients.\u003C/li>\u003Cli>The server has a cached response ready for immediate serving to client devices.\u003C/li>\u003Cli>In case of an OCSP Responder failure, the server continues to provide the latest cached response.\u003C/li>\u003C/ul>","892d91b3-9423-40d9-83c7-5a73c31cfb9e",{"content":79,"id":81,"isHidden":13,"type":19},{"text":80},"\u003Cp>OCSP Stapling is generally considered to be the recommended deployment model for the technology. Nginx, Apache, and IIS all have configuration directives to enable it, making it ubiquitous.\u003C/p>","8d756c19-9d71-4ac7-ab87-7faa65d7fc06",{"content":83,"id":85,"isHidden":13,"type":14},{"level":22,"text":84},"What is OCSP Must-Staple","47fe11f2-56d8-4133-99bd-9be922a5bf85",{"content":87,"id":89,"isHidden":13,"type":19},{"text":88},"\u003Cp>As defined in RFC 7633, OCSP Must-Staple is an optional certificate extension that instructs browsers to require a stapled OCSP response when a server connection is established. Should the server present a Must-Staple certificate without a valid stapled response, the browser must reject the connection rather than soft-fail it.\u003C/p>\u003Cp>Must-Staple is in place to address the concern that OCSP checking is optional, rather than mandatory in most current implementations of the standard. An SSL/TLS certificate equipped with the Must-Staple extension hardens the process at the cost of operational complexity.\u003C/p>\u003Cp>Misconfigured servers, unreachable OCSP Responders, and expired (and unrefreshed) stapled responses under Must-Staple will lead to blocked access. In practice, this means OCSP Must-Staple is best used for high-security deployments where the added operational risk is well justified.\u003C/p>","135a42da-7ef2-460f-a943-13b9696944fb",{"content":91,"id":93,"isHidden":13,"type":14},{"level":22,"text":92},"Hard-Fail and Soft-Fail","da2efa0c-f0ef-49a8-a819-24efb1a6dde9",{"content":95,"id":97,"isHidden":13,"type":19},{"text":96},"\u003Cp>Handling of failure cases is a weak point in the current version of revocation checking. If the OCSP Responder is inaccessible, the client or browser needs to decide how to handle the situation, and there are two options at its disposal:\u003C/p>","6c48d4cd-f25a-4e6c-9391-8d8c732b4501",{"content":99,"id":101,"isHidden":13,"type":33},{"text":100},"\u003Cul>\u003Cli>Hard-Fail: Connection is rejected entirely, providing a solid security guarantee at the cost of reliability.\u003C/li>\u003Cli>Soft-Fail: Connection is accepted, granting users access to the server with the added risk of ineffective revocation checking.\u003C/li>\u003C/ul>","f62bc017-c57f-4df1-8854-8eb714754e4c",{"content":103,"id":105,"isHidden":13,"type":19},{"text":104},"\u003Cp>Most browsers serve a Soft-Fail state by default, with their own custom revocation lists supplementing high-priority revocations.\u003C/p>","70b1e9e3-fceb-4fe2-bf80-2895cd184820",{"content":107,"id":109,"isHidden":13,"type":14},{"level":10,"text":108},"To Summarise","c5dcb07c-e6a8-4157-a582-fdf0899b2a8d",{"content":111,"id":113,"isHidden":13,"type":19},{"text":112},"\u003Cp>Certificate revocation is the mechanism of choice for PKI ecosystem responses to untrustworthy certificates. CRLs provided the operational foundation for modern-day OCSP models, which offer improved performance, security, and utility. OCSP Stapling further addresses the privacy and performance costs of client-side OCSP querying by moving the responsibility to the servers being accessed. Each iteration improves on the last, with Soft-Fail currently handling the point of contention.\u003C/p>","05302e4c-1da6-4017-8ded-02464b896572",[115,117,119,121,123],{"text":116},"The need for premature invalidation",{"text":118},"Understand Certificate Revocation Lists (CRLs)",{"text":120},"Explain what OCSP is",{"text":122},"Describe OCSP Stapling",{"text":124},"nderstand soft-fail and hard-fail revocation","What is OCSP, Certificate Revocation?","How browsers check the validity of an SSL/TLS certificate.","",[129],{"uri":130,"title":131,"shorttitle":127},"learning/ssl/certificate-expiration","What Happens When an SSL Certificate Expires?","An easy-to-read guide to learn about Certificate Revocation, OCSP, CRLs, Stapling and how it all works together.",1780632420287]