SSL certificate checker

A standard certificate proves two things: the connection is encrypted, and the server you reached controls the hostname you asked for. That is all, and it is enough for a content site. It says nothing about who runs the site, whether the business is real, or whether the content is trustworthy, which is why a padlock has never been a trust badge and why phishing sites have valid certificates too.

Organisation and extended validation certificates add checks on the legal entity behind the domain, and browsers stopped showing that distinction prominently years ago. For a publisher, they buy nothing a free certificate does not already provide. Where money changes hands and a compliance requirement names them, that is a different decision, and it is a legal one rather than a technical one.

The upgrade worth making instead is HSTS, which tells browsers to refuse plain http for your domain in future. It closes the gap where the very first request goes out unencrypted before your redirect answers, and unlike a certificate upgrade it costs one header. Add it after you are confident every subdomain is on https, because it applies to all of them and it is deliberately hard to undo.

Certificates are short-lived now, typically 90 days, on the reasoning that anything renewed that often has to be automated. The automation is reliable and the things around it are not, which is why expiry remains a common outage on otherwise well-run sites.

The failures are consistent. The renewal job runs on a server that was replaced. Port 80 gets firewalled off, and the challenge that proves domain control cannot complete. DNS moves to a new provider and the API credentials for the DNS challenge are never updated. A CDN sits in front and serves its own cached certificate while the origin renews happily behind it. In every case the renewal fails quietly and the site keeps working, right up to the day it does not.

So treat the 30-day warning here as the monitoring rather than the nuisance, confirm at least one renewal has actually completed before trusting the setup, and check the full chain is served rather than the leaf alone. And when a certificate does move, re-check that the sitemap lists https URLs and that the handshake is not adding latency from a badly placed origin.

The certificate problems worth a walkthrough are the ones you cannot reproduce, and the most common is the incomplete chain. A fraction of visitors report security warnings, you check on your own browser and everything is fine. What happened: the server is sending only the site's own certificate, without the intermediate certificate that links it to a trusted root. Browsers that have seen that intermediate before have it cached and connect happily; a fresh install, an older Android device or a command-line client fails with an unable to verify message. The fix is configuration, serve the full chain file instead of the leaf alone, and the reason it survives so long is that the person who could fix it is the least likely to ever see it.

The second mystery is the name mismatch after a change nobody connected to certificates. The site standardises on www, or adds a shop subdomain, and the certificate covers example.com alone. Browsers refuse outright with a name error. A certificate is only valid for the names listed in it, so the fix is reissuing with every hostname you serve listed, which automated issuers do free provided you ask for both names.

The third involves a CDN, where TLS terminates in two places. The visitor's connection ends at the edge with the CDN's certificate, and the CDN connects onward to your origin with yours. Either can expire independently: an origin certificate lapses and the site stays up until the edge cache misses, or the edge certificate misbehaves while your origin tests clean. When a certificate problem appears on a proxied site, check both hops before concluding anything.

All three are invisible from the inside, which is the argument for testing from the outside. An external probe, this one or any TLS checker, sees the chain as served, the names as listed and the days remaining, with no cache to flatter the result. After any certificate change it is also worth re-running the wider technical pass, because the http to https redirect and the mixed-content scan cover the two ways a protocol change quietly multiplies URLs. If you want to see what the probe sees with your own eyes, any browser will show the served chain in the certificate viewer behind the padlock icon, and openssl s_client -connect yourdomain.com:443 prints it in a terminal: the names covered, the issuer, the dates, and whether the intermediate arrived. Reading it once demystifies every mystery above.