SSL certificate checker

What this checker looks at

The check is a single TLS handshake, the same one your browser performs before it asks for a page, stopped at the moment the server presents its certificate. From that we read four things that decide whether visitors get a padlock or a warning: the validity window and how many days are left on it, the names the certificate covers (its common name and every subject alternative name), whether the hostname you entered is one of them, and whether the chain the server sent actually verifies against the public trust store. Nothing beyond the handshake is requested, so no page, redirect, or cookie is involved.

The three failures that catch people out

An incomplete chain is the classic one. The server sends its leaf certificate but omits the intermediate that links it to a trusted root. Desktop browsers often paper over this by caching intermediates from earlier visits, so the site looks fine to the person who deployed it and breaks for mobile clients, API consumers, and anything running curl. That is why this tool verifies the chain rather than only reading the leaf.

The wrong virtual host is the second. When several sites share an address, the server picks a certificate based on the SNI name in the handshake; if that mapping is missing or stale, the default certificate is served instead and the hostname simply does not match. The report above shows the names the certificate covers, which usually makes the mismatch obvious at a glance.

An expired intermediate is the third and the most confusing, because your own certificate is still perfectly valid. The chain above it is not, so clients reject it anyway. Renewing the leaf changes nothing until the intermediate bundle on disk is refreshed too. It is worth re-checking after every renewal rather than assuming automation got it right, since a renewal that writes the leaf but not the bundle fails silently.