A certificate that passed validation yesterday can fail today without any change on your part — because certificate revocation, CT log disqualification, and intermediate CA trust changes can invalidate certificates that were issued and validated correctly
The previous articles on this site covered SSL certificate types (DV/OV/EV), TLS configuration, Certificate Transparency logs, and how automated renewal breaks silently. This article addresses post-issuance certificate monitoring — the ongoing verification that a certificate remains valid after issuance, what events can invalidate it without your action, and how to build monitoring that catches these before your users do.
Certificate revocation: when a valid certificate becomes invalid
Certificate revocation is the process by which a CA (Certificate Authority) invalidates a certificate before its expiry date. Once revoked, the certificate should not be trusted by clients — even though it was validly issued and hasn't expired.
Reasons for revocation:
- The certificate's private key was compromised (stolen, exposed in a breach, accidentally committed to a public repository)
- The certificate was issued in error (wrong domain, wrong organization details)
- The subscriber relationship with the CA ended
- The CA itself was compromised and the certificate was issued under a compromised key
How clients check revocation status:
CRL (Certificate Revocation List): a periodically-updated list of revoked serial numbers published by the CA. Clients download and check the CRL. CRLs can be large and are only as current as the last publication.
OCSP (Online Certificate Status Protocol): a real-time query to the CA's OCSP responder asking "is this certificate revoked?" Provides current status but adds latency to TLS handshakes and requires the OCSP responder to be available.
OCSP Stapling: the server fetches the OCSP response and "staples" it to the TLS handshake — the client gets the revocation status without a separate OCSP query. Better performance, but requires server configuration.
When revocation doesn't work: the soft-fail problem
In practice, certificate revocation has a well-known reliability problem — most browsers implement "soft-fail" for revocation checking. If the CRL or OCSP responder is unreachable (network issue, responder outage), the browser proceeds with the connection rather than blocking it.
The logic: if blocking connections whenever revocation checks fail is the policy, an OCSP responder outage takes down every HTTPS site in the browser's scope. Most browsers decided availability should win over revocation certainty in failure cases.
The consequence: a revoked certificate may still be accepted by browsers whose revocation checks failed due to network issues. This is a known limitation of the PKI (Public Key Infrastructure) system.
Chrome's CRLSets: Google pushes revocation information directly to Chrome via software updates (the "CRLSets" mechanism) for high-priority revocations — major CA compromises, phishing certificates, etc. This works around the soft-fail problem for the most critical cases but doesn't cover routine revocations.
Certificate Transparency and retroactive distrust
Certificate Transparency (CT) requires all publicly-trusted certificates to be logged in public append-only logs. Browsers verify that certificates include a Signed Certificate Timestamp (SCT) from a trusted log before trusting them.
Two ways CT can invalidate a certificate post-issuance:
Log disqualification: if a CT log operator is found to be misbehaving (issuing false log entries, failing availability requirements, or other violations), that log is removed from browser trust stores. Certificates whose only SCTs come from a disqualified log may lose browser trust — even if the certificate itself is valid.
Mis-issuance discovery: because CT logs are public and searchable, security researchers actively monitor them for anomalies. A certificate incorrectly issued for a domain you own — perhaps by a CA that was tricked by a phishing attack — will appear in CT logs and can be discovered. The correct response is to contact the CA for revocation and review how the incorrect issuance was possible.
Intermediate CA issues: when the chain breaks
SSL certificates chain to a root CA via intermediate CAs. If the intermediate CA that issued your certificate is compromised or has its trust revoked, all certificates issued under that intermediate may become distrusted — even if your specific certificate is valid.
This has happened: in high-profile CA incidents (DigiNotar in 2011, Comodo reseller incidents, Symantec's CA infrastructure issues that led to Chrome's graduated distrust in 2017-2018), certificates issued by affected CAs or intermediates were marked untrusted by browsers, requiring re-issuance.
For website operators: when a CA incident is announced affecting your certificate's issuer, the correct response is usually to re-issue the certificate through a different CA or a non-affected intermediate, rather than waiting for the browser trust removal to affect your users.
The monitoring stack for active certificate health
A comprehensive certificate monitoring approach:
1. Expiry monitoring: alert 30, 14, and 7 days before expiry. This is the minimum and is well-understood.
2. Revocation status monitoring: periodically query the OCSP responder for your certificate's status. If the response changes to "revoked," you need to act immediately — a revoked certificate means your private key may be compromised.
3. CT log monitoring: services like Facebook's Certificate Transparency Monitoring or crt.sh alerts notify you when any certificate is issued for your domain. This catches unauthorized certificate issuance you didn't request.
4. Chain validation: regularly verify the complete certificate chain (certificate + intermediates + root) validates correctly from external vantage points. Missing intermediate certificates cause "untrusted certificate" errors for clients that don't cache intermediates.
5. TLS configuration drift: verify that TLS versions, cipher suites, and HSTS configuration remain correctly set. Misconfiguration can be introduced by server updates, CDN configuration changes, or load balancer updates.
How to use the SSL Checker on sadiqbd.com
- Verify the complete certificate chain: the tool shows the certificate, intermediates, and root — a missing intermediate causes trust errors for some clients even if the certificate itself is valid; verify all chain components are present and valid
- Check expiry against automated renewal: if using Let's Encrypt with Certbot or similar, the expiry shown should be well within the renewal window (60 days for most auto-renewal configurations); an expiry closer than 30 days for an auto-renewed certificate indicates the renewal mechanism has failed
- Verify Subject Alternative Names (SANs): confirm all domains that should be covered by the certificate are listed in the SANs — a certificate missing a subdomain that your site serves will cause a name mismatch error for that subdomain
Frequently Asked Questions
How do I know if my certificate's private key has been compromised? You often won't know immediately — that's part of what makes key compromise dangerous. Indicators include: unexpected appearance of your certificate on suspicious domains in CT logs (someone is using your key), certificate appearing in breach databases (if your server was compromised), or Let's Encrypt-style automated issuance logs showing unexpected certificate requests. Preventative practices that reduce private key exposure: using ECDSA keys (shorter, faster to generate, lower exposure surface than RSA), never logging private key material, using hardware security modules (HSMs) for high-value certificates, and rotating keys annually even without known compromise. If compromise is suspected, revoke and re-issue immediately — the CA can invalidate the old certificate and issue a new one with a freshly-generated key pair.
Is the SSL Checker free? Yes — completely free, no sign-up required.
Try the SSL Checker free at sadiqbd.com — verify any domain's SSL certificate expiry, issuer, SAN coverage, and chain validity instantly.
