COMMENTARY: Your certificate authority can revoke a certificate while an application keeps accepting it. Both can appear to be working as configured.
That gap should concern anyone responsible for certificate security. A published revocation proves that the issuer changed the certificate's status. It does not prove that your application received the update or acted on it.
The useful question is how long a revoked certificate remains usable by the systems you actually run.
[SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
Browser progress does not protect every client!
Let's Encrypt shut down its Online Certificate Status Protocol service on Aug. 6, 2025. It now publishes revocation information exclusively through certificate revocation lists (CRLs). That was a change in delivery, not the end of revocation.
Browsers have their own mechanisms. Chromium documents CRLSets as Chrome's primary way to block certificates in emergencies. They include selected revocations, not every certificate on every CA's list. Chrome generally does not perform live OCSP or CRL checks.
Mozilla introduced production CRLite use in Firefox 142, supporting local revocation checks through distributed data.
Related reading:
Neither mechanism automatically protects your internal API client or network appliance. Those systems may rely on different libraries, settings, and update paths. A browser test tells you about that browser. It does not establish what a Java service or disconnected device will do.
Your inventory needs to include the systems that trust certificates, not just the certificates you issue.
The failure sits between teams
Treat revocation as three handoffs, each with an owner.
| Handoff | Suggested owner | Evidence to request |
| Publish status | Certificate authority or PKI operator | Signed, current status information |
| Deliver updates | Infrastructure or endpoint team | Successful retrieval and freshness records |
| Enforce distrust | Application or platform owner | A test showing rejection of the revoked certificate |
The table describes responsibilities, not a universal organization chart.
A current CRL at the issuer says nothing about a device holding an older copy. A configured OCSP address says nothing about what happens when the responder becomes unreachable.
If a client accepts the connection when the status is unavailable, it preserves availability but can allow a revoked certificate through. If it rejects the connection, a status-service outage can become an application outage. Neither choice should be an undocumented default.
Management needs to approve the trade-off. Application owners need to demonstrate the actual behavior.
Expiry is not an emergency response!
Shorter certificates help, but waiting for expiry is not the same as stopping misuse.
The CA/Browser Forum's TLS Baseline Requirements, section 6.3.2 reduce maximum validity for newly issued publicly trusted TLS subscriber certificates to 100 days from March 15, 2027, and 47 days from March 15, 2029. Those dates do not impose the same schedule on private PKI.
A key stolen soon after issuance can still be useful before expiry. Replacing the certificate on your server does not, by itself, stop a client from trusting the original certificate.
Shorter validity also makes renewal automation harder to defer. Check deployment to every intended endpoint, not just successful issuance. Otherwise, a replacement certificate can exist while production continues presenting the old one.
Three things to do before the next incident
- Map the clients that make trust decisions. Record their owners, trust domains, and status-checking behavior. Include non-browser and disconnected systems. Mark unknown behavior as unknown, rather than compliant.
- Run controlled failure tests. In an approved lab, present a revoked test certificate, then repeat with status access blocked or data made stale. Record acceptance, rejection, and update delay. Do not disrupt production trust to prove a point.
- Set a response target and an escalation path. Define the tolerable delay between revocation and rejection for each critical client class. Keep evidence of the test, the responsible owner, and any approved exception. Retest after relevant runtime or policy changes.
This is not an argument for forcing every client onto one protocol. Some environments need direct checks. Others need pre-distributed status or a separate emergency-distrust mechanism. The choice depends on connectivity and the cost of failure.
Ask your teams to show where revocation becomes rejection. Until they can, a completed revocation request is evidence of one step, not a completed incident response.
