SSL Toolkit Logo

Revocation Reason Decoder

Check CRL distribution points and OCSP responder URLs

About Certificate Revocation

Certificate revocation is the process of invalidating a TLS certificate before its expiration date. Revocation can occur for several reasons including key compromise, CA compromise, or cessation of operation. Certificate Authorities publish revocation information through CRL (Certificate Revocation List) distribution points and OCSP (Online Certificate Status Protocol) responders. Our Revocation Reason Decoder extracts these details from any TLS certificate, helping you understand how revocation is handled.

How to Use

  1. Enter the domain name of the server hosting the certificate.
  2. Specify the port number if needed (default is 443).
  3. Click Check to fetch the certificate and decode its revocation information.
  4. Review the CRL distribution points, OCSP responder URLs, and any revocation reason codes.

Use Cases

  • Revocation Infrastructure Verification: Ensure certificates include valid CRL and OCSP endpoints for revocation checking.
  • Incident Investigation: Determine why a certificate was revoked by decoding the revocation reason.
  • CA Evaluation: Compare how different CAs handle revocation and what information they provide in their certificates.
  • Compliance Auditing: Verify that certificates meet organizational requirements for revocation reporting.

Frequently Asked Questions

A CRL Distribution Point (CRL DP) is a URL in a certificate that points to the location where the Certificate Revocation List is published. Clients use this URL to download the CRL and check if a certificate has been revoked.
Common revocation reasons include: key compromise (the private key was exposed), CA compromise (the CA's private key was compromised), affiliation changed (the subject left the organization), superseded (a new certificate was issued), and cessation of operation (the service was discontinued).
You can check revocation status by querying the CRL Distribution Point or OCSP responder URL found in the certificate. Use our CRL Checker or OCSP Checker tools for real-time revocation status verification.
The private key may have escaped, so every certificate signed with it must be treated as compromised. It is the most serious revocation reason and it is not host-specific: if the same key issued certificates for several domains, all of them need replacing and all deployments using it need checking. The response is reissue from a fresh key everywhere, not just revoke and redeploy the same key.
Usually not. It means the issuer stopped using the certificate for its original purpose, typically because it expired or was superseded — routine lifecycle events. The exception is a shared key: if the same key signed certificates for other hosts, those are covered by the same revocation and may need attention too. The key question is always whether the key is shared, because that determines the scope.
The two sources are updated independently and a revocation reason can change after the fact. An authority may initially publish one reason and later correct it — keyCompromise is sometimes revised to cessationOfOperation once a replacement certificate is issued, because the problem has been remediated. Where they disagree, treat the more severe reason as the one to act on until the authority settles it.
It affects whether the client sees anything at all. With a stapled response, the status and reason arrive with the handshake and are as fresh as the server's cache. Without it, the client queries the responder itself, adding latency and a dependency on reaching a third party. Either way the reason itself is authoritative and identical — stapling changes delivery, not content.
Indefinitely, in the records that matter. Revocation is permanent: there is no unrevocation, and a certificate marked revoked in a CRL or OCSP responder stays marked. Historical logs and transparency records are append-only and preserve the event. That permanence is what makes revocation an effective response to compromise — and also why distributing revocation to clients that cache aggressively takes time to take effect everywhere.

What Is Read From the Certificate

A revocation reason explains why a certificate was revoked, and it is carried in two places: the CRL entry for the serial, and the OCSP response. This page reads what the certificate itself makes available.

  1. 1Retrieve the certificate and read the distribution points from its CRL and Authority Information Access extensions. Those give the URLs a client would actually use, which is more useful than a description of where to look.
  2. 2Report the OCSP responder URLs separately from the CRL distribution points, since the two are queried differently and either may be the only one your clients use.
  3. 3Explain what the reason means for you. The distinction that matters operationally is key compromise versus cessation of operation: a compromised key is urgent and needs revocation everywhere it was used, while an expired or superseded certificate is routine and usually affects only the one host.

A live certificate is not revoked, so it carries no reason — the reason belongs to a revocation event that has not happened. What this page surfaces is where that information would come from, which is the useful part when planning your own response.

Tips & Best Practices

  • •Key compromise (reason 1) requires immediate certificate replacement
  • •CA compromise (reason 5) requires replacing all certificates from that CA
  • •Affiliation changed (reason 3) typically means domain ownership changed
  • •Superseded (reason 0) is normal for certificate renewal or replacement

Technical Details

Standards: RFC 5280 certificate revocation reason codes
Codes: 0-10 defined reasons with plain-language explanations
OCSP: How revocation reasons are communicated via OCSP/CRL
Impact: Trust implications and recommended actions for each reason