Expired Security Certificate Is Blocking Visitors and Breaking Trust

Vulnerability Explanation

The server is presenting a TLS certificate whose validity period has elapsed. When a browser or API client initiates a TLS handshake, it validates the certificate's 'notAfter' field against the current date. If the certificate is expired, the Certificate Authority's trust chain can no longer be verified, causing the handshake to fail or proceed only after the user bypasses a browser warning. This breaks the authentication guarantee of TLS — the browser can no longer confirm it is talking to the legitimate server — which is a prerequisite condition for man-in-the-middle (MITM) attacks. Additionally, automated clients (APIs, mobile apps, monitoring agents) will typically hard-fail and refuse to connect entirely, causing service disruptions.

Root Cause

Certificate lifecycle management was not automated or monitored. TLS certificates have a fixed validity period (currently up to 398 days for publicly trusted certificates, with the CA/Browser Forum reducing this to 200 days effective March 15, 2026, and further to 47 days by 2029). Without automated renewal via an ACME client (e.g., Certbot) or a managed certificate service, certificates will inevitably expire if manual renewal is missed.

Technical Impact

Browsers display full-screen security warnings ('Your connection is not private', SEC_ERROR_EXPIRED_CERTIFICATE), deterring users from proceeding. Automated API clients and services silently refuse connections, causing integration failures. The broken authentication guarantee creates conditions where a MITM attacker could present a fraudulent certificate more convincingly, since the legitimate site already shows a warning. PCI DSS compliance is violated for any site handling payment data.

Severity Justification

The certificate is already expired, meaning the trust chain is actively broken for all visitors and API clients right now. While encryption may still function at the transport layer in some configurations, the authentication guarantee is gone, enabling MITM attacks. The immediate operational impact (browser warnings, broken API connections, compliance violations) justifies High severity.

Affected Components

• TLS/SSL Certificate — all versions once past notAfter date

Remediation Steps

1. Immediately renew or replace the certificate. For Let's Encrypt / Certbot: run `sudo certbot renew --force-renewal` (Nginx) or `sudo certbot renew --force-renewal --apache` (Apache), then reload the web server (`sudo systemctl reload nginx` or `sudo systemctl reload apache2`).
2. For commercially issued certificates (DigiCert, Sectigo, etc.): generate a new CSR, submit it to your CA, download the issued certificate and chain, install it on the server, and reload the web server.
3. After installation, verify the new certificate is live: `echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates` — confirm 'notAfter' is a future date.
4. Enable automated renewal to prevent recurrence. For Certbot, verify the systemd timer or cron job is active: `systemctl list-timers | grep certbot` or `cat /etc/cron.d/certbot`. If missing, add a cron entry: `0 */12 * * * root certbot -q renew --nginx` (runs twice daily, only renews when within 30 days of expiry).
5. Set up certificate expiry monitoring with an alerting threshold of 30 days before expiry. Tools: UptimeRobot (free tier), Nagios, Zabbix, or a dedicated SSL monitoring service.

Verification Steps

1. Run: `echo | openssl s_client -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates` and confirm 'notAfter' is in the future.
2. Visit https://www.ssllabs.com/ssltest/ and run a scan against your domain — it should return an 'A' grade with no certificate errors.
3. Open the site in Chrome/Firefox and confirm the padlock icon is present with no warnings.
4. Test automated renewal with a dry run: `sudo certbot renew --dry-run` — it should complete without errors.

Code Examples (bash)

# Certificate check showing expired state
$ echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Jan  1 00:00:00 2023 GMT
notAfter=Jan  1 00:00:00 2024 GMT  ← EXPIRED

# After renewal — notAfter is in the future
$ echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
notBefore=Mar 15 00:00:00 2026 GMT
notAfter=Mar 15 00:00:00 2027 GMT  ← VALID

# Certbot force-renewal (Nginx)
$ sudo certbot renew --force-renewal
$ sudo systemctl reload nginx

# Cron entry for automated renewal (twice daily)
0 */12 * * * root certbot -q renew --nginx

Best Practices

• Automate certificate renewal using an ACME client (Certbot) or a managed certificate service (Cloudflare, AWS ACM, Azure App Service) — never rely on manual renewal.
• Set up expiry monitoring with alerts at 30 days and 14 days before expiry as a safety net alongside automation.
• Maintain a certificate inventory if you manage multiple domains or subdomains — missed renewals are most common when certificates are undocumented.
• Note: The CA/Browser Forum is reducing maximum TLS certificate lifetimes to 200 days (effective March 15, 2026) and eventually 47 days by 2029 — automation is no longer optional at these shorter lifespans.

References

• letsencrypt.org/docs/
• certbot.eff.org/
• owasp.org/Top10/A02_2021-Cryptographic_Failures/
• www.ssllabs.com/ssltest/