The fix, in one snippet
sudo certbot renew --dry-run && systemctl list-timers certbot*Illustrative values. Change the paths, hostnames and options to match your own site before using it.
The sections below explain what is tested, why it matters and the alternatives.
What we test
Scan.now reads the notAfter field of the leaf certificate obtained during the handshake and compares it to the current time. The check fails when fewer than 30 days remain; it is reported as high when fewer than 7 days remain or the certificate has already expired (in which case certificate-valid fails too). The result shows the exact expiry timestamp, the issuer and the total validity period. Intermediates are examined as well, because an expired intermediate breaks the chain just as surely. The report also notes the certificate's total lifetime: since the CA/Browser Forum's Ballot SC-081 took effect in March 2026 public certificates may be issued for at most 200 days, falling to 100 days in March 2027 and 47 days in March 2029, which makes manual renewal impractical.
Why it matters
Expiry is the most common self-inflicted outage on the web. The moment the certificate lapses, browsers show an interstitial, mobile apps and API integrations fail with TLS errors, webhooks stop, and mail servers that enforce TLS start bouncing. Because nothing is hacked, monitoring often does not notice until customers complain. Large, well-staffed organisations have had multi-hour outages from a single forgotten certificate. A certificate close to expiry is also a signal that renewal is not automated, which means the next expiry is a matter of when, not if. As lifetimes shrink under the CA/Browser Forum schedule, any process that depends on a person remembering a date will fail. The certificate errors guide covers what users see and how to recover.
How to fix it
Automate renewal and monitor it. Certbot installs a systemd timer (or cron entry) that renews any certificate with fewer than 30 days left; confirm it is active and simulate a renewal:
systemctl list-timers | grep certbot
sudo certbot renew --dry-runIf you manage the timer yourself, a twice-daily cron entry with a reload hook is enough:
0 3,15 * * * certbot renew --quiet --deploy-hook "systemctl reload nginx"For Apache, replace the hook with systemctl reload apache2 (or httpd). acme.sh and Caddy are alternatives that renew automatically without extra tooling. Behind Cloudflare, Universal SSL renews the edge certificate itself; Origin CA certificates for the origin can be issued for up to 15 years, which removes the deadline from that hop. Wherever renewal happens, add an external check that alerts when fewer than 14 days remain, so a broken hook is caught before the deadline. The SSL checker shows days remaining on demand, and the SSL and TLS guide explains the certificate lifecycle.
Where this fits
Certificate expiry is check 3 of 12 that the website vulnerability scanner runs under transport security (https / tls), ordered the way they are worth fixing. That ordering is the point: Fixing this one while the check above it still fails buys less than it looks like.
Fix this one first
Above it in the same category sits HTTPS is available (critical), where the site could not be reached over HTTPS on port 443, or the TLS handshake failed. An attacker who has that does not need this, so it is the better use of the same hour.
What fixing this still leaves open
Certificate expiry closes one route in. Immediately below it: Deprecated TLS versions accepted (1.0 / 1.1), where the server still completes handshakes with TLS 1.0 or TLS 1.1; HTTP redirects to HTTPS, where port 80 serves page content instead of redirecting to HTTPS, or the redirect chain is wrong; Certificate key strength, where the certificate's public key is weaker than current guidance: An RSA key shorter than 2048 bits, or a DSA key.
Found in the same scan
The website vulnerability scanner reports this alongside checks from other categories that are at least as serious, including Exposed .env configuration file, where a .env configuration file is served from the web root, and Exposed .git repository, where the site's .git directory is reachable over HTTP. A single run of website vulnerability scanner answers all of them at once.
The first few lines
You are a senior web engineer. I ran a security and SEO scanner against my site and it reported the finding below. Fix it properly rather than suppressing the symptom.
Finding: Certificate expiry (high severity)
Scanner check id: certificate-expiryThe rest of this prompt names the pages and line numbers we found the problem on, the configuration to change, and the constraints a good answer has to respect. It is free, it just needs an account so the work is not scraped wholesale.
Sign in with GoogleSigning in is free and takes one click. We store your email address and nothing else.
References
Related guides
8 min read · Updated Sep 18, 2026
TLS Certificate Errors Explained: Expired, Mismatched, Self-Signed and Untrusted Chains
A certificate warning means the browser could not prove it is talking to the right server. Each error, what causes it on the server...
Read the guide
9 min read · Updated Sep 18, 2026
SSL and TLS Explained: Certificates, Handshakes, Protocol Versions and Cipher Suites
TLS is the protocol behind the padlock. What a certificate proves, how the handshake works, why TLS 1.0 and 1.1 are retired, what a...
Read the guide