A certificate can still have time left before its expiry date when its issuer revokes it. If you are new to HTTPS, it helps to keep two questions separate: Is the current time inside the certificate’s validity period? and Has the issuer withdrawn this certificate? Neither answer completes every certificate check.
Conceptual status-reading diagram. It does not show a live browser request or a tested revocation result.
Expiry and revocation describe different things
The certificate carries a validity period. Revocation is a later status decision, for example after a key compromise or an issuance problem. It does not erase copies of the certificate from servers or computers.
Clients need a way to obtain and assess relevant status information. RFC 5280 describes certificates and certificate revocation lists, including the signed data and time fields used to evaluate a list.
CRLs and OCSP give status information in different forms
| Mechanism | What you inspect | What still matters |
|---|---|---|
| CRL: certificate revocation list | A signed list, within its issuer and distribution scope, identifying revoked certificates | Issuer, scope, signature and freshness |
| OCSP: Online Certificate Status Protocol | A signed response describing the status of a requested certificate | Response authority, signature, time and the stated status |
Do not treat a certificate’s serial number as a globally unique identifier. The issuer is also part of identifying the certificate whose status you are checking. A list can also have a limited scope, so absence from an arbitrary CRL is not proof that every relevant check passed.
Read an OCSP status precisely
RFC 6960 defines good, revoked and unknown.
-
goodis a positive status response. It does not, by itself, establish every certificate property or even necessarily prove that the certificate was issued. -
revokedis a negative status that needs attention. The protocol also describes particular cases such as certificates on hold and non-issued certificates. -
unknownmeans the responder does not know about the requested certificate. It is not a substitute forgood.
A familiar-looking status string is not enough. The response must also be checked under the appropriate authority and time conditions. Name matching, the certificate’s own validity period and its trust path remain separate checks.
Do not assume every browser makes the same live request
Status delivery and acceptance depend on the client, its configuration and the issuer’s services. Responses may be cached or delivered with the TLS connection through stapling, rather than fetched directly by the visitor. RFC 6961 discusses TLS certificate-status delivery. It is a protocol reference, not a claim that every current browser uses that exact mechanism.
Public TLS issuance requirements also evolve. The CA/Browser Forum Baseline Requirements include CRL requirements and allow OCSP as an optional service. Before designing monitoring, check the actual issuer and client behaviour. A failed request to one URL is neither a complete revocation verdict nor an excuse to disable verification.
A worksheet for your first status investigation
- Certificate issuer and serial number: ____.
- Hostname and service presenting it: ____.
- Certificate validity period: ____.
- Relevant status source and its scope: ____.
- Response status, signature/authority check and freshness: ____.
- Client, version and configuration used: ____.
- What was observed, and what remains unconfirmed: ____.
No command or production test was executed for this article. The worksheet helps record evidence without inventing a successful result.
For the broader incident handoff, PKI Channel’s revocation operations guide connects status information to the service and response process. For command-level study, its OCSP/CRL reading guide is in Japanese and separates response verification from the certificate-status result.
AI was used for source review and drafting.
Top comments (0)