DEV Community

Cover image for SSL Certificate Expiry: The Silent Downtime Bomb
Jonathan Pimperton
Jonathan Pimperton

Posted on • Originally published at sitevett.com

SSL Certificate Expiry: The Silent Downtime Bomb

SSL Certificate Expiry: The Silent Downtime Bomb

It’s a scenario every web developer and agency dreads. A client calls, frantic. Their website is down, or worse, showing a terrifying "Your connection is not private" warning. Visitors are gone. The cause, often, is a simple oversight: an expired SSL certificate. This isn't a catastrophic hack; it's a ticking time bomb with a predictable fuse.

Ignoring SSL certificate expiry is like leaving your front door unlocked. It might be fine for a while, but eventually, someone will notice, and the consequences can be severe. For businesses relying on their website for revenue or customer interaction, this downtime translates directly into lost money and damaged reputation. Browsers are increasingly strict about security, and an expired certificate triggers immediate user distrust.

Checking Your Certificate's Status

Knowing when your certificates expire is the first line of defense. Thankfully, there are several straightforward ways to check.

For a quick command-line check, openssl s_client is a handy tool. Run it against your domain and port 443 (the standard HTTPS port).

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -dates
Enter fullscreen mode Exit fullscreen mode

This command pipes the connection output to another openssl command that extracts just the "notBefore" and "notAfter" dates, showing you precisely when your certificate becomes valid and, crucially, when it expires.

Alternatively, you can use your browser's developer tools. Navigate to your website, open the DevTools (usually F12), go to the "Security" tab, and click on the certificate information. This will often show you the expiry date directly.

For a more automated approach, various online SSL checker tools exist. Websites like SSL Labs (ssllabs.com) provide comprehensive reports, including certificate expiry dates, alongside many other security metrics. These are excellent for quick, at-a-glance checks across multiple domains.

Automating Renewal with Let's Encrypt

The advent of free, automated certificates from Let's Encrypt has drastically reduced the manual burden of certificate management. Tools like certbot are designed to automate the entire process, including renewal.

If you're using certbot with Apache or Nginx, the renewal process is usually handled automatically by a cron job or systemd timer that runs the certbot renew command.

For example, a common certbot cron job might look like this:

0 0 * * * certbot renew --quiet
Enter fullscreen mode Exit fullscreen mode

This runs the renewal check every day at midnight. certbot renew checks all installed certificates and renews any that are due for expiration within the next 30 days.

The Common Pitfall: Server Reloads

Here’s where many systems stumble, even with automated renewals. Let’s Encrypt and certbot are excellent at obtaining and renewing certificates. However, a certificate is only useful if the web server is aware of the new one. Many automated setups forget to tell the web server to reload its configuration to pick up the renewed certificate.

If certbot renews a certificate but your web server (like Nginx or Apache) hasn't been told to reload its SSL configuration, visitors will continue to see the old, soon-to-expire certificate until the server is manually restarted or reloaded.

certbot can often handle this for you if configured correctly. When you initially set up certbot with a web server plugin (e.g., certbot --nginx or certbot --apache), it typically adds a "deploy hook" or post-renewal hook. This hook is a command that runs after a certificate is successfully renewed. The common command for Nginx is:

systemctl reload nginx
Enter fullscreen mode Exit fullscreen mode

And for Apache:

systemctl reload apache2
Enter fullscreen mode Exit fullscreen mode

If you're not using a certbot plugin that handles this automatically, or if you're managing certificates manually, you must ensure your server configuration is reloaded after a certificate renewal. This is a critical step that is frequently missed, leading to the silent expiry bomb. Regularly testing your automated renewal process by forcing a renewal (e.g., certbot renew --force-renewal) and then checking your site is a good practice to ensure your hooks are working as expected.


SiteVett checks this automatically as part of a free website QA scan with 60+ checks across security, SEO, content, performance, and more.

Top comments (0)