Why SSL certificates expire
Every publicly trusted SSL/TLS certificate has a built-in expiry date. This is not a flaw; it is a deliberate security mechanism. Expiry forces organisations to rotate their certificates on a regular schedule, which limits the damage window if a private key is ever compromised.
The maximum validity for public certificates has been shrinking rapidly. In April 2025, the CA/Browser Forum approved Ballot SC-081v3, setting a phased reduction schedule: 200 days from March 2026, 100 days from March 2027, and 47 days from March 2029. The ballot was driven by Apple and supported by Google, who had previously proposed a 90-day maximum. Let's Encrypt already issues certificates with a 90-day validity period, providing a practical baseline for what automated renewal looks like at scale.
Shorter lifetimes mean that manual certificate management is no longer viable for most organisations. If you are managing more than a handful of domains, automated monitoring is essential.
What happens when a certificate expires
The consequences of an expired certificate are immediate and severe:
- Browser warnings: Every major browser displays a full-page security warning. Most users will not click through it; they will simply leave.
- Search engine de-indexing: If Googlebot encounters a certificate error during a crawl, it may stop indexing the site entirely until the issue is resolved.
- API failures: Any service that connects to your endpoint over HTTPS will receive a TLS handshake error. Webhooks, partner integrations, and mobile apps will all break simultaneously.
- Email delivery failures: If your MX servers use expired certificates, receiving mail servers that enforce TLS (opportunistic or strict) may reject inbound messages. Use our DNS Lookup tool to check your MX and CNAME records.
- HSTS lockout: If your site uses HTTP Strict Transport Security and the certificate expires, browsers will refuse to load the site at all, with no option to bypass the warning.
What to monitor
Certificate expiry is the most obvious thing to track, but it is far from the only thing that can go wrong. A thorough monitoring setup should cover all of the following:
- Expiry date: The most critical check. You need enough warning time to renew before the certificate lapses.
- Certificate chain completeness: A missing intermediate certificate causes failures on certain clients (particularly older Android devices and some corporate proxies) even though the certificate itself is valid.
- Protocol version: TLS 1.0 and 1.1 are officially deprecated. If your server still offers them, you are exposing users to known vulnerabilities. Only TLS 1.2 and 1.3 should be enabled.
- Cipher suites: Weak ciphers such as RC4, 3DES, and export-grade suites should be disabled entirely. Modern configurations should prefer ECDHE key exchange with AES-GCM or ChaCha20.
- Certificate Transparency (CT) logs: CT logs are public records of every certificate issued for your domain. Monitoring them allows you to detect misissued or unauthorised certificates, which could indicate a compromise or a misconfiguration at a CA.
- Hostname mismatch: The Subject Alternative Names (SANs) or Common Name (CN) on the certificate must match the domain being served. A mismatch causes the same browser warning as an expired certificate.
Check your certificate now with our free SSL Checker to see your expiry date, chain status, protocol versions, and more. You should also verify your CAA records to ensure only authorised certificate authorities can issue certificates for your domain, and use our WHOIS Lookup to confirm your domain registration is current.
How often to check
Daily checks are the minimum for any production domain. With 90-day certificates becoming the standard, you need at least 30 days of warning before expiry to give yourself a comfortable renewal window. Many organisations set alert thresholds at 30, 14, and 7 days.
Even if you use automated renewal through ACME (certbot, Caddy, or your cloud provider's managed certificates), silent failures are more common than you might expect. A DNS validation record that was accidentally deleted, a rate limit hit on Let's Encrypt, or a permissions change on the renewal script can all cause the automated process to fail without any visible error.
The monitoring check should always verify the live certificate as served by your web server, not the renewal configuration file on disk. The only way to know for certain that your visitors see a valid certificate is to connect to the server over TLS and inspect what it presents.
Automated vs manual monitoring
Manual monitoring typically means setting calendar reminders or occasionally clicking the padlock icon in your browser to inspect certificate details. This approach works for a single domain, but it breaks down quickly when you manage five, ten, or fifty domains. Calendar reminders get dismissed, and browser checks only happen when someone remembers to do them.
Automated monitoring uses a tool or service that connects to each of your domains on a schedule, inspects the live certificate, and sends alerts when expiry thresholds are reached or problems are detected. This is the only reliable approach for organisations with multiple domains or subdomains.
ShieldMarc checks your SSL certificates daily with configurable alert windows. You can set your preferred warning thresholds (for example, 30 and 7 days before expiry) and receive notifications by email when action is needed. Paid plans include daily SSL monitoring with alerts for all domains in your organisation.
Common certificate problems and how to fix them
Expired certificate
Renew immediately. If you use certbot, run sudo certbot renew --force-renewal and then reload your web server. Check your ACME cron job or systemd timer to ensure it is running correctly so the problem does not recur.
Incomplete certificate chain
Your server must send the full chain: your leaf certificate plus all intermediate certificates, up to (but not including) the root. Most CAs provide a "full chain" or "bundle" file. In Nginx, concatenate the leaf and intermediate into a single file and reference it with ssl_certificate.
Mixed content
If your page loads over HTTPS but includes resources (images, scripts, stylesheets) over plain HTTP, browsers will block those resources or show a "not fully secure" warning. Audit your pages for hardcoded http:// URLs and replace them with https:// or protocol-relative paths.
Wrong hostname (SAN mismatch)
If your certificate was issued for www.example.com but your users visit example.com, the browser will show a hostname mismatch error. Reissue the certificate with the correct Subject Alternative Names. Most CAs let you include both the bare domain and the www subdomain at no extra cost.
HSTS without a valid certificate
If you have deployed HSTS headers (particularly with includeSubDomains or HSTS preloading) and your certificate expires, users who have previously visited your site will be completely locked out. Browsers will refuse to connect, with no bypass option. This makes certificate monitoring even more critical for sites that use HSTS.
Check your Security Grade to analyse your SSL configuration alongside DNS, SPF, DKIM, and DMARC in one pass.
SSL protects transport; DMARC protects the sender
SSL/TLS secures the connection between a client and your server, ensuring data is encrypted in transit. But it does nothing to verify who sent an email on behalf of your domain. That is the job of DMARC, SPF, and DKIM. A complete domain security posture requires both: TLS for transport encryption and DMARC for sender authentication. Read our guide: What is DMARC?
Check your certificates now
Use our free SSL Checker to inspect your certificate expiry, chain, protocol version, and cipher suites in seconds. No signup required.
Need ongoing monitoring across all your domains? Create a free ShieldMarc account to get daily SSL checks with configurable expiry alerts, alongside DMARC reporting, domain health scoring, and brand protection.