Beyond expiry dates: the SSL security checks your agency is missing — Aideworks

Key takeaways

Expiry dates are only part of the story — a valid, non-expired cert can still be revoked without warning.
Certificate chains fail when intermediate certificates (not the leaf cert) expire — but most monitoring misses this.
OCSP stapling is a performance optimization that reduces browser handshake latency — most enterprise certs support it but don't use it.
A revoked certificate causes browsers to block the site entirely — depending on revocation checking strictness, users may not even see an error.
These checks happen silently during the SSL handshake — you need monitoring to know if they fail.

In this article

Why expiry dates aren’t enough

Most SSL monitoring stops at a single metric: how many days until the certificate expires? Alerts trigger at 30, 14, 7, and 1 day before expiry. This works well for catching renewals that failed, but it completely misses three critical security checks that modern CAs and browsers now enforce.

An SSL certificate can be perfectly valid — not expired, properly signed, covering the right domain — and still cause browser warnings or site unavailability if:

It has been revoked — the CA invalidated it due to key compromise, domain control loss, or administrative request.
Its chain is broken — an intermediate certificate in the signing chain (not the leaf cert) has expired.
OCSP stapling is missing — the certificate is valid but lacks the performance optimizations modern browsers expect.

OCSP Stapling — enabling certificate status caching

OCSP (Online Certificate Status Protocol) is how browsers check whether a certificate has been revoked by its CA. Without OCSP stapling, every page load triggers a separate OCSP request from the browser to the CA’s OCSP responder — adding latency and creating privacy concerns (the CA learns which sites visitors browse).

OCSP Stapling fixes this by having the web server query the OCSP responder once, cache the response, and “staple” it to the SSL handshake. Browsers get the revocation status instantly, without making a separate network call.

Why this matters: Enterprise CAs and cloud providers highly recommend OCSP stapling for performance. If your certificate supports it but your server isn’t configured to use it, you’re adding milliseconds to every page load and leaking visitor data to CAs. Some browsers may also enforce strict OCSP checks and fail the handshake if the response isn’t available.

Certificate revocation — when a cert becomes untrusted

A certificate revocation is rare but catastrophic. The CA invalidates a certificate for a few possible reasons:

Private key compromise — the server’s private key was exposed or stolen.
Domain control loss — the domain was transferred, taken down, or no longer controlled by the cert owner.
Admin request — the domain owner requested revocation (rare but possible).
CA policy violation — the certificate was issued in violation of CA/B Forum rules.

When a certificate is revoked, the CA publishes the serial number on a revocation list (CRL) or via the OCSP responder. Browsers then check this list during the SSL handshake and reject the certificate entirely.

The risk: A revoked certificate causes browsers to hard-fail the connection — visitors see a security warning and cannot access the site. Depending on browser settings, some may not even show an error message; they just refuse to connect. If revocation checks are strict (as they now are in modern browsers), your site becomes unreachable within minutes of revocation.

Certificate chains — why intermediates matter

Your SSL certificate (the “leaf” cert) is not signed directly by the root CA. Instead, it’s signed by an intermediate certificate, which is signed by the root. This chain ensures trust: browsers trust the root (pre-installed), validate the intermediate, then validate your leaf cert.

The problem: Intermediates have their own expiry dates. If an intermediate expires, the entire chain becomes invalid — even if your leaf certificate is still valid for another year.

Why this happens silently: Your server may serve the correct leaf certificate, but if the configured chain doesn’t include the currently-valid intermediate, browsers see the chain as broken. Certificate authorities regularly replace intermediates (usually annually) to improve security or due to policy changes. If your hosting maintains the chain correctly, you won’t notice. If they don’t, your site breaks 90-180 days before your leaf cert expires.

What happens when these checks fail

Check	Failure Symptom	User Experience
Revocation Check	Cert in CRL/OCSP blacklist	Site blocked entirely
Chain Validation	Intermediate cert expired	"Untrusted certificate" error
OCSP Stapling	Staple missing or stale	Page loads slower, extra latency

How to monitor SSL security beyond expiry dates

Modern SSL monitoring needs to go beyond counting down to expiry. Enterprise-grade monitoring should track:

OCSP status — is the certificate revoked? Store revocation status on each check to detect sudden changes.
Certificate chain health — which intermediates are in the chain? When do they expire? Alert before they breach 90-day window.
OCSP stapling presence — is the server configured to staple? Flag if missing to recommend performance optimization.
Signature algorithm strength — are you using modern algorithms (RSA-2048+, ECDSA)? Flag weak keys.
CAA records — which CAs are authorized to issue for your domain? Verify the CAA policy hasn’t been weakened.

The bottom line

Agencies managing client portfolios face new complexity: as CAs enforce stricter revocation checking and shorten certificate lifetimes (from 398 to 47 days by 2029), the margin for error shrinks. Monitoring expiry alone is no longer enough. You need visibility into revocation status, chain integrity, and OCSP performance — the same insights that enterprise IT teams depend on to keep thousands of internal domains secure and performant.