SSL Certificate Checker

What this checker actually reads

It opens a TLS connection to port 443 on the hostname you enter, completes the handshake, and reads the certificate chain the server presents. Nothing is stored, no account is created, and the check is a single ordinary HTTPS request of the kind the site receives thousands of times a day.

From that chain it reports the expiry date, the issuer, every hostname the certificate covers, the negotiated protocol version and cipher, and whether the intermediate certificates needed to build a path to a trusted root were actually sent. Those last two are where most surprises live.

The date is the easy part

Every certificate carries a notBefore and a notAfter date, and the countdown to notAfter is what most monitoring reports. It matters, but it is the failure mode people already have a plan for, because the browser error it produces is loud, immediate and unambiguous.

Certificate lifetimes have been shortening for years — a public certificate issued today is capped at a little over a year, and the industry timetable takes that considerably lower over the next few years. Shorter lifetimes mean automated renewal is no longer optional, and they also mean an automation failure has a much smaller window in which to be noticed.

The practical consequence: if you renew by hand, you have fewer chances to remember. If you renew automatically, the thing worth monitoring is not the date but whether the automation is still running.

Ways a valid certificate still breaks the site

A certificate can be entirely in date and still produce an error in a visitor's browser. These are the cases we see most often.

The name is not covered. The certificate is for example.com and the visitor asked for www.example.com, or a new subdomain went live and was never added to the list of covered names.

The chain is incomplete. The server sends its own certificate but not the intermediate that links it to a trusted root. Desktop browsers often paper over this by fetching the missing link themselves; many API clients, mobile apps and command-line tools do not, so the site works for you and fails for an integration.

The intermediate itself expired, or the root it chains to was distrusted. This is rare and spectacular when it happens, because it breaks every certificate under that issuer at once.

A redirect, load balancer or CDN in the path is serving a different certificate from the one you deployed.

What the grade is measuring

The configuration grade is not about the certificate so much as how it is served. Offering obsolete protocol versions, weak cipher suites, or an incomplete chain all cost points, and each has a specific fix that the result names rather than leaving you to search for.

A grade is a summary, not a verdict. A site can grade well and still be misconfigured in a way this check cannot see, and a site can lose points for something that is a deliberate compatibility decision.

What it cannot tell you

It reads the certificate you are serving, which means it is blind to certificates that exist for your domain and are being served somewhere else — a staging host, a subdomain pointed at a third party, a certificate taken by somebody who briefly had DNS access. Those are visible only in the public Certificate Transparency logs.

It also cannot see certificates inside a private network, and it cannot tell you whether your renewal automation will run next time. Both are arguments for continuous monitoring rather than a check you remember to perform.

Common questions