How to Check a Certificate Revocation Status: OCSP, CRL, and Common Validation Errors

Overview

A certificate can be within its validity dates and still no longer be acceptable for trust. A certificate authority (CA) may revoke it after a private-key compromise, an incorrect issuance, a domain-control problem, or another security or administrative event. Certificate revocation checking is the process of asking whether that certificate has been withdrawn.

The two main mechanisms are the Online Certificate Status Protocol (OCSP) and the certificate revocation list (CRL):

• OCSP: A client sends a status request for a certificate to an OCSP responder named in the certificate's Authority Information Access extension. The responder normally returns a status such as good, revoked, or unknown, together with timing information.
• CRL: A CA publishes a signed list of revoked certificate serial numbers. The certificate's CRL Distribution Points extension can identify where the list may be retrieved.

Revocation is only one part of PKI certificate validation. A successful OCSP response does not by itself prove that the certificate is suitable for a hostname or application. You must also check the certificate chain, signature algorithms, key usage, validity period, hostname, trust store, and—where relevant—policy requirements. For a broader certificate chain check, see the SSL certificate checker guide.

Step-by-step workflow

1. Capture the exact certificate

Start with the certificate actually presented by the server or application. Do not rely only on a common name, an old exported file, or a certificate copied from a different environment. For a TLS service, inspect the endpoint and record the leaf certificate, issuer, serial number, validity period, and extensions.

With OpenSSL, a basic inspection command is:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Save the relevant PEM block if you need to run separate checks. The -servername option matters when the endpoint uses SNI and serves different certificates for different hostnames.

2. Inspect revocation endpoints

Use the certificate details to find the OCSP responder and CRL Distribution Points. These URLs are issuer-provided metadata; they are not interchangeable with the website's URL. If neither location is present, the relying application may have limited or implementation-specific revocation support.

For a local certificate file:

openssl x509 -in leaf.pem -noout -serial -issuer -subject \
  -ocsp_uri -text

Review the output for the certificate serial number and the issuer certificate. OCSP requests identify a certificate through its issuer and serial number, so using the wrong issuer can produce an unhelpful result.

3. Query OCSP where supported

An OCSP check generally needs the leaf certificate, its issuer certificate, and the responder URL. A representative OpenSSL command is:

openssl ocsp -issuer issuer.pem -cert leaf.pem \
  -url https://ocsp.example-ca.test \
  -CAfile issuer.pem -resp_text

Replace the example responder with the URL from the certificate. Command options vary by OpenSSL release, so check the installed version's help output before using the command in automation. A valid response should be evaluated for more than its headline status: check the responder signature, the certificate identifier, the thisUpdate and nextUpdate fields, and any nonce or freshness behavior used by your client.

Interpret common statuses as follows:

• Good: The responder does not report the certificate as revoked for the queried identity and time. It is not a guarantee that every other certificate or validation condition is correct.
• Revoked: Treat the certificate as withdrawn. Confirm the revocation time and reason when available, then replace the certificate and investigate possible key exposure or incorrect issuance.
• Unknown: The responder cannot provide a status for that certificate, issuer, or request. Check that the leaf and issuer match and that you are using the correct responder.
• Unavailable or timeout: The status could not be obtained. This may indicate a network, DNS, proxy, responder, firewall, or service issue rather than a revoked certificate.

4. Check the CRL as a second path

Download the CRL from the certificate's distribution point and inspect it with the issuing CA's public certificate. A simplified workflow is:

curl -fL -o issuer.crl https://crl.example-ca.test/issuer.crl
openssl crl -inform DER -in issuer.crl -text -noout

If the CRL is encoded as PEM, omit -inform DER. Compare the leaf certificate's serial number with entries in the CRL. Also inspect the CRL's issuer, thisUpdate, and nextUpdate values. A stale, unsigned, or mismatched CRL should not be treated as conclusive evidence that the certificate is safe.

5. Apply the result to the full validation decision

Use this decision tree:

1. If the certificate is reported as revoked, stop relying on it and replace it.
2. If OCSP says good and the response is correctly signed, current, and for the expected certificate, continue with chain and hostname validation.
3. If OCSP returns unknown, compare the issuer, serial number, responder URL, and certificate chain, then try the CRL path if available.
4. If both mechanisms are unavailable, determine whether your application fails closed, fails open, or records a soft-fail. Escalate the uncertainty for security-sensitive workflows rather than labeling the certificate trusted.

Tools and handoffs

Use different tools for different layers of the investigation:

• OpenSSL: Useful for repeatable inspection, OCSP queries, CRL parsing, and examining extensions.
• Browser developer tools or certificate viewers: Helpful for seeing the certificate presented to a user agent, although browser revocation behavior may differ from command-line tools.
• Public SSL checkers: Useful for an outside-in view of the endpoint, chain, and TLS configuration. Do not submit private certificates or sensitive material to an unfamiliar service.
• Application and proxy logs: Check these when a service reports a responder timeout, stapled-response failure, trust-store error, or certificate mismatch.

In production, separate ownership clearly. The certificate or platform administrator usually owns renewal and replacement; the network team may own outbound access to OCSP and CRL endpoints; application owners own the trust-store and fail-open or fail-closed behavior; and security teams may own incident response after a revocation. If the endpoint uses OCSP stapling, inspect the server's stapled response as well as the CA responder. A stale or malformed staple can cause a validation failure even when a direct query succeeds.

For systems that issue or display digital credentials, the same principle applies: record the credential identifier, issuer, status source, status timestamp, and verification result. The guidance in Build a Certificate Verification Portal can help when revocation checks are part of a public verification workflow.

Quality checks

Keep evidence with the incident or change record: the certificate fingerprint, serial number, issuer, exact endpoint, command or tool version, response timestamps, and the final decision. Avoid logging private keys or unnecessary identity data. When a certificate is revoked, preserve enough evidence to determine whether replacement alone is sufficient or whether credentials, keys, deployments, and trust stores also require review.

For signed files and non-TLS credentials, do not substitute an OCSP check for signature validation. A signed document needs a separate check of the signer certificate, signature integrity, trust chain, and revocation information. See How to Verify a Digitally Signed Document for that workflow.

When to revisit

Revisit this certificate verification workflow after every certificate renewal, issuer change, trust-store update, proxy or firewall change, TLS configuration change, or security alert. It is also worth repeating when users report intermittent trust failures, when monitoring shows OCSP or CRL timeouts, or when a CA changes its responder or distribution-point behavior.

Maintain a small operational test that captures the served certificate, validates the chain and hostname, checks the configured revocation path, and alerts on a revoked, expired, mismatched, or unexpectedly unavailable result. Review the commands when OpenSSL or another validation tool changes syntax, and review application behavior when a platform changes how it handles OCSP stapling, soft-fail responses, or CRL caching.

The practical rule is simple: a certificate revocation check is a status input, not a complete trust decision. Confirm the exact certificate, query an appropriate status source, validate the response, compare with the available CRL when needed, and document what remains uncertain before declaring the certificate trusted.