Certificate revocation: test the client behavior and status-service dependency

Last updated: 5 Oct 20266 min read

tutorial

Revocation may use a certificate revocation list, an online status response, a short certificate lifetime, or a workload identity system's own policy. Client implementations differ in what they check and what happens when the status service is unreachable. A private CA operator cannot assume its issuance controller publishes revocation data. Define the mechanism, distribution interval, cache lifetime, failure behavior, and fastest alternative for compromised credentials before an incident.

Operational decision

An internal document-signing API accepts client certificates from partner gateways. The security team revokes a test client certificate in a disposable CA and probes each gateway class after publication. One proxy checks a refreshed list, while another trusts its cached list until a reload; a batch client does not check revocation at all. The team records those differences and uses a short-lived identity plus explicit access-policy denial for the batch path rather than claiming immediate revocation. Simulate an unavailable status endpoint and verify whether each gateway fails closed, uses a bounded cached response, or fails open; the chosen behavior is documented against its availability objective. Do not publish the CA key or the full server Secret as a way to distribute lists. For a compromised issuer key, leaf revocation alone is not enough because the adversary may mint new leaves; move to a new trust anchor and remove the old one on an emergency schedule. Monitor the age of revocation data as well as certificate expiry. A log entry saying 'revoked' is not proof that every relying process rejects the certificate.

Partner revocation acceptance
Issuer: mechanism and publication owner known
Gateway A: revoked client rejected after list refresh
Gateway B: cache age and reload behavior measured
Batch path: no revocation check; identity lifetime bounded
Status outage: declared fail behavior observed
Issuer compromise: trust-anchor replacement plan invoked

Cost and verification

For C client classes and S status states, a basic matrix needs O(C × S) checks. Online status requests can add network dependence or latency, while local lists consume distribution and memory; choose based on actual clients and risk. Measure rejection time after revocation, oldest cached status, clients with no check, and availability impact during status-service failure. Short certificates reduce exposure but increase issuance and reload work.

Common Mistakes

Do not equate an issuer's revocation record with client rejection.
Do not assume an issuance controller also operates a status service.
Do not treat revoking leaves as sufficient after issuer-key compromise.

Connected lessons

Practice and check

devops

tls