This chapter covers certificate revocation mechanisms, specifically Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP), which are essential for maintaining trust in a Public Key Infrastructure (PKI). For the SY0-701 exam, objective 1.4 (General Security Concepts) requires you to understand how these technologies work, their differences, and how attackers exploit gaps in revocation. Mastering CRL and OCSP will help you answer scenario-based questions about PKI trust, certificate validation, and real-time status checking.
Jump to a section
Imagine a nightclub where every patron must show a government-issued ID to enter. The bouncer has a master list of all valid IDs, but some IDs get revoked—maybe the person lost it, or it was stolen. The club can't check with the DMV every time someone walks in; that would take too long. Instead, the bouncer uses two methods. First, every hour, a manager prints a new list of revoked IDs (the CRL). The bouncer checks each ID against this list. But the list can be huge, and by the time it's printed, it might be outdated. Second, the club installs a direct phone line to the DMV (the OCSP responder). When a suspicious ID comes up, the bouncer calls the DMV, reads the ID number, and gets a live 'valid' or 'revoked' response. The call is fast, but the phone line can get busy. The bouncer must decide: use the printed list (which is offline but less current) or call the DMV (which is online but may have latency). In PKI, CRL is the printed list—periodically downloaded and cached; OCSP is the live call—real-time but requires network connectivity. An attacker might exploit the delay in CRL updates to use a revoked certificate, just like a patron could use a revoked ID before the next list is printed. Understanding this trade-off between timeliness and availability is key to choosing the right revocation method.
What Is Certificate Revocation and Why Does It Matter?
Certificate revocation is the process of invalidating a digital certificate before its natural expiration date. Certificates are issued by Certificate Authorities (CAs) to bind a public key to an entity (user, server, device). However, circumstances can arise where a certificate should no longer be trusted: the private key is compromised (e.g., stolen, leaked), the certificate was issued incorrectly (e.g., to the wrong domain), or the entity is no longer authorized (e.g., employee left the company). Without revocation, an attacker could use a compromised certificate to impersonate a legitimate server, sign malicious code, or decrypt communications. Revocation ensures that relying parties (browsers, email clients, VPNs) can detect and reject such certificates.
How Certificate Revocation Works Mechanically
When a CA revokes a certificate, it publishes the revocation information so that relying parties can check it. There are two primary methods: CRLs and OCSP.
#### CRL (Certificate Revocation List)
- Definition: A CRL is a time-stamped list published by a CA that contains serial numbers of revoked certificates, the date of revocation, and optionally the reason for revocation (e.g., keyCompromise, cessationOfOperation).
- Process:
1. A certificate holder or administrator reports a compromise to the CA, or the CA revokes for policy violations.
2. The CA updates its internal database and generates a new CRL.
3. The CRL is published to a distribution point (CRL Distribution Point, or CDP) specified in the certificate's CRL Distribution Points extension.
4. Relying parties (e.g., a web browser) download the CRL, cache it, and check the serial number of the certificate they are validating against the list.
5. If the serial number appears, the certificate is considered invalid.
- CRL Formats: Defined in RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile). CRLs are signed by the CA to prevent tampering.
- CRL Types:
- Full CRL: Contains all revoked certificates. Can become large.
- Delta CRL: Contains only changes since the last full CRL. Reduces download size.
- Freshest CRL: An extension pointing to delta CRLs.
- Limitations:
- Latency: CRLs are updated periodically (e.g., every 24 hours). A certificate revoked after the last CRL issuance will still be considered valid until the next CRL is downloaded.
- Size: Full CRLs can be megabytes, causing bandwidth and processing overhead.
- Availability: If the CDP is unreachable, the relying party may accept the certificate (depending on policy).
#### OCSP (Online Certificate Status Protocol)
- Definition: OCSP is a protocol that allows a relying party to query a responder (OCSP responder) for the real-time status of a specific certificate.
- Process:
1. The client (e.g., browser) sends an OCSP request containing the certificate's serial number and issuer information.
2. The OCSP responder checks its database (usually the CA's revocation database) and returns a signed response: good, revoked, or unknown.
3. The response includes a thisUpdate and nextUpdate time, allowing the client to cache the result for a short period.
- Protocol Details: Defined in RFC 6960. Uses HTTP (port 80) or HTTPS (port 443) for transport. The request is typically a GET or POST with base64-encoded DER data.
- Advantages:
- Real-time: Provides current status, reducing the window of vulnerability.
- Efficient: Only queries for a single certificate, minimizing bandwidth.
- Limitations:
- Availability: If the OCSP responder is unreachable, the client may fail open (accept the certificate) or fail closed (reject), depending on configuration. Most browsers fail open (soft-fail) to avoid breaking HTTPS.
- Privacy: The OCSP responder learns which certificates a client is validating, potentially tracking browsing habits. OCSP stapling mitigates this.
- Performance: Each query adds latency.
#### OCSP Stapling
- Definition: OCSP stapling (formally, TLS Certificate Status Request extension, RFC 6066) allows the server to send a time-stamped OCSP response along with its certificate during the TLS handshake.
- How It Works:
1. The server periodically fetches an OCSP response from the CA's responder.
2. During the TLS handshake, the server includes (staples) this response in the CertificateStatus message.
3. The client verifies the stapled response instead of making its own OCSP request.
- Benefits:
Reduces client latency (no extra round trip).
Improves privacy (the CA never sees client IPs).
Reduces load on OCSP responders.
Must-Staple: The status_request extension in the certificate (RFC 7633) tells clients that the server must provide a stapled OCSP response; otherwise, the certificate is considered invalid. This prevents downgrade attacks.
Key Components, Variants, and Standards
CRL Distribution Points (CDP): An X.509v3 extension that lists one or more URLs where the CRL can be fetched. Example: http://crl.example.com/crl.crl.
Authority Information Access (AIA): An extension that contains the URL of the OCSP responder. Example: http://ocsp.example.com.
OCSP Responder: A server that handles OCSP requests. It may be operated by the CA or a third party.
OCSP Response Signing: Responses are signed by the responder's certificate, which must be trusted by the client. The responder's certificate may be the CA's certificate or a dedicated OCSP signing certificate.
OCSP Nonce: An optional extension (RFC 6960) that adds a random number to the request to prevent replay attacks.
CRL vs. OCSP in Practice: Browsers like Chrome and Firefox use OCSP by default, but with soft-fail (if responder is down, they accept the certificate). Some organizations use CRLs for internal PKI due to simpler infrastructure.
How Attackers Exploit Revocation Gaps
Revocation Delay: Attackers can use a compromised certificate during the window between revocation and CRL update. For example, a stolen private key used to sign malware will be trusted until the next CRL is published.
OCSP Downgrade: If a client does not enforce OCSP stapling (must-staple), an attacker can suppress the OCSP request (e.g., by blocking port 80) and the client will accept the certificate due to soft-fail. This is a man-in-the-middle (MITM) attack.
CRL Poisoning: An attacker with control over a CDP could serve a forged CRL (though CRLs are signed, implementation flaws may allow injection).
OCSP Responder DDoS: Flooding the OCSP responder can cause denial of service, forcing clients to fail open.
Real Command/Tool Examples
OpenSSL: Check CRL:
openssl crl -in crl.pem -text -nooutOpenSSL: Check OCSP status:
openssl ocsp -issuer ca.pem -cert cert.pem -url http://ocsp.example.com -textcurl: Fetch CRL:
curl -O http://crl.example.com/crl.crlOCSP Stapling Test: Use openssl s_client with -status option:
echo | openssl s_client -connect example.com:443 -status 2>/dev/null | grep -A 20 'OCSP response'View Certificate Extensions:
openssl x509 -in cert.pem -text -noout | grep -A 2 'CRL Distribution Points'Summary
CRL and OCSP are the two main mechanisms for checking certificate revocation. CRL is a batch list downloaded periodically; OCSP is a real-time query. OCSP stapling improves performance and privacy. The exam tests your understanding of when to use each, their limitations, and how attackers exploit gaps. Remember: CRL is offline, OCSP is online; CRL has latency, OCSP has availability concerns; OCSP stapling fixes both latency and privacy.
Check CRL Distribution Points
When a client (e.g., browser) receives a certificate during TLS handshake, it first extracts the CRL Distribution Points (CDP) extension from the certificate. This extension contains one or more URLs pointing to where the CRL can be downloaded, typically an HTTP or LDAP URL. For example, a certificate might have `http://crl.example.com/crl.crl`. The client then attempts to fetch the CRL from the first URL. If that fails, it tries the next. This step is crucial because without a CDP, the client cannot obtain the CRL and may either fail or accept the certificate based on local policy. In logs, you might see a request to the CDP URL if network monitoring is in place. A common exam scenario: the CDP URL is unreachable, and the client must decide whether to proceed.
Download and Parse CRL
The client downloads the CRL file (a signed, time-stamped list) from the CDP. The CRL is an ASN.1 DER-encoded or PEM-encoded file signed by the CA. The client verifies the signature using the CA's public key (which it already trusts). It then parses the CRL to extract the list of revoked certificate serial numbers, revocation dates, and optional revocation reasons. The CRL also contains an `issuer` field (matching the CA that issued the certificate) and `thisUpdate` and `nextUpdate` fields indicating the validity period. If the CRL is expired or signature invalid, the client may reject the certificate. The client caches the CRL to avoid re-downloading for each connection. The cache duration is typically the difference between `nextUpdate` and `thisUpdate`. In a SOC, an analyst might see repeated CRL downloads from a single client, indicating potential cache issues.
Compare Serial Number Against CRL
The client extracts the serial number from the certificate being validated and searches the CRL for a matching entry. The serial number is a unique integer assigned by the CA. If a match is found, the certificate is considered revoked, and the client must reject the connection. If no match is found, the certificate is considered valid (assuming not expired). The CRL may contain thousands of entries; searching is O(n) if unsorted, but modern implementations use binary search or hash tables. The revocation reason (e.g., keyCompromise, affiliationChanged) is informational but does not affect the validation decision—any revocation means invalid. On the exam, a trick question might ask: 'What if the serial number is not on the CRL?' Answer: The certificate is considered valid (but still check expiration and signature).
Send OCSP Request to Responder
If the client uses OCSP instead of CRL, it extracts the Authority Information Access (AIA) extension from the certificate to find the OCSP responder URL. The client then constructs an OCSP request containing the certificate's serial number, the issuer's hash, and optionally a nonce for replay protection. The request is DER-encoded and sent via HTTP POST or GET to the responder (usually port 80 or 443). For example, a POST request to `http://ocsp.example.com` with base64-encoded data. The responder must be reachable; if not, the client applies its fail policy. In a SOC, an analyst might see HTTP requests to OCSP URLs in proxy logs. A common mistake is assuming OCSP always uses HTTPS; it can use HTTP, but responses are signed.
Process OCSP Response and Validate
The OCSP responder queries its database (often the CA's internal revocation database) and returns a signed response indicating `good` (not revoked), `revoked`, or `unknown` (if the responder doesn't know about the certificate). The response includes `thisUpdate`, `nextUpdate`, and is signed by the responder's certificate. The client verifies the signature and checks that the responder is authorized (the responder's certificate must chain to a trusted root). If the status is `revoked`, the client rejects the certificate. If `good`, it accepts. If `unknown`, behavior varies; typically, the client treats it as revoked or fails open. The client may cache the response for the period between `thisUpdate` and `nextUpdate`. On the exam, remember that OCSP responses are signed to prevent tampering, but the transport (HTTP) is not encrypted—privacy issue.
Scenario 1: Compromised Private Key in an Enterprise PKI A company uses internal certificates for VPN authentication. An employee's laptop is stolen, and the private key for their VPN certificate is considered compromised. The IT administrator revokes the certificate via the internal CA. The CA publishes a new CRL and updates the OCSP responder. However, the VPN gateway (a Cisco ASA) is configured to use CRL checking with a 24-hour cache. For the next 24 hours, the attacker could potentially use the stolen certificate to connect to the VPN because the gateway has not yet downloaded the latest CRL. The correct response: configure the VPN gateway to use OCSP with a short cache (e.g., 5 minutes) or use OCSP stapling on the client side. A common mistake: assuming that revocation is instantaneous. In reality, the window of vulnerability depends on the CRL update interval or OCSP response caching. The analyst should monitor logs for failed authentication attempts using the revoked certificate during this window.
Scenario 2: OCSP Responder DDoS Leading to Soft-Fail A major e-commerce site uses OCSP to validate customer certificates. An attacker launches a DDoS attack against the CA's OCSP responder, making it unreachable. Browsers attempting to connect to the site send OCSP requests that time out. Because most browsers are configured with soft-fail (accept certificate if OCSP is unavailable), they proceed with the connection, even if the certificate is actually revoked. The attacker could have previously compromised a certificate and now uses it during the DDoS window. The correct response: implement OCSP stapling with must-staple extension on the server side. This way, the server provides a fresh OCSP response during the TLS handshake, and the client does not need to contact the responder. The must-staple extension forces the client to reject the certificate if no stapled response is provided. A common mistake: assuming that enabling OCSP alone is sufficient; without must-staple, soft-fail can be exploited.
Scenario 3: CRL Size Overwhelming Small Devices An IoT deployment uses certificates for device authentication. The CA issues thousands of certificates, and the CRL grows to several megabytes. IoT devices with limited memory and bandwidth struggle to download and parse the full CRL every update cycle. This leads to devices either failing to validate certificates (rejecting valid ones) or skipping revocation checks entirely (security risk). The correct response: use delta CRLs to reduce download size, or switch to OCSP (which queries only one certificate). Alternatively, use OCSP stapling with the server providing the status. A common mistake: deploying CRLs without considering device constraints. The analyst should monitor CRL download times and device memory usage.
What SY0-701 Tests Objective 1.4 covers 'Explain the importance of certificate revocation' as part of Public Key Infrastructure (PKI). The exam expects you to:
Differentiate between CRL and OCSP (know the protocol names and acronyms).
Understand the purpose of revocation (compromised key, changed affiliation, superseded certificate).
Identify the components: CRL Distribution Points (CDP), Authority Information Access (AIA), OCSP responder.
Recognize the limitations: CRL latency, OCSP availability, privacy concerns.
Know OCSP stapling as a mitigation for OCSP issues.
Understand the difference between hard-fail and soft-fail policies.
Common Wrong Answers 1. 'CRL is real-time, OCSP is batch.' – Wrong; CRL is batch, OCSP is real-time. Candidates confuse the two because both involve lists. 2. 'OCSP uses port 443 always.' – Wrong; OCSP typically uses HTTP port 80, though HTTPS can be used. The exam may test that OCSP uses HTTP. 3. 'CRL is more secure than OCSP because it is offline.' – Wrong; offline means less timely, not more secure. Both have security trade-offs. 4. 'OCSP stapling eliminates the need for CRLs.' – Wrong; OCSP stapling still relies on the CA's revocation database; CRLs are still used internally.
Specific Terms and Acronyms - CDP: CRL Distribution Point. - AIA: Authority Information Access. - OCSP: Online Certificate Status Protocol (RFC 6960). - CRL: Certificate Revocation List (RFC 5280). - Must-staple: Certificate extension requiring OCSP stapling (RFC 7633). - Soft-fail: Accept certificate if revocation check fails. - Hard-fail: Reject certificate if revocation check fails.
Trick Questions - 'Which protocol provides real-time revocation status?' Answer: OCSP (not CRL). - 'What extension tells a client where to find the CRL?' Answer: CRL Distribution Points (not AIA). - 'What is the main disadvantage of CRL?' Answer: Latency (not size; size is a secondary issue). - 'How does OCSP stapling improve privacy?' Answer: The client does not contact the OCSP responder, so the CA cannot track clients.
Decision Rule for Eliminating Wrong Answers On scenario questions, first identify whether the question asks about 'timeliness' or 'availability.' If timeliness is critical (e.g., immediate revocation needed), eliminate CRL options. If availability is a concern (e.g., network may be down), eliminate OCSP without stapling. If privacy is mentioned, look for OCSP stapling. If the question mentions 'periodic download,' it's CRL. If 'real-time query,' it's OCSP.
CRL stands for Certificate Revocation List; defined in RFC 5280.
OCSP stands for Online Certificate Status Protocol; defined in RFC 6960.
CRL Distribution Points (CDP) extension tells clients where to fetch the CRL.
Authority Information Access (AIA) extension provides the OCSP responder URL.
OCSP stapling allows the server to provide a time-stamped OCSP response during TLS handshake (RFC 6066).
Must-staple extension (RFC 7633) requires OCSP stapling; without it, clients may fall back to soft-fail.
Soft-fail means accept certificate if revocation check fails; hard-fail means reject.
CRL latency is the main disadvantage; OCSP availability is the main disadvantage.
OCSP responses are signed but often sent over HTTP (port 80), not HTTPS.
Delta CRLs reduce download size by including only changes since last full CRL.
These come up on the exam all the time. Here's how to tell them apart.
CRL (Certificate Revocation List)
Batch list of all revoked certificates.
Downloaded periodically; cached by client.
Higher latency (hours to days).
Offline operation possible after download.
Large list size can be a problem.
OCSP (Online Certificate Status Protocol)
Real-time query for a single certificate.
Queried on-demand; response cached briefly.
Near real-time status.
Requires network connectivity to responder.
Small request/response size.
Mistake
CRL and OCSP are interchangeable and provide the same level of security.
Correct
They have different security profiles. CRL has a window of vulnerability due to update latency; OCSP provides near real-time status but depends on network availability. Neither is inherently more secure; the choice depends on the threat model.
Mistake
OCSP always uses HTTPS, so it is encrypted.
Correct
OCSP typically uses HTTP (port 80) for transport, though HTTPS can be used. The response is signed for integrity, but the request is sent in cleartext, revealing the certificate serial number to network observers.
Mistake
Once a certificate is revoked, it is immediately unusable.
Correct
Revocation is not instantaneous. CRL updates are periodic (hours/days), and OCSP responses may be cached. The certificate remains valid until the relying party receives the revocation information.
Mistake
CRL is always downloaded from the CA's server directly.
Correct
CRLs can be distributed via multiple CDPs, including HTTP, LDAP, or even file shares. The CDP is specified in the certificate, not necessarily the CA's own server.
Mistake
OCSP stapling is only used for server certificates.
Correct
OCSP stapling is primarily used in TLS for server certificates, but it can also be used for client certificates in some implementations (e.g., mutual TLS).
CRL (Certificate Revocation List) is a periodically published list of revoked certificate serial numbers that clients download and cache. OCSP (Online Certificate Status Protocol) is a real-time protocol where clients query a responder for the status of a specific certificate. CRL has latency but works offline after download; OCSP is near real-time but requires network access and introduces privacy concerns. On the exam, remember that CRL is batch/offline, OCSP is real-time/online.
OCSP typically uses HTTP on port 80, though it can also use HTTPS on port 443. The default is HTTP (port 80) because the response is signed and does not require encryption for integrity. However, some implementations use HTTPS for privacy. The exam may present a scenario where OCSP traffic is seen on port 80.
OCSP stapling is a TLS extension where the server fetches a time-stamped OCSP response from the CA and includes it in the TLS handshake. This eliminates the need for the client to contact the OCSP responder, reducing latency and improving privacy (the CA doesn't see client IPs). It also reduces load on the responder. Must-staple (RFC 7633) makes stapling mandatory; without it, clients may fail open if the responder is unreachable.
A CRL Distribution Point is an X.509v3 certificate extension that specifies one or more locations (URLs) where the CRL can be obtained. For example, `http://crl.example.com/crl.crl`. The client uses this to download the CRL. If the CDP is unreachable, the client may accept the certificate (soft-fail) or reject it (hard-fail), depending on policy.
Soft-fail means the client accepts the certificate if the revocation check fails (e.g., CRL download fails or OCSP responder is down). Hard-fail means the client rejects the certificate if the revocation check cannot be completed. Most browsers use soft-fail for OCSP to avoid breaking HTTPS when the responder is unavailable. Hard-fail is more secure but can cause availability issues. The exam may ask which policy is more secure (hard-fail) or more user-friendly (soft-fail).
Yes, but it is unnecessary. An expired certificate is already invalid because of its expiration date. Revocation is only meaningful for certificates that are still within their validity period. However, a CA may still revoke an expired certificate for record-keeping purposes, but relying parties typically ignore revocation status for expired certificates.
A delta CRL is a smaller list that contains only the changes (additions and removals) since the last full CRL was issued. Clients that have the full CRL can download the delta CRL to update their cache without re-downloading the entire list. This reduces bandwidth and processing time. Delta CRLs are defined in RFC 5280.
You've just covered CRL and OCSP — Certificate Revocation — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?