Revoked Certificates: Interpret OCSP and CRL Results

A revoked TLS certificate should be treated as a trust problem involving that certificate. It does not, by itself, establish that the domain is malicious. Conversely, a favorable revocation status does not guarantee that a site is honest.

Keep three parts of the investigation separate: the certificate presented, the revocation response used, and the reputation of the observed activity. This prevents a precise diagnosis from being replaced with an ambiguous label such as “unsafe SSL.”

Identify the certificate actually presented

Record the requested hostname, endpoint contacted, collection time, and client used. Preserve the certificate presented and its chain if your tool provides them. A check performed from another network or at another time may receive a different certificate.

Interpret the serial number together with the issuer's identity. Add the certificate's SHA-256 fingerprint to the case record. Do not confuse it with a fingerprint of the public key: they identify different objects and support different comparisons.

If you already have a PEM copy named certificate.pem, this command reads its local information:

openssl x509 -in certificate.pem -noout -subject -issuer -serial -dates -sha256 -fingerprint

A second command displays names and references to status services when those extensions are present:

openssl x509 -in certificate.pem -noout -ext subjectAltName,authorityInfoAccess,crlDistributionPoints

These options are documented in OpenSSL's x509 reference. They inspect the saved certificate. They do not contact the site or perform complete chain or revocation validation.

Keep the tool version and output with the collected evidence. If a colleague obtains a different result, you can first establish whether you are examining the same certificate.

Distinguish the OCSP outcomes

OCSP defines good, revoked, and unknown statuses. good is not complete certificate validation; revoked indicates that the certificate should be rejected on that basis; unknown means the responder cannot determine its status. A connection error is none of these three outcomes. RFC 6960 defines these distinctions and the checks required for responses.

Avoid a single “OCSP OK” boolean in your logs. Instead, retain the received result, responder identity, relevant timestamps, signature validation result, and any transport error. This distinguishes a usable response from text displayed by a tool after an incomplete check.

A response delivered with the TLS connection, commonly called OCSP stapling, also needs validation. Its presence alone is insufficient: it must correspond to the certificate in question, and the client must accept its authenticity and freshness.

Expiration remains a separate check. A certificate can be outside its validity period without being reported as revoked. Writing “not revoked, therefore valid” merges two different conditions and can hide the actual cause of a failure.

Evaluate a CRL within its scope

A certificate revocation list, or CRL, is signed and published for a defined scope. A serial number's absence is meaningful only after verifying the issuer, coverage, and freshness of the list. The thisUpdate and nextUpdate fields help establish its publication timeline; complete CRLs and delta updates require appropriate processing. These mechanisms are described in RFC 5280, sections 5 and 6.3.

During an investigation, request detailed results from your validation tool instead of manually searching for a number in a file found online. A list from the wrong issuer does not answer your question, even if its contents are well formed.

Preserve the CRL's source and the copy used for the check. If you revisit the case several days later, the available list may have changed. The report should let you recover the evidence that supported the original decision.

Resolve disagreement between two checks

Consider a fictional case: a monitor reports a revoked certificate for portail.example, while a workstation opens the page without a warning. The reserved name is illustrative; this is not a description of a real incident.

The first question is certificate identity. Did the monitor contact an old server? Did the workstation receive a renewed certificate? Do both connections pass through the same proxy? If their fingerprints differ, there may be no disagreement: the tools are evaluating different objects.

If the fingerprints match, compare the time periods and status sources. One result may rely on a cache or an older response. Then record the clients' actual behavior and validation configuration. Successfully opening the page does not establish that the browser performed the same check as the monitor.

For the service owner, the immediate task is to locate endpoints still presenting the certificate and apply the appropriate replacement procedure. Do not ask users to bypass the warning to test the service. Technical verification belongs with the team administering the infrastructure.

Investigate reputation separately

In a phishing case, also record the exact domain, received URL, message context, and actions requested of the user. A valid certificate can accompany a page designed to steal credentials. Encrypting the connection does not establish the operator's intentions.

Likewise, a revoked certificate on a familiar service can result from an unfinished replacement operation. Establish the explanation before distributing a blocking rule covering every associated subdomain or address.

Certificate Transparency monitoring helps investigate certificate issuance, while infrastructure clustering through DNS and certificates examines relationships. Neither comparison replaces the status of the exact certificate observed during your connection.

In the final ticket, record separately: “certificate identified,” “status checked at this time,” “effect observed on this client,” and “hypothesis about the domain's activity.” Add a domain reputation report to the last item, then decide on TLS remediation and any security investigation using the evidence relevant to each.