Expired TLS Certificate

How attackers find and exploit it

• Enumerate the target's hostnames from Certificate Transparency logs, passive DNS, and subdomain discovery, then probe each candidate on 443 and other TLS ports to collect live certificates.
• Parse the notAfter field from every retrieved certificate and flag any host already past expiry, plus any host whose certificate expires imminently as a near-term opportunity window.
• Identify services where the user base has been trained to bypass warnings (the certificate has likely been expired for some time), because those users are most likely to click through a substituted certificate.
• Position on a path the victim traverses, for example shared Wi-Fi, a compromised router, or DNS spoofing, and present a self-signed or attacker-controlled certificate for the same hostname.
• Because the legitimate site already shows a warning, the user perceives the attacker's warning as the normal, expected behavior, accepts it, and the attacker proxies the session to intercept credentials, session tokens, or API keys in cleartext.
• Harvest captured secrets and replay them against the real service, or use the foothold to pivot, while the victim believes they reached the genuine endpoint.

How to detect it on your surface

• Build an authoritative inventory of every internet-facing hostname and the TLS ports each one listens on, including load balancers, mail servers, and API gateways, not just the primary web property.
• For each endpoint, retrieve the served certificate chain and compare the current date against the notAfter of both the leaf and every intermediate certificate, since an expired intermediate causes an outage even when the leaf is current.
• Continuously monitor Certificate Transparency logs for your domains to discover hosts and shadow IT you did not know were issuing certificates, then verify whether those certificates were ever renewed.
• Establish renewal-runway thresholds (for example alert at 30, 14, and 7 days before notAfter) so you detect the condition before it becomes a live outage rather than after.
• Cross-check every certificate against an asset owner; any certificate that maps to no owning team is a lifecycle gap that will eventually expire unnoticed.

Detection signals

• Browser interstitials such as Chrome's NET::ERR_CERT_DATE_INVALID or Firefox's SEC_ERROR_EXPIRED_CERTIFICATE when loading the host.
• A TLS handshake completes but the served leaf or intermediate certificate's notAfter timestamp is earlier than the current date.
• openssl s_client -connect host:443 reports the notAfter date in the past, and openssl x509 -checkend 0 returns a non-zero status indicating the certificate has already expired.
• Command-line and API clients (curl, requests, JDBC drivers) fail with certificate verification errors referencing an expired or out-of-validity-window certificate.
• A Certificate Transparency log shows the most recent precertificate or certificate for the hostname was issued long enough ago that its typical validity period has already elapsed with no newer entry.

Validate before you report

• Re-resolve the hostname and connect directly to the live IP and port to confirm the expired certificate is what the server is actually serving right now, not a stale cached result.
• Run openssl x509 -noout -dates on the retrieved certificate to read the exact notBefore and notAfter, and confirm notAfter is strictly before the current UTC time.
• Walk the full chain and check each intermediate certificate's notAfter independently, so the finding correctly attributes expiry to the leaf or to a specific intermediate.
• Verify the expired certificate's Subject and SAN actually cover the hostname under test, confirming this is the certificate that would be presented to a real visitor of that name.
• Capture the served certificate (PEM and decoded text) plus the timestamp of collection as evidence, so the finding is reproducible and the expiry is documented at a specific moment.

What looks like this but isn't

• Confirm the validating client's own system clock and timezone are correct; a skewed clock can make a perfectly valid certificate appear expired or not-yet-valid.
• Distinguish an expired certificate from a not-yet-valid one (current date before notBefore) and from a hostname mismatch or untrusted chain, since each is a different finding with a different fix.
• Check whether the hostname is intentionally retired or parked; an expired certificate on a decommissioned endpoint that is being shut down is a different remediation path than a live production service.
• Ensure SNI was sent during collection; a server may return a default fallback certificate that appears expired when the correctly negotiated certificate for the requested name is actually valid.

Remediation

• Issue and install a replacement certificate from a publicly trusted CA covering the affected hostname, and deploy it across every node and load balancer that terminates TLS for that name.
• Install the complete, current chain including the correct intermediate CA certificate so clients do not break on a stale or expired intermediate even after the leaf is renewed.
• Reload or restart the serving process and validate from an external vantage point that the new certificate, not the cached expired one, is being presented.
• Automate renewal using ACME (for example certbot or an equivalent) so certificates renew and reload well before notAfter without manual intervention.
• Assign a named owner and a system of record for every certificate, eliminating the unowned assets that silently age out.
• Configure proactive expiry alerting at multiple runway thresholds feeding a channel an on-call engineer actually watches, so a missed renewal surfaces days early rather than as an outage.

Operational checklist

• Maintain a central, automatically updated inventory of all TLS certificates across internet-facing and internal services, with notAfter dates and owning teams.
• Enroll every public domain in continuous Certificate Transparency log monitoring to catch both unexpected issuance and certificates that were never renewed.
• Default all renewals to ACME-based automation and treat any manually renewed certificate as a managed exception with a documented owner.
• Standardize on short, automatable certificate lifetimes and verify both leaf and intermediate certificates against expiry on a recurring schedule.
• Run expiry alerts at 30, 14, and 7 days of runway into an actively monitored on-call channel, and rehearse the renewal-and-deploy runbook so recovery is fast.
• Review certificate dashboards in regular operational cadences so coverage gaps are caught before any certificate reaches its notAfter date.

Weakness references (CWE)

• CWE-298 — Improper Validation of Certificate Expiration
• CWE-324 — Use of a Key Past its Expiration Date
• CWE-295 — Improper Certificate Validation