A valid expiration date does not guarantee that a TLS certificate is safe to trust. A certificate can be revoked after a private key leak, a mistaken issuance, or a change in domain control. Browsers often handle revocation inconsistently, so infrastructure teams need an independent check that turns certificate status into an observable signal. A scheduled web cron job is a practical way to run that check continuously without maintaining a resident monitoring process.
What an OCSP monitor should prove
Online Certificate Status Protocol (OCSP) checks ask the issuing certificate authority whether a specific certificate is good, revoked, or unknown. A useful monitor should prove more than “the endpoint responded.” It should verify the target certificate, identify its issuer, build a standards-compliant OCSP request, validate the responder signature, and record the certificate status together with the response timestamps.
This complements, rather than replaces, certificate-expiration monitoring, Certificate Transparency checks, and CAA record monitoring. Those controls answer different questions: when a certificate expires, what was issued, and which authorities may issue. OCSP answers whether the current certificate has been revoked.
Build a narrow validation endpoint
Create an authenticated HTTPS endpoint such as /internal/checks/ocsp. Keep the scheduler simple: it calls the endpoint, while the application performs the TLS and OCSP work. This separation makes retries, evidence storage, and alert routing easier to test.
GET /internal/checks/ocsp?target=api.example.com
Authorization: Bearer The endpoint should return a compact machine-readable result. Include the hostname, certificate serial number, issuer fingerprint, OCSP responder URL, status, produced-at time, this-update time, next-update time, response validation result, and total latency. Never return private keys or reusable administrative credentials.
Retrieve and identify the live certificate
Open a TLS connection with Server Name Indication set to the monitored hostname and capture the complete peer chain. Validate hostname matching and chain construction before querying OCSP. A status check for the wrong certificate can create a convincing but useless green result.
Store a fingerprint of the leaf certificate and its issuer. When either changes, mark the run as a certificate-change event and refresh the monitor's baseline. If the new certificate appears unexpectedly, raise a separate warning even when its OCSP status is good. For broader protocol coverage, pair this check with TLS protocol and cipher monitoring.
Create and validate the OCSP request
Read the Authority Information Access extension from the leaf certificate and select the OCSP responder URL. Construct a request using the certificate serial number plus the issuer name and key hashes. Send it with strict timeouts and a bounded response-size limit. Accept only HTTPS or explicitly approved HTTP responder URLs, and block redirects to private or loopback networks.
When the response arrives, verify all of the following:
- The response status is successful and contains a single response for the requested certificate.
- The responder signature chains to the issuer or an authorized OCSP signing certificate.
- The serial number and issuer hashes match the request.
thisUpdateis not unreasonably old or in the future.nextUpdate, when present, has not passed.- The status is exactly good, revoked, or unknown; never coerce unknown into good.
Classify failures without hiding risk
A revoked response is a critical incident. Record the revocation time and reason, remove the certificate from service, rotate the affected key material, and investigate issuance history. An unknown response deserves a high-severity warning because the responder cannot establish status.
Network timeouts and responder errors are different from a cryptographic revocation result. Classify them as availability failures, retry against policy, and retain the last verified status with its age. Do not display stale “good” state without an explicit staleness label.
Use resilient schedules and bounded retries
For public-facing production certificates, run the check every 15 to 30 minutes. Stagger hosts to avoid bursts. If a request times out, retry once after a short delay and once more with exponential backoff and jitter. Cap each attempt so one slow responder cannot consume the entire job window. The cron retry strategies guide explains how to combine backoff, timeouts, and idempotency.
Protect the endpoint with a monitor-specific credential, IP restrictions where practical, and strict request validation. Follow the patterns in secure web cron endpoints, and use a lock so overlapping runs do not write contradictory state.
Alert on the condition that matters
| Condition | Severity | Action |
|---|---|---|
| Revoked | Critical | Page the on-call team and remove the certificate |
| Unknown | High | Investigate issuer and chain immediately |
| Invalid signature or mismatch | High | Reject the response and inspect the request path |
| Stale response | Medium | Retry and track status age |
| Responder timeout | Medium after threshold | Retry, then alert on sustained failure |
| Unexpected certificate change | Medium | Verify deployment and issuance ownership |
Deduplicate alerts by hostname, serial number, and condition. Send an immediate notification on transition to revoked or unknown, then repeat only at controlled intervals until recovery. A recovery message should include the first failure, last failure, total duration, and the certificate that restored healthy state.
Keep evidence for investigations
Persist the raw OCSP response or a cryptographic digest, parsed status fields, certificate fingerprints, responder URL, validation outcome, and timestamps. Retain enough history to distinguish a short responder outage from a certificate lifecycle incident. Avoid logging bearer tokens, session cookies, or other secrets.
Clock accuracy matters because OCSP validity is time-bound. If you see widespread future or stale timestamps, verify the monitor host with server clock-drift monitoring before blaming the issuer.
Test the monitor safely
Unit-test good, revoked, unknown, malformed, expired, mismatched, and badly signed responses with recorded fixtures. In staging, use a certificate authority or test environment that can produce a known revoked certificate. Confirm that timeouts are bounded, retries do not overlap, and alerts contain actionable evidence. Never revoke a production certificate merely to test the pipeline.
Implementation checklist
- Enumerate every public hostname and certificate owner.
- Validate the live hostname, chain, issuer, and serial number.
- Verify OCSP signatures and response freshness.
- Keep revoked, unknown, unavailable, and stale as distinct states.
- Schedule checks with jitter, short timeouts, and bounded retries.
- Protect the monitoring endpoint and redact secrets.
- Store evidence and test both alert and recovery paths.
OCSP monitoring is a small scheduled task with an outsized security benefit. When it is strict about identity, signatures, freshness, and failure classification, it can detect a revoked certificate long before a routine expiry check would notice anything wrong.