Say a company finds out on a Tuesday that the private key behind one of its TLS certificates has been sitting in a public repo for a month. They rotate the key, get a new certificate issued, and revoke the old one. Reasonable response.
Now look at the old certificate. The dates on it are still good through next March. The CA signature verifies fine. Nothing about the name has changed either, so every field a client can check on its own passes. The certificate does not know it was revoked, and it never will.
That gap is the reason a whole revocation system has to exist, and it is the part of PKI that SY0-701 keeps poking at.
Expired and revoked fail in completely different ways
An expired certificate is easy. The client has a clock and the certificate has a notAfter date, so the comparison happens in memory in a microsecond. Nobody has to be online for that. Nobody has to be asked.
Revocation has none of it. Where does the revocation decision actually live? At the CA, not in the certificate. So a client that wants to know has to go get that information from somewhere else. And if it cannot reach that somewhere else, it has to decide what to do about not knowing.
Hold onto that last sentence. It decides more exam questions than the acronyms do.
Three mechanisms, one question underneath
All three answer the same question: is this certificate still good? What separates them is who does the legwork, and when.
CRL, where you download the whole list
A certificate revocation list is a signed file the CA publishes with the serial numbers it has revoked. Your client downloads it and caches it, then checks whether the serial in front of it shows up on that list.
It works, and it has two costs. The list gets big at a CA of any real size; that is just volume. The other cost is staleness. A CRL is only as fresh as the last time it was published, so there is a window where a certificate is revoked in reality and still missing from the copy your client happens to be holding.
OCSP, where you ask about one certificate
The Online Certificate Status Protocol swaps the download for a question. The client sends the serial number of the one certificate it cares about to an OCSP responder, and gets a status back: good, revoked, or (when the responder has no record of that serial) unknown.
Smaller and fresher, and it introduces two new problems in the process. Every new connection now waits on a round trip to a third party before anything loads. And the CA is now receiving a running list of the sites you visit, because you asked about them one at a time.
Stapling, where the server asks first
Stapling flips who does the asking. The web server queries the OCSP responder on its own schedule, gets back a status response that the CA has timestamped and signed, and hands that response to every client during the TLS handshake.
So the client gets a fresh signed answer without ever contacting the CA. The latency is gone, and so is the privacy leak. A slow responder also stops being every visitor's problem.
So could a compromised server just staple a "good" response for a certificate that was actually revoked? It cannot. The CA signed that response, and the response carries a timestamp. The server has no way to forge either one. All it is doing is carrying somebody else's sealed note.
Soft-fail, which is where the scenario questions actually live
Here is the part that gets skipped, and it is the part that separates memorizing three acronyms from understanding the control.
So what happens when a browser cannot reach the CRL distribution point or the OCSP responder at all? In most cases it does not stop. It notes the failure and goes on to the site. That behavior is called soft-fail. It exists because the alternative, hard-fail, means the internet breaks for you every time some CA has a bad afternoon.
The consequence is uncomfortable. An attacker who is positioned to present you a stolen certificate is very often positioned to block your revocation check too, and a blocked check reads as "could not determine" rather than "do not trust." The check that was supposed to save you is the one that quietly gives up.
Stapling helps here in a way that is worth understanding. The status arrives inside the handshake you were already having, so there is no separate connection sitting out there for somebody to interfere with.
Reading these questions on the exam
A few things fall out of all of this that are worth carrying in with you.
When a scenario says a certificate was compromised and asks what to do about it, revocation is the answer and waiting for expiry is not. Certificates get issued for a year or more at a time, and "it runs out eventually" has never been an incident response.
If the complaint is handshake latency, or privacy (the CA quietly learns what you browse), or a responder outage dragging sites down with it, the answer is stapling. Those are OCSP's costs, and stapling is the fix CompTIA wants you to name.
A large environment fighting with a revocation file that will not stop growing? That one is a CRL question.
And when an answer choice tells you revocation checking will reliably stop a stolen certificate from being used, be a little suspicious of it. It stops that certificate when the check completes and the client honors what came back.
One drilling habit that costs nothing: on any certificate question, before you read the options, ask who has to do work in that scenario, and whether that work lands on the client or on the server or back at the CA. Then read the choices. They tend to sort themselves out, because these mechanisms put the work in three different places.
If you want to find out whether this material is genuinely solid for you rather than just familiar, the free diagnostic at https://secplusmastery.com/diagnostic is a decent gut check, and the lessons and question bank are at https://secplusmastery.com.
Top comments (0)