SSL checker guide: read a certificate before it breaks

The checker performs a TLS handshake with your domain on port 443 and captures the certificate chain the server sends back. From the leaf certificate — the one issued for your domain — it extracts the subject and the Subject Alternative Names, which together list every hostname the certificate is valid for. This is where www surprises live: a certificate for example.com does not cover www.example.com unless the SAN list says so, and vice versa.

The validity window is two timestamps, not-before and not-after, and the days-until-expiration figure is derived from the second one. The issuer field names the certificate authority — Let's Encrypt, DigiCert, Sectigo, GlobalSign, or a cloud provider's own CA — which matters mostly for knowing where renewal happens and what the certificate's lifetime is likely to be. Let's Encrypt certificates run 90 days by design; paid certificates have historically run about a year.

Beyond the certificate itself, the check reports connection properties: which TLS protocol versions the server accepts and which cipher suites it negotiates. Modern configuration means TLS 1.2 and 1.3 only. Anything still offering TLS 1.0 or 1.1 fails compliance baselines like PCI DSS and triggers warnings in current browsers, and the fix is a one-line change in the web server or load balancer configuration.

When a browser connects over HTTPS, the server presents its certificate during the TLS handshake, and the browser has to answer one question: does an unbroken chain of cryptographic signatures connect this certificate to an authority I already trust. The browser ships with a trust store — roughly 150 root CA certificates baked into the operating system or browser — and your site's certificate is never signed by a root directly. It is signed by an intermediate certificate, which is signed by the root, forming a chain: leaf, intermediate, root.

Validation walks that chain. Each certificate's signature is verified against its issuer's public key, hop by hop, until the walk lands on a root in the trust store. Alongside the signature math, the browser checks that the current time falls inside every certificate's validity window, that the hostname in the address bar matches an entry in the leaf's SAN list, and that no certificate in the chain has been revoked. Any single failure aborts the connection with a warning.

The chain explains the most confusing failure in the business: the incomplete chain. Servers are supposed to send the leaf plus all intermediates, but a server configured with only the leaf will still work in Chrome and Safari — both can fetch missing intermediates on the fly or have them cached. Then a customer on an older Android device, a curl script, or a payment provider's API client hits the same site and fails hard, because stricter clients only trust what the server actually sends. This is why it works in my browser is worthless evidence for TLS problems, and why a checker that inspects the served chain settles the argument in seconds.

One more moving part: the certificate proves identity, not encryption strength. Encryption is negotiated separately in the handshake, via the TLS version and cipher suite. That is why a check reports both — a perfectly valid certificate can sit on a server still speaking a protocol version from 2008.

Most SSL problems collapse into a short list of causes, and the checker's output tells you which one you have. Match the symptom to the finding and the fix is usually mechanical.

After every certificate installation or renewal. Deployment is where things go wrong: the new certificate is on the load balancer but not the origin, the intermediate file was forgotten, or one of four edge servers kept the old certificate. A post-deploy check verifies what is actually being served, not what the control panel claims.

When a customer reports an error you cannot reproduce. Reports like your site says not secure arrive while everything looks fine on your machine — the incomplete-chain signature, or a CDN serving different certificates in different regions. Checking from a neutral vantage point shows what external clients receive rather than what your primed browser cache shows you.

Before a launch or campaign. A product launch that sends thousands of paid clicks at a landing page whose certificate expires mid-campaign is an expensive way to discover renewal dates. Checking every domain involved — including the link-shortener domain and the tracking subdomain — takes a minute and belongs on the pre-flight list.

On a renewal calendar. Let's Encrypt certificates expire every 90 days, which means automation is mandatory — and automation fails quietly: a changed DNS record, an expired API token, a renewal cron job lost in a server migration. A monthly check of your domains, plus an alert threshold at 30 days remaining, catches a dead renewal pipeline while there is still time to fix it calmly. Anyone running more than a handful of domains has been saved by this habit at least once.

Certificate lifetimes have been shrinking for a decade and the trend is accelerating. Public certificates have been capped at 398 days since 2020, Let's Encrypt normalized 90-day certificates years before that, and the CA/Browser Forum has approved stepping maximum lifetimes down over the coming years toward 47 days by 2029. The direction is unambiguous: manual renewal is being deliberately engineered out of viability, and every operator will end up on automation.

The durable setup is therefore automation plus verification. Let the ACME client — certbot, or the built-in support in Caddy, Traefik, and most managed platforms — handle issuance and renewal, and treat periodic external checks as the smoke alarm that tells you the automation is still alive. Check after every deploy that touches TLS, check monthly otherwise, and investigate any certificate that gets within 30 days of expiry without renewing, because a healthy ACME setup renews around 30 days out and one that has not is telling you something is broken.

Keep an inventory while you are at it. Expiry incidents disproportionately involve the forgotten certificate — the API subdomain, the staging environment a customer somehow bookmarked, the domain bought for one campaign. A checker only protects the domains you remember to point it at, so the list is half the defense.