Certificate Revocation List (CRL): Meaning, Purpose and Working

An SSL/TLS certificate is normally trusted until its notAfter date is reached. But there are situations where waiting for expiration is not safe. If the private key has been compromised, a certificate was issued incorrectly, ownership information has changed, or a certificate must otherwise be invalidated before its natural expiration date, the Certificate Authority needs a mechanism to tell certificate users that the certificate should no longer be trusted.

A Certificate Revocation List (CRL) is one of the mechanisms used by Public Key Infrastructure (PKI) to communicate that information. It is a digitally signed list published by a Certificate Authority or designated CRL issuer containing the serial numbers of certificates that have been revoked. A relying system can obtain an appropriate CRL, verify its authenticity and validity, and determine whether the certificate it is evaluating appears on the list. RFC 5280 defines the Internet X.509 CRL profile and describes this model in detail.

The important point is that a CRL does not replace certificate validation. It is an additional source of certificate status information. A certificate can have a valid signature, an unexpired validity period, and a trusted issuer, yet still need to be rejected because its serial number appears on a valid CRL.

What Is a Certificate Revocation List?

A Certificate Revocation List is a signed data structure published by a CA that identifies certificates revoked before their scheduled expiration. Each revoked certificate is identified primarily through its certificate serial number, allowing a relying party to determine whether a particular certificate has been withdrawn.

The CA periodically publishes updated CRLs rather than changing a single file every time a certificate is revoked. That means revocation information is distributed according to the CA’s publication schedule. RFC 5280 notes that CRLs can be issued at regular intervals such as hourly, daily, or weekly, depending on the environment and policy.

A simplified model looks like this:

Certificate Authority
        |
        | Revokes Certificate
        v
Creates / Updates CRL
        |
        | Digitally signs CRL
        v
Publishes CRL
        |
        | CRL Distribution Point
        v
Certificate-Using System
        |
        v
Checks Certificate Serial Number

The CRL itself is therefore not the certificate and does not contain a replacement certificate. Its job is to provide authoritative information that a previously issued certificate should no longer be accepted under the CA’s revocation policy.

Why Does a Certificate Need to Be Revoked?

Expiration handles planned certificate retirement, while revocation handles circumstances that require trust to end earlier. The difference is important because a compromised certificate could otherwise remain technically valid for months while an attacker continues using it.

Common reasons for revocation include:

RFC 5280 specifically identifies circumstances such as private-key compromise, changes in the relationship between the subject and CA, and changes in organizational association as reasons a certificate may need to be revoked before expiration.

This is why SSL certificate validation and revocation should be understood as separate parts of certificate trust. Validation establishes whether a certificate can be trusted according to its identity, signatures, validity and chain; revocation determines whether that previously issued certificate has subsequently been withdrawn.

How Does a Certificate Revocation List Work?

The CRL process begins when a CA accepts a valid revocation request or otherwise determines that a certificate must be revoked. The CA records the certificate’s serial number and revocation information, incorporates the change into an appropriate CRL, digitally signs the CRL, and publishes it through the designated distribution mechanism.

A certificate-using system can then retrieve the CRL and validate it before deciding whether the certificate remains acceptable. The system does not need to trust the server from which the CRL was downloaded in the same way that it trusts the CA; the CRL’s digital signature provides the cryptographic mechanism used to verify that the revocation information came from the appropriate authority. RFC 5280 specifically describes CRLs as signed data structures that can be distributed through untrusted servers and communications.

The overall process is:

1. Certificate is issued
        ↓
2. Certificate is used
        ↓
3. Revocation event occurs
        ↓
4. CA accepts / processes revocation
        ↓
5. Certificate serial number enters CRL
        ↓
6. CA signs updated CRL
        ↓
7. CRL is published
        ↓
8. Client retrieves appropriate CRL
        ↓
9. Client validates CRL
        ↓
10. Client checks certificate serial number

The critical detail is step 10. The client is not asking whether the domain appears somewhere in a revocation database. It is determining whether the specific certificate being evaluated, identified by its serial number, appears as revoked within the applicable CRL.

What Information Does a CRL Contain?

A CRL contains more than a simple list of revoked certificate numbers. It has fields that allow a relying party to determine who issued the CRL, when it was generated, how long it should be considered current, and what certificates have been revoked.

Important CRL fields include:

This structure is important because a client cannot simply download an old CRL and assume it represents the current status forever. The CRL itself has temporal information that helps the relying party determine whether the information is current enough for the validation policy being applied.

The Certificate Serial Number Is the Key Identifier

Every X.509 certificate has a serial number assigned by its issuer. The serial number is used to distinguish that certificate from other certificates issued by the same CA.

When a certificate is revoked, the CRL contains the serial number associated with that certificate. A relying party can therefore compare the serial number of the certificate being evaluated with the serial numbers contained in the CRL.

For example:

Certificate being checked

Issuer:
Example Intermediate CA

Serial Number:
52:A7:91:03:8F

The CRL may contain:

Revoked Certificates

52:A7:91:03:8F
17:3C:81:AA:20
91:4F:22:76:B8

Because the certificate’s serial number appears in the revoked set, the relying party has evidence that the certificate has been revoked.

The serial number is therefore much more important to CRL processing than the website’s domain name. Two certificates issued for the same domain can have different serial numbers and different revocation states.

What Is a CRL Distribution Point?

A certificate needs a way to tell certificate-using systems where they can obtain relevant revocation information. X.509 certificates can contain a CRL Distribution Points (CDP) extension that identifies locations where the corresponding CRL can be obtained.

A simplified relationship looks like this:

Website Certificate
        |
        | CRL Distribution Points
        v
CRL URL
        |
        v
CA's Published CRL

The CDP does not itself say whether the certificate is revoked. It provides information that can help a relying system locate the CRL that contains the relevant revocation information.

This is one reason examining a certificate’s extensions can reveal useful information about its PKI architecture. The same certificate also contains information used for other aspects of trust and chain construction, which is why understanding the certificate chain of trust is useful when troubleshooting more advanced certificate-validation problems.

What Happens When a Client Downloads a CRL?

Downloading a CRL is only the beginning of the process. A security-aware implementation needs to determine whether the CRL is appropriate for the certificate being checked and whether the CRL itself can be trusted.

A simplified validation sequence looks like this:

1. Locate the relevant CRL. The client obtains the CRL using the applicable distribution information or another configured mechanism.
2. Validate the CRL issuer. The system determines whether the CRL was issued by an authorized CRL issuer.
3. Verify the CRL signature. The digital signature is checked to ensure the CRL has not been modified and was signed by the appropriate authority.
4. Check CRL freshness. Fields such as thisUpdate and nextUpdate help determine whether the CRL is current according to the applicable policy.
5. Check the certificate serial number. The client searches the revoked-certificate entries for the certificate being evaluated.
6. Apply the result. If the certificate appears as revoked, the implementation can reject it according to its validation policy.

RFC 5280 describes CRL processing as part of certificate validation and specifies requirements around CRL issuers, signatures, scopes, update times and revoked certificate entries.

Why CRL Freshness Matters

A CRL is not necessarily updated the instant a certificate is revoked. The CA may operate a scheduled publication process, meaning a certificate could be revoked internally before that revocation appears in a newly published CRL.

This creates a fundamental timing limitation. Suppose a CA publishes a new CRL every 24 hours and revokes a certificate shortly after today’s publication. A client relying on the previous CRL may not receive the new revocation information until the next scheduled publication.

RFC 5280 explicitly recognizes this limitation and notes that the time between a revocation event and its appearance in distributed CRL information depends on the CRL issuance interval.

That does not mean the certificate is technically “valid again” during this period. It means the relying party may not yet possess the updated revocation information needed to detect the change.

What Is the Difference Between Certificate Expiration and Revocation?

Expiration and revocation are often confused because both can cause a certificate to become unacceptable, but they represent different events.

Expiration is scheduled. A certificate has a defined validity period, and when its notAfter time passes, it is no longer valid according to that validity interval.

Revocation is an early termination of trust. The CA marks the certificate as revoked before its normal expiration because continuing to trust it is no longer appropriate.

For example, imagine a certificate that expires on December 31 but whose private key is discovered on October 10 to have been copied from a compromised server. Waiting until December 31 would leave the compromised certificate potentially usable for months. Revocation exists to shorten that exposure window.

This is also why certificate lifecycle management needs to include revocation alongside issuance, renewal and deployment. Replacing a compromised certificate is not complete until the old certificate is properly retired and removed from every system that still uses it.

What Are CRL Reason Codes?

A CRL entry can contain a reason code that provides additional context about why the certificate was revoked. The reason code is useful for operational records, incident response and PKI administration, although the presence of a reason code does not turn one revoked certificate into a “more revoked” or “less revoked” certificate.

Examples include:

RFC 5280 defines the standard revocation-reason framework and the associated CRL entry structure.

For security teams, keyCompromise deserves particular attention because it indicates a potentially usable private key. Revoking the certificate alone is not sufficient incident response; the compromised key should be replaced and removed from systems where it could still be used.

What Happens After a Private Key Is Compromised?

Suppose an attacker obtains the private key corresponding to a website certificate. The certificate may still be within its validity period and may still chain correctly to a trusted CA. None of those facts remove the immediate security problem.

The organization should first contain the compromised key and determine where it was deployed. The certificate should then be revoked through the CA’s applicable process and replaced with a newly generated key pair and certificate.

The process should look like:

Private Key Compromise
        ↓
Contain / Investigate
        ↓
Generate New Key Pair
        ↓
Issue Replacement Certificate
        ↓
Deploy Replacement
        ↓
Revoke Compromised Certificate
        ↓
Verify New Certificate
        ↓
Monitor for Further Abuse

The order can vary depending on the incident, but the key principle is that revocation does not repair a compromised private key. It tells relying parties to stop trusting the certificate associated with that key. The compromised key itself must be retired.

CRL vs OCSP: Why Was OCSP Created?

CRLs have an obvious scalability problem. If a CA has issued millions of certificates, its CRL can become large because the list potentially contains many revoked certificate entries.

A client checking one certificate does not necessarily need the revocation status of millions of unrelated certificates. It needs the status of the particular certificate it is validating.

OCSP was designed around that model. Instead of downloading a potentially large list, an OCSP client sends a request identifying the certificate and receives a signed status response such as good, revoked, or unknown. RFC 6960 defines OCSP and describes it as a mechanism for determining certificate status without requiring CRLs.

The basic difference is:

The important point is that OCSP did not make CRLs obsolete at the protocol level. It provided a different mechanism for obtaining certificate status, with its own operational and privacy tradeoffs.

For a deeper comparison, CompareCheapSSL already has Certificate Revocation List vs OCSP and modern revocation mechanisms. That article goes considerably further into OCSP stapling, browser behavior, CRLSets and the industry’s movement toward shorter certificate lifetimes, so this article should be used as the foundational CRL explanation rather than duplicating that entire discussion.

What Are Delta CRLs?

A full CRL can become expensive to distribute when the CA has a large certificate population. Delta CRLs provide an incremental mechanism in which a smaller update contains changes since an applicable base CRL.

Conceptually:

Base CRL
  |
  | Contains existing revocations
  v
Delta CRL
  |
  | Contains changes
  v
Current Revocation State

Instead of repeatedly downloading a complete dataset, a relying system that supports the relevant mechanism can combine the base CRL with the applicable delta information.

RFC 5280 defines delta CRL processing and requires the combined information to accurately reflect the revocation status represented by the applicable base and delta CRLs.

Delta CRLs are therefore an optimization for distribution and update efficiency. They do not change the underlying concept of revocation: the relying party still needs an accurate view of whether the certificate has been revoked.

Why CRLs Can Become Very Large

CRL size is directly related to the CA’s issuance and revocation history, among other factors. A CA issuing enormous numbers of certificates can accumulate a substantial number of revoked certificate entries.

That creates several practical problems. Large CRLs consume bandwidth, require storage, take time to download and process, and become increasingly inefficient when a client is interested in the status of only one certificate.

Caching helps significantly because a client does not necessarily need to download the same CRL for every certificate it validates. But caching creates another tradeoff: the cached information may be older than the most recent revocation event.

This tension between freshness, size and availability is one of the fundamental reasons certificate revocation has remained a difficult part of internet PKI.

What Happens If a CRL Distribution Point Is Unreachable?

This is one of the most important practical questions about CRL checking. A client may know where the CRL should be located, but the CRL distribution point may be temporarily unavailable because of DNS problems, routing failures, firewall rules, server outages, or other network issues.

There is no universal answer that every application must follow when revocation information cannot be obtained. The behavior depends on the implementation and its security policy. Some environments can fail open, allowing certificate use when revocation status cannot be confirmed, while high-assurance environments may choose stricter behavior.

The tradeoff is straightforward:

Fail Open
    |
    +-- Better availability
    +-- Revocation status may be unknown
    +-- Security assurance is reduced

Fail Closed
    |
    +-- Stronger revocation assurance
    +-- CRL outage can block connections
    +-- Availability risk increases

This is not simply a technical bug. It is a security-versus-availability decision. RFC 5280 acknowledges that revocation mechanisms introduce operational requirements around distribution and availability, while the precise processing behavior depends on the certificate-validation environment.

Can a CRL Be Trusted if It Is Downloaded Over HTTP?

Yes, provided the CRL is correctly validated according to the applicable PKI rules. This may initially sound counterintuitive because HTTPS is normally used to protect internet communications, but a CRL does not need transport-layer confidentiality to establish its authenticity.

The important security property is the CRL’s digital signature. RFC 5280 explicitly notes that CRLs can be distributed through untrusted servers and untrusted communications because the signed CRL can be cryptographically verified by the relying party.

An attacker might be able to interfere with the delivery of a CRL, but simply modifying the CRL to remove a revoked certificate should cause signature validation to fail. This is an excellent example of why PKI relies on cryptographic signatures rather than assuming that every distribution channel is itself trustworthy.

CRL Validation Is Different From Certificate Chain Validation

Certificate chain validation determines whether a certificate can be connected through valid issuer signatures and trust relationships to an accepted trust anchor.

CRL processing answers a different question:

Has this otherwise valid certificate been revoked?

The two processes work together.

Certificate
    |
    +----> Validity Period
    |
    +----> Hostname / Identity
    |
    +----> Signature
    |
    +----> Certificate Chain
    |
    +----> Key Usage / Constraints
    |
    +----> Revocation Status
              |
              +----> CRL / Other Status Mechanism

This distinction is particularly useful when troubleshooting certificate errors. A valid chain does not automatically mean that the certificate has never been revoked, just as a certificate that appears on a CRL cannot become acceptable simply because its chain is otherwise valid.

The broader certificate-chain verification process explains the trust-path portion of this process, while CRL processing addresses the certificate’s subsequent status.

What Is a CRL Signer?

The CA that issues certificates does not always have to be the same entity that publishes and signs the CRL. PKI architectures can delegate CRL issuance to a designated CRL issuer.

This distinction matters in large or complex PKI environments because the infrastructure responsible for certificate issuance may be separated from the infrastructure responsible for publishing revocation information.

The CRL itself identifies its issuer, and the relying party must determine whether that issuer is authorized to issue the CRL for the certificates within its scope.

The 2026 IETF update RFC 10007 further clarifies a CRL-validation requirement concerning the keyUsage extension and the cRLSign bit for CRL issuer certificates. This is a good example of the fact that PKI validation rules continue to evolve even though the basic CRL concept has existed for decades.

Why Revocation Is Becoming Less Central to Web PKI

There is a larger architectural shift happening in public TLS. Traditional revocation mechanisms attempt to tell clients that a certificate issued for a relatively long validity period should no longer be trusted.

A different strategy is to make certificates valid for much shorter periods and automate renewal. If certificates are continuously replaced, the window in which a compromised certificate can remain useful is naturally reduced.

This does not eliminate revocation. Enterprise PKI, client certificates, internal systems, and certain high-assurance environments can still require explicit revocation mechanisms. But for large-scale public web PKI, shorter certificate lifetimes and automated issuance increasingly change the role that CRLs and OCSP play.

CompareCheapSSL’s certificate lifecycle management guide examines this operational shift in detail, including the growing importance of automation as certificate lifetimes become shorter.

CRL and Short-Lived Certificates Solve Different Problems

It would be incorrect to say that short-lived certificates simply “replace” CRLs in every environment.

A short-lived certificate reduces the maximum period during which an otherwise compromised certificate can remain valid. Revocation provides an explicit mechanism for ending trust before that natural expiration.

Consider two certificates:

The second certificate still might need immediate revocation if the situation is severe. But the natural expiration date places a hard limit on the certificate’s remaining lifetime.

This is why certificate automation and revocation should be considered together rather than as competing technologies. Automation makes frequent certificate replacement practical, while revocation remains an important emergency control for situations where waiting for expiration is unacceptable.

How Should Security Teams Handle Certificate Revocation?

Organizations should treat revocation as an incident-response capability rather than something that is performed only when a certificate happens to expire.

When a certificate needs to be revoked, the team should identify every endpoint using the certificate, determine whether the private key is compromised, request revocation through the appropriate CA process, issue a replacement certificate using a new key pair where compromise is suspected, deploy the replacement everywhere, and verify the production endpoints.

A practical process looks like this:

1. Identify the affected certificate. Record the serial number, hostname, issuer, expiration date and deployment locations.
2. Determine why it must be revoked. Key compromise requires a more urgent response than routine replacement.
3. Contain the affected private key. If compromise is suspected, stop relying on the key and remove it from active systems.
4. Request revocation. Follow the issuing CA’s approved revocation procedure.
5. Generate a new key pair. Do not reuse a potentially compromised private key.
6. Issue a replacement certificate. Ensure the new certificate covers the required hostnames.
7. Deploy the replacement. Update every server, load balancer, CDN, API gateway or other endpoint using the old certificate.
8. Verify externally. Check what certificate the production endpoint is actually serving.
9. Update the certificate inventory. Record the old certificate as revoked and the new certificate as active.

This final inventory step is frequently overlooked. A certificate that was revoked but remains installed on an unknown internal endpoint can become a future incident if the team later forgets why it was retired.

How Certificate Lifecycle Management Supports Revocation

Revocation is difficult at scale because organizations first need to know where the certificate is being used. If a compromised certificate exists on twenty servers and the security team knows about only fifteen, revoking the certificate does not guarantee that every affected system has been replaced.

A mature certificate inventory records the certificate’s location, owner, CA, hostname coverage, expiration, deployment status and other operational details. When a certificate must be revoked, that inventory becomes an incident-response map.

This is one of the practical reasons certificate lifecycle management goes beyond renewal reminders. Discovery, ownership, deployment tracking and revocation all belong to the same operational lifecycle.

CRL vs OCSP vs Short-Lived Certificates

The three approaches should not be treated as simple competing technologies because they address certificate status in different ways.

OCSP is formally defined by RFC 6960 as a protocol for determining certificate status without requiring CRLs, while CRL remains the standardized list-based mechanism defined in the X.509 PKI framework.

For a detailed treatment of how these mechanisms interact with modern browser behavior and public CA infrastructure, see CompareCheapSSL’s CRL vs OCSP and modern certificate revocation guide.

Common CRL Problems and Their Solutions

CRL-related failures are often difficult to diagnose because they occur beneath the normal browser interface. The browser may simply report a certificate or trust error without making it obvious that revocation information was unavailable or invalid.

CRL distribution point cannot be reached

Possible causes: DNS failure, firewall restrictions, routing problems, expired distribution infrastructure, proxy restrictions or an unavailable CA repository.

Solution: Inspect the certificate’s CRL Distribution Points, test connectivity to the referenced endpoint, verify DNS resolution and check whether the CRL itself is available and current. Do not immediately replace the website certificate without establishing whether the problem is actually the certificate or its revocation infrastructure.

CRL signature validation fails

Possible causes: Corrupted CRL, incorrect issuer information, unsupported validation behavior or an invalid signing relationship.

Solution: Obtain the CRL again, inspect its issuer and signature, and verify that the CRL issuer is authorized for the certificate population it covers. A modified CRL should not be accepted simply because it was downloaded from the expected location.

CRL is stale

Possible causes: Cached CRL past its expected update interval, publication failure or synchronization problems.

Solution: Inspect thisUpdate, nextUpdate and related CRL metadata. Confirm that the client is receiving the current CRL and investigate CA-side publication problems when the expected update is missing.

Revoked certificate is still being accepted

Possible causes: The client may not be performing CRL checking, may be using cached information, may use another revocation mechanism, or may apply a fail-open policy when status information cannot be obtained.

Solution: Determine the exact client’s revocation behavior rather than assuming every browser and operating system performs identical CRL checks. Revocation behavior is implementation- and policy-dependent.

Certificate was replaced but the old key remains deployed

Possible causes: Incomplete certificate inventory, multiple servers, load balancers, CDN caches or forgotten infrastructure.

Solution: Search all known TLS endpoints and verify the live certificate externally. A replacement certificate should not be considered fully deployed until every relevant production endpoint has been checked.

How to Inspect CRL Information in a Certificate

Advanced administrators can inspect a certificate’s extensions to determine whether it contains CRL Distribution Point information.

Using OpenSSL, you can inspect certificate extensions with:

openssl x509 -in certificate.pem -text -noout

Look for a section similar to:

X509v3 CRL Distribution Points:

    Full Name:
        URI:http://example-ca.com/crl/intermediate-ca.crl

The exact output depends on the certificate.

You can then retrieve and inspect the CRL itself using appropriate tooling. The important point is to distinguish between finding the CRL URL and validating the CRL. A URL that returns a file does not by itself prove that the file is authentic, current, correctly scoped or suitable for the certificate being evaluated.

Is Certificate Revocation Perfect?

No. Revocation has always involved a difficult tradeoff between security, availability, privacy, scalability and performance.

A perfect system would instantly tell every client whenever any certificate became compromised. It would impose no additional network overhead, expose no browsing information, never fail because of infrastructure outages, and scale to billions of certificates.

Real-world PKI cannot satisfy all of those requirements simultaneously.

CRLs provide a signed, distributable and cacheable mechanism, but their periodic nature can create delay and their size can become substantial. OCSP provides certificate-specific status information, but introduces responder infrastructure and privacy considerations. Browser-specific mechanisms add another layer of complexity.

The industry’s increasing movement toward shorter certificate lifetimes and automated renewal is partly a response to these limitations. The goal is not to make revocation irrelevant everywhere, but to reduce the amount of security responsibility placed on a mechanism that has always involved difficult operational tradeoffs.

Final Takeaway

A Certificate Revocation List is one of the fundamental mechanisms used by PKI to communicate that a certificate should no longer be trusted before its normal expiration date. It works by allowing a CA to publish a signed list containing the serial numbers of revoked certificates, which certificate-using systems can retrieve and evaluate as part of their validation process.

The mechanism is conceptually straightforward, but its real-world behavior involves important issues around publication frequency, CRL size, caching, distribution availability, signature validation and client policy. That is why CRL should not be understood simply as “a list that browsers download.”

CRL also represents only one part of the larger certificate-status ecosystem. OCSP provides a certificate-specific query mechanism, OCSP stapling changes where the status response is obtained, and modern browser ecosystems may use their own revocation distribution mechanisms. Short-lived certificates and automated renewal are also reducing the operational dependence on long-lived certificate revocation for some public web use cases.

For security teams, the practical lesson is straightforward: revocation is an emergency trust-control mechanism, not a substitute for certificate lifecycle management. When a certificate is compromised, organizations need to know where it is deployed, revoke it through the appropriate CA process, generate a replacement key pair, deploy the replacement everywhere, and verify that the old certificate is no longer being served.

The future of certificate security is therefore not simply about choosing between CRL and OCSP. It is about combining reliable PKI validation, appropriate revocation mechanisms, short certificate lifetimes, automated renewal, accurate certificate inventories and strong private-key protection so that a compromised or incorrectly issued certificate cannot remain trusted longer than necessary.

Frequently Asked Questions

What is a Certificate Revocation List?

A Certificate Revocation List is a digitally signed list published by a Certificate Authority or authorized CRL issuer containing certificates that have been revoked before their normal expiration. Revoked certificates are identified by serial number, and the CRL can include additional information such as revocation dates and reason codes.

Why would a CA revoke an SSL certificate?

A certificate can be revoked because its private key has been compromised, the certificate was mis-issued, the certificate holder’s circumstances have changed, the certificate has been superseded, or the associated service or organization is no longer operating. The exact reasons available depend on the applicable PKI policy and revocation framework.

Is a revoked certificate the same as an expired certificate?

No. An expired certificate has reached the end of its defined validity period. A revoked certificate has been withdrawn before its scheduled expiration because continued trust is no longer appropriate.

Where does a browser find a CRL?

Certificates can contain CRL Distribution Point information identifying locations from which applicable CRLs can be retrieved. The client then determines how and whether to use that information according to its certificate-validation implementation and policy.

Does every browser check CRLs directly?

No. Browser and operating-system revocation behavior varies, and many modern browsers use additional mechanisms rather than performing a full CRL download for every certificate. Therefore, website owners should not assume that publishing a CRL automatically means every browser will perform a real-time lookup against it.

What is the difference between CRL and OCSP?

CRL distributes a list of revoked certificates, while OCSP allows a client to request the status of a particular certificate. OCSP was standardized to provide a more targeted status mechanism without requiring clients to obtain potentially large CRLs.

Can a revoked certificate still appear valid?

Yes, depending on the client’s revocation-checking behavior and the availability or freshness of revocation information. Certificate validity dates and revocation status are separate concepts, and not every client necessarily has immediate access to the latest revocation information.

Does revoking a certificate revoke the private key?

No. Revocation applies to the certificate’s trust status. If the private key has been compromised, the key itself must be retired and replaced. A new certificate should normally be issued with a newly generated key pair.