Study Guide
Certificate Validity and Revocation: CRLs and OCSP
Why certificates expire, how a certificate is withdrawn early, what a certificate revocation list and the Online Certificate Status Protocol each do, and why revocation checking is less reliable in practice than it sounds.
Lesson 6.6 Cryptography & PKI
A certificate is issued with an end date. This lesson works out why, what happens when a certificate must stop being trusted before that date, and why that turns out to be one of the weakest parts of the whole system.
Stage: Think
A lost bank card
Think it through
You lose your bank card. Its expiry date is two years away. What do you want to happen, and how would a shop’s card machine find out?
- Hint 1: Would you wait two years?
Show what happens
You want the card cancelled now, not in two years, and every card machine to learn that it has been cancelled, either by checking a list or by asking the bank. Certificates face the same problem, with the same two answers.
Think it through
Show the answer
Answer: B. To limit unnoticed harm.
To limit the harm if one is lost or stolen without anyone noticing: it stops working on its end date anyway.
Stage: Explain
Validity and expiry
Every certificate carries two dates: not before and not after. Outside that window, software will not accept it. The end date is the certificate’s expiry.
Expiry exists for good reasons.
- It limits damage. If a private key is stolen and nobody notices, the certificate still stops working on its end date.
- It keeps information current. Each renewal makes the CA check again that the applicant still controls the name.
- It retires old technology. Short lifetimes mean weak algorithms and key sizes drop out of use within a known time.
Expiry is checked by the client from the dates inside the certificate. It needs no network connection and cannot be blocked.
Check your understanding
Show the answer
Answer: C. No: the dates are in it.
No. The dates are inside the certificate, so the client checks them itself, and the check cannot be blocked.
An expired certificate is the most common certificate fault in everyday IT, and it is an availability problem as much as a security one: when a certificate expires, the service behind it stops working for everyone until it is renewed. Organisations therefore track expiry dates and, increasingly, renew automatically.
Go deeper How long may a public certificate last?
The maximum lifetime of a publicly trusted web certificate is set by the CA/Browser Forum, the body in which CAs and browser makers agree their rules. It has fallen steadily. For several years the limit was 398 days. In 2025 the Forum agreed a schedule of further cuts: 200 days for certificates issued from 15 March 2026, 100 days from 15 March 2027 and 47 days from 15 March 2029.
Lifetimes that short are practical only with automated renewal. They are also the industry’s main response to the weaknesses of revocation described below.
A private CA sets its own lifetimes.
Stage: Predict
Revocation: ending a certificate early
Revocation is the CA withdrawing a certificate before its expiry date.
Think it through
List reasons a certificate might need to be withdrawn before its expiry date.
- Hint 1: What could make the certificate’s statement no longer true?
Show what happens
The private key was, or may have been, stolen; it was issued in error; its details are no longer true; it is no longer needed; or the CA itself was compromised.
Typical reasons:
- the private key was compromised, or may have been;
- the certificate was issued in error, or to the wrong party;
- the details are no longer true: the domain was sold, or the organisation changed its name;
- the certificate is no longer needed: a server was retired, or a member of staff left;
- the CA itself was compromised, in which case its own certificate is revoked.
Think it through
Show the answer
Answer: B. Not unless it finds out.
Not unless the browser finds out. Revocation matters only when relying software learns of it.
Revoking a certificate does nothing by itself. A revocation matters only if the software relying on the certificate finds out about it. There are two standard ways to tell it.
Stage: Predict
Certificate revocation lists
A certificate revocation list (CRL) is a file, published by the CA at an address named in each certificate, listing the serial numbers of the certificates it has revoked and not yet expired. The CA signs the list, so it cannot be forged, and republishes it on a schedule, for example every day.
A client that wants to check a certificate downloads the CA’s CRL, verifies the signature and looks for the certificate’s serial number.
Think it through
Show the answer
Answer: C. It misses it.
It misses it: a list is only as fresh as its last publication.
- Strength: the client fetches one list and can check many certificates against it, without telling the CA which sites it is visiting.
- Weaknesses: the list can grow very large, and it is only as fresh as its last publication. A certificate revoked this morning is not on yesterday’s list.
A browser checks a website’s certificate, serial number 4F:A2, against a certificate revocation list. The serial numbers are invented.
- Step 1: Browser to Certificate authority. Request the listPlease send your current revocation list.
- Step 2: Certificate authority to Browser. The signed listPublished at midnight. Revoked: 2B:91, 7C:03 and several thousand more.
The browser then searches the list itself for 4F:A2. It is not there, so the certificate is accepted. The authority never learns which certificate was being checked. But if 4F:A2 was revoked at nine o’clock this morning, it is not on a list published at midnight.
Stage: Predict
Online Certificate Status Protocol
Think it through
Instead of downloading a whole list, what else could a browser do to find out whether one certificate is revoked? What would that reveal?
- Hint 1: Who would the browser have to ask?
Show what happens
Ask the CA about that one certificate. The answer is small and current, but each question tells the CA which certificate, and so which website, the browser is visiting.
The Online Certificate Status Protocol (OCSP) lets a client ask a question about one certificate. The client sends the certificate’s serial number to the CA’s OCSP responder, and the responder returns a signed answer: good, revoked or unknown.
- Strength: the answer is small and more up to date than a periodic list.
- Weaknesses: every check is a network request that can be slow, fail or be blocked, and each request tells the CA which certificate, and therefore which website, that client is looking at.
The same browser checks the same certificate by asking the certificate authority’s OCSP responder.
- Step 1: Browser to OCSP responder. Is 4F:A2 still good?One question about one certificate.
- Step 2: OCSP responder to Browser. Signed answer: revokedRevoked at 09:00 today.
The answer is up to date, so this morning’s revocation is caught and the browser refuses the site. The price is that the responder now knows which certificate, and so which website, this browser was visiting.
The same check, when the request never reaches the responder.
- Step 1: Browser to OCSP responder. Is 4F:A2 still good?The request is blocked or times out. Nothing comes back.
With no answer, most browsers carry on and accept the certificate. This is called soft-fail, and the section on the limits of revocation checking explains why it matters.
Check your understanding
Show the answer
Answer: B. Which site you are visiting
Which certificate, and therefore which website, you are looking at.
Go deeper OCSP stapling
OCSP stapling moves the request from the visitor to the server. The web server asks the responder for a signed, time-stamped answer about its own certificate and “staples” it to the handshake. The visitor’s browser gets a recent, CA-signed status without contacting the CA, which solves both the privacy and the speed problems.
Stapling works only if the server is set up to do it, and browsers have never required it widely.
Stage: Predict
CRL and OCSP compared
Think it through
Do not confuse: CRL and OCSP
- FormCRL
- A signed list of every revoked certificate, published periodically by the CA and downloaded by the client.“Here is everything we have revoked.”
- FormOCSP
- A signed answer to a question about one certificate, given by the CA’s responder on request.“Is certificate 4F:A2 still good?”
| Aspect | CRL | OCSP |
|---|---|---|
| What the client receives | The whole list | The status of one certificate |
| Freshness | As of the last publication | Close to real time |
| Size | Can be large | Small |
| Privacy | The CA does not learn which certificate is being checked | The responder learns which certificate is being checked |
| If the service is unreachable | An older copy may still be used | No answer at all |
Stage: Predict
The limits of revocation checking
Think it through
A browser cannot reach the revocation service. Should it block the site or carry on? What does an attacker gain from each choice?
- Hint 1: How often are servers slow?
Show what happens
Blocking breaks sites whenever the service is slow, so most browsers carry on. An attacker who blocks the check can then get a revoked certificate accepted.
Revocation sounds like a clean answer to a stolen key. In practice it is the weakest part of PKI, and it is important to know why.
- Soft-fail. If a browser cannot get an answer, it has to choose between blocking the site, which breaks the web whenever a CA’s server is slow, and carrying on. Most clients carry on. An attacker who is in a position to misuse a stolen certificate is often also in a position to block the revocation check.
- Freshness. A CRL published daily can be up to a day out of date. Cached OCSP answers have the same problem on a smaller scale.
- Privacy. Plain OCSP reveals browsing behaviour to the CA.
- Coverage. Many applications that use certificates, outside the main browsers, perform no revocation check at all.
The industry has responded in three ways.
- Browser-distributed lists. The major browsers collect revocations from CAs and push a compressed summary to every installation, so the check is local, private and cannot be blocked.
- A move back towards CRLs. The rules for public CAs now make CRLs mandatory and OCSP optional, and at least one large public CA has switched off its OCSP service altogether, citing privacy.
- Shorter lifetimes. If a certificate lives for only a few weeks, a missed revocation matters for only a few weeks.
The lesson for a defender is that revocation reduces risk; it does not remove it. A stolen key calls for revocation and for asking how the key was stolen.
Check your understanding
Show the answer
Answer: B. Shortened lifetimes
Shortened certificate lifetimes, alongside browser-distributed revocation lists and a move back towards CRLs.
A fictional company finds that an intruder copied the private key for its web server’s certificate, which has eight months left to run.
- Generate a new key pair on a clean server. Re-using the old key would achieve nothing.
- Request a new certificate for the new public key, with a CSR, and install it.
- Ask the CA to revoke the old certificate, giving key compromise as the reason. Its serial number goes onto the next CRL.
- Investigate how the key was reached, and fix that.
Doing nothing would leave the intruder able to impersonate the company’s site for eight months. Even after revocation, a visitor whose software does not check, or cannot reach the check, may still accept the old certificate until it expires.
Stage: Explain
Security+ terminology
The CompTIA Security+ SY0-701 exam objectives (objective 1.4) list certificate revocation lists (CRLs) and the Online Certificate Status Protocol (OCSP) under Certificates.
The objectives do not list OCSP stapling, soft-fail or certificate lifetimes; they are included here because they explain how revocation behaves in practice.
Stage: Apply
Apply it in a new situation
These questions use the lesson in situations it has not shown. For the strongest test of your understanding, come back to them on another day and answer each one at the first attempt.
Apply it
Show the answer
Answer: B. Generate a new key pair.
Generate a new key pair on a clean server, get a new certificate, revoke the old one, and investigate how the key was reached.
Apply it
Show the answer
Answer: C. An expired certificate
An expired certificate: the most common certificate fault, and an availability problem as much as a security one.
Apply it
Show the answer
Answer: C. Find the cause.
Find out how the key was stolen and fix that. Revocation reduces risk; it does not remove it.
Stage: Check
Check your understanding
These questions come from the approved revision bank. They were approved under owner-authorised delegated review: the site owner authorised the review and did not read each question individually.
Show answer
Answer: Revocation ends a certificate early; expiry is its planned end date
Every certificate has a validity period and stops being acceptable when it expires, while revocation withdraws a certificate before that date. Both apply to certificates at any level of a chain, and both are checked by the client that is deciding whether to rely on the certificate.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Certificate Validity and Revocation: CRLs and OCSP (Supplementary Study Guide explanation)
Show answer
Answer: Revoke the certificate and issue a new one for a new key pair
Revocation withdraws a certificate before its expiry, for example because its private key was compromised. Until the certificate is revoked or expires, whoever holds the copied key can present it as the company’s server, so waiting eight months is not acceptable, and a new certificate must use a new key pair. A renewed or reissued certificate for the same key pair would still vouch for a key that the intruder holds.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Certificate Validity and Revocation: CRLs and OCSP (Supplementary Study Guide explanation)
Show answer
Answer: A CRL is a published list of revoked certificates; OCSP answers a query about one certificate
A certificate revocation list (CRL) is a signed list, published periodically by a CA, of the serial numbers of certificates it has revoked, while the Online Certificate Status Protocol (OCSP) lets a client ask a responder for the current status of one certificate. Neither is a list of trusted roots or of expired certificates: both concern certificates that a CA has withdrawn early.
Revision sources: Session 9: Cryptographic Algorithms, Public Key Infrastructure and Cryptographic Solutions (Classroom session record) · Certificate Validity and Revocation: CRLs and OCSP (Supplementary Study Guide explanation)
Show answer
Answer: True
True. A certificate revocation list (CRL) is published periodically by the certificate authority, so it is only as fresh as its last publication. A client holding yesterday’s list has no way of knowing about a revocation made since, and will accept the certificate until it fetches a newer list.
Revision sources: Certificate Validity and Revocation: CRLs and OCSP (Supplementary Study Guide explanation)
Show answer
Answer: The responder learns which certificate the client is checking
An OCSP query tells the responder which certificate a client is checking, which reveals something about the sites that client visits. Downloading a full list is the characteristic of a CRL, not of OCSP. OCSP responses are signed, and the protocol concerns certificates issued by a CA, not self-signed ones.
Revision sources: Certificate Validity and Revocation: CRLs and OCSP (Supplementary Study Guide explanation)
Show answer
Answer: False
False. An OCSP query can fail or be blocked, and many clients carry on when no answer arrives. An attacker who can block the check may therefore still succeed with a revoked certificate, which is one of the operational limits of revocation checking.
Revision sources: Certificate Validity and Revocation: CRLs and OCSP (Supplementary Study Guide explanation)
Show answer
Answer: The certificate stops being accepted sooner, even if a revocation is missed
Shorter certificate lifetimes limit how long a compromised certificate stays usable. Expiry is enforced by every client from the dates in the certificate itself, so it works even where revocation checking is skipped or blocked. A certificate’s lifetime has nothing to do with the length of its key, and a CA never holds its customers’ private keys, so a renewal cannot reveal that one was copied.
Revision sources: Certificate Validity and Revocation: CRLs and OCSP (Supplementary Study Guide explanation)
Study and revision
Practise through the Cryptography & Data Protection topic. Questions cover expiry against revocation, when to revoke, CRLs against OCSP, the freshness of a list, what an OCSP query reveals, soft-fail and why short lifetimes help; three flashcards recall the main points. Most are learning-only. The questions that have been verified against CompTIA Security+ SY0-701 objective 1.4 are also in the Security+ practice track; that does not mean the lesson covers the whole of an objective, and the lesson does not establish practical experience.
Stage: Consolidate
What to remember
- Every certificate has a validity window; expiry limits damage and needs no network check.
- Revocation withdraws a certificate early, but matters only if relying software finds out.
- A CRL is a signed list of revoked serial numbers; OCSP asks about one certificate, and reveals which.
- Revocation checking often carries on when it cannot get an answer, which is why lifetimes are getting shorter.
- A stolen key needs a new key pair, a new certificate, revocation of the old one and an investigation.
Key terms
- Certificate expiry
The planned end of a certificate’s life: the “not after” date written inside it. After that date, software will not accept the certificate.
- Certificate revocation
A certificate authority withdrawing a certificate before its expiry date, for example because its private key was compromised.
- CRL (Certificate revocation list)
A signed list, published periodically by a certificate authority, of the serial numbers of certificates it has revoked.
- OCSP (Online Certificate Status Protocol)
A protocol that lets a client ask a certificate authority’s responder for the current status of one certificate.
Common misunderstandings
Expiry is the planned end date, checked from the certificate itself. Revocation is an early withdrawal by the CA, which a client must look up.
Only clients that check, and that receive an answer, will reject it. Many carry on when the check fails.
Each has costs. OCSP is fresher but reveals what is being checked and can be blocked. Public CAs are now required to publish CRLs, and OCSP is optional.
Further reading
- RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile: section 5 defines the CRL.
- RFC 6960: Online Certificate Status Protocol: the OCSP standard.
- CA/Browser Forum: Ballot SC-081v3: the schedule of shorter certificate lifetimes.
- Let’s Encrypt: Ending OCSP support in 2025: a public CA’s reasons for moving from OCSP to CRLs.
- CompTIA Security+ SY0-701 exam objectives (PDF): objective 1.4.
Lesson sources and acknowledgements
Sources and scope
- Covered in Session 9 (see the Session 9 Learning Log): certificate validity and expiration; certificate revocation; and CRLs compared with OCSP.
- Accuracy qualification: revocation checking has operational limitations, and a revoked certificate may still be accepted by a client that does not check or cannot get an answer.
- Independently checked: CRLs against RFC 5280 and OCSP against RFC 6960; the lifetime schedule against the CA/Browser Forum’s ballot SC-081; the withdrawal of an OCSP service against Let’s Encrypt’s own announcement; and the Security+ wording against the published SY0-701 objectives. These are external references, not course evidence.
- Supplementary explanation: every definition, the reasons for expiry and for revocation, the lifetime schedule, OCSP stapling, the comparison table, soft-fail and the other limits, the industry responses, the three sequence diagrams with their invented serial numbers and times, the stolen-key example and the misunderstandings. These were developed afterwards and are my explanations, not the tutor’s words.
- Guided version (published 1 November 2026, awaiting the site owner’s editorial review): the lost-bank-card opening questions, every question asked in the lesson with its feedback and hints, the application questions and the closing summary are supplementary explanation written for the Study Guide. The settings are fictional. The questions in the lesson’s steps are not revision-bank items; those in “Check your understanding” are, unchanged.
- No practical work is claimed. The company in the example is fictional. I have not revoked a certificate or operated a revocation service as part of this lesson.
The security objective of keeping systems, services and information accessible to authorised users when required.
The planned end of a certificate’s life: the “not after” date written inside it. After that date, software will not accept the certificate.
A certificate authority withdrawing a certificate before its expiry date, for example because its private key was compromised.
A measure intended to modify risk, for example by restricting access, detecting misuse or supporting recovery.
A signed list, published periodically by a certificate authority, of the serial numbers of certificates it has revoked.
A document, signed by a certificate authority, that binds a public key to the identity of its subject. The standard format is X.509.
The number of bits in a key. Each added bit doubles the number of possible keys.
The two related keys used in asymmetric cryptography: a public key and a private key. What one does, only the other can undo.
A protocol that lets a client ask a certificate authority’s responder for the current status of one certificate.
The certificate authorities, certificates, software and policies that bind public keys to identities and manage certificates through their lives.
The half of a key pair that its owner keeps secret. It decrypts data sent to the owner and creates the owner’s signatures.
A certificate authority whose root certificate is already trusted by operating systems and browsers, so that its certificates are accepted by any visitor.
The half of a key pair that can be given to anyone. It encrypts data for the key’s owner and verifies the owner’s signatures.
Uncertainty and potential harm to an organisation’s objectives, considering what could happen, how likely it is, the consequences and the organisation’s context.
Carrying on with a connection when a revocation check gets no answer, instead of blocking it.
Your progress on this lesson
Saved in this browser only. It is not sent anywhere, does not follow you to another device, and is lost if you clear this site’s data.
This browser is not allowing the site to save progress, so it will be forgotten when you leave the page.