How to check when an SSL certificate expires

Browsers warn late

A certificate has a start time and an end time. After the end time, browsers stop loading the site and show a warning people will not click through. The warning does not arrive two weeks earlier as an email to you, unless you set something up that reads the date. Let's Encrypt certificates last about ninety days. Hosts that renew them automatically usually try well before the end. A renewal that silently fails looks healthy until the day the old certificate stops.

Expiry is also not the only way a certificate breaks a visit. The name on the certificate has to match the host people type. A certificate for www that is served on the apex, or a self-signed certificate a tool generated and forgot, fails even when the date is still in the future. The padlock disappearing is the customer's view. The date is the thing you can check before that.

What the date means

The relevant field is not-after, the moment the certificate stops being valid. Not-before is the moment it starts. A clock skew of a few minutes is normal. A certificate that expires today is already an outage for part of the world, because some clients treat the end as the end. Count days from now to not-after, in UTC, and renew while you still have a cushion. Fourteen days is a practical alarm for a ninety-day certificate. Thirty days is more relaxed and still fine if renewal is automatic and you only want to hear about a stuck job.

The issuer is who signed it: Let's Encrypt, your host's proxy, or a name you do not recognize. An issuer you did not choose can mean the host put its own certificate in front of yours, which is normal for some platforms, or that you are not talking to the server you think you are. Read the name on the certificate as well as the date.

What a one-host check does

The SSL tool connects to port 443 on the host you paste. It reads the certificate that handshake presents: the name, the issuer, the two dates, and how many days are left. If this check does not trust the chain, it still shows the dates and says why. Self-signed, a name that does not match, and an incomplete chain are different problems from 'the date is next year'.

It does not open the page in a browser, so it does not run your app and it does not spend a browser session. It does not try port 80, and it does not walk subdomains. A certificate on www is invisible if you only ask about the apex. Check each host that people use. It does not renew anything. If the date is close, renew at the host or the certificate panel, then run the check again.

What still needs a person

Automatic renewal fails for boring reasons: a DNS record moved, an HTTP challenge path was blocked, the account that issued the certificate lost permission, or a proxy is serving a certificate you uploaded by hand and then forgot. The check can tell you the date is near. It cannot tell you which of those caused it. If renewal is supposed to be automatic and the date is inside two weeks, look at the renewal log before you upload a new file at random.

A scheduled browser flow in WhoopsBot does not replace this. Flows open a page and follow steps. They do not read not-after. Use the certificate tool when you publish a domain, when you change DNS or the proxy, and any time a customer says the browser warned them. Use a flow for signup, login, and checkout, which keep working or breaking independently of the certificate date.

After it expires

If the date is already past, people cannot use the site until a valid certificate is served on that host. Renew or reattach it, then request the host again. A CDN sometimes keeps the old certificate in front until you purge it or the proxy picks up the new file. Confirm the issuer and the new not-after, not only that your control panel says active.

Then check the page itself. A certificate outage and a bad deploy can land on the same day. The free page check opens the URL and reports load errors, console errors, headers, and a few obvious leaks. It is the right second look once the handshake works again. It is the wrong tool for the date, which is why the certificate check is separate.

Check the host people actually type. A certificate that is valid on the apex and expired on www, or the other way around, still breaks half of your links. If both names answer, run the tool twice. A redirect from one to the other does not move the certificate. Each name presents its own during the handshake.