An expired SSL certificate

A "your connection is not private" warning stops most visitors - rightly so, because the browser cannot tell a forgotten renewal apart from a real attack. The good news is that it is almost always one of a handful of recurring causes.

First establish what exactly is wrong

Click the warning icon next to the address and open the certificate details. Three things matter: the expiry date, the domain name the certificate was issued for, and the issuer. From the command line it is quicker and more reliable:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com < /dev/null 2>/dev/null | openssl x509 -noout -dates -subject -issuer

The reply gives you the notBefore and notAfter dates and the domain in the subject field. That is enough to decide between the three most common scenarios.

The certificate has expired

The notAfter date is in the past. Let's Encrypt certificates are issued for 90 days and renewed automatically, usually around 30 days before the end - so an expiry almost never means "I forgot", it means "the automation stopped working". Check it with:

sudo certbot renew --dry-run

The test shows whether a renewal would go through at all. The usual reasons it stops:

• A change in the server configuration - redirecting all traffic to HTTPS can block the /.well-known/acme-challenge/ path used to verify the domain.
• The cron job or system timer stopped running, for instance after a move to another server.
• The domain no longer points at this server, so verification has no way to succeed.

A certificate for a different name

The second typical situation: the certificate is valid, but issued for yourdomain.com while the visitor arrives at www.yourdomain.com - or the other way round. The browser reports an error even though "SSL is there". The certificate has to cover both names, and one version should redirect to the other. With a wildcard certificate, keep in mind that *.yourdomain.com covers subdomains but not the bare domain itself.

An incomplete chain

The most deceptive case: the site works in a desktop browser but throws an error on a phone or in an application. That usually means the server is not sending the intermediate certificate. Some clients hold it in memory from other visits and some do not - hence the apparent randomness. The server configuration needs to point at the full chain (with Let's Encrypt, the fullchain.pem file, not cert.pem).

This is not the same as mixed content. If the padlock is struck through but there is no full-page warning, the certificate is fine - the page is simply pulling images or scripts over http://. The cause and the fix are entirely different: the addresses in the content and the template need correcting.

Keeping it from coming back

Two things remain after the fix. First, make sure renewal runs automatically and that somebody finds out when it stops - the simplest way is monitoring that checks the expiry date and warns a couple of weeks ahead. Second, if the site enforces HTTPS with an HSTS header, check this in advance: with HSTS enabled visitors cannot click "proceed anyway", so an expired certificate means the site is unreachable, not merely flagged.