Inspect a site's certificate, chain, and expiry in seconds.
Runs against a live TLS connection or the certificate you paste in — nothing here is stored or sent anywhere else.
Enter a hostname and the checker opens a real TLS connection to it on port 443, then reads back the certificate the server actually presents. That distinction matters: it reports what your visitors are being served right now, not what a configuration file says should be served.
The days-remaining figure is the number that matters operationally. A certificate does not degrade as it approaches expiry — it works perfectly until the notAfter timestamp passes, and then every client rejects it at once. There is no partial failure and no grace period, which is why expiry outages tend to be total and sudden.
Treat anything under 30 days as needing action, and anything under 14 days as urgent, particularly if renewal involves a purchase, a validation step, or a change window.
"Trusted" means a chain of signatures from this certificate up to a root certificate in the trust store verified successfully. "Not trusted" does not necessarily mean the certificate is bad — the most common cause is a server that holds a perfectly valid certificate but does not send the intermediate certificates a client needs to link it to a root.
If you see "not trusted" and the dates look fine, run the domain through the Chain Tester next.
Modern certificates carry the hostnames they are valid for in the SAN extension; the legacy common name field is effectively ignored by browsers. If a hostname is not in the SAN list, that hostname will fail even though the certificate is otherwise healthy.
This is worth checking after any change to your domain layout. Adding a new subdomain to a load balancer does not add it to the certificate.
RSA 2048 and ECDSA P-256 are both fine today. What you are looking for is anything older: a SHA-1 signature or a 1024-bit RSA key means an old certificate that clients have already begun to reject, and it should be reissued rather than renewed as-is.
Connection refused or timed out. Nothing is listening on port 443, a firewall is dropping the connection, or DNS points somewhere unexpected. This is a network problem, not a certificate problem.
Expired. The notAfter date has passed. Every client will reject the certificate until it is replaced.
Self-signed. The certificate signed itself instead of being signed by a certificate authority. Fine for internal services with a distributed trust store; broken for anything a browser will visit.
Hostname not in the SAN list. The certificate is valid but was issued for a different name — common after a domain migration, or when a shared load balancer serves a default certificate.
A manual check tells you about one domain at one moment. The certificates that cause outages are rarely the ones anyone thought to check — they are on the staging subdomain, the internal API, or the marketing microsite that a contractor set up two years ago.
Renew Radar runs this same check on a schedule across every domain you add and emails you before anything gets close to expiring. It is free while in beta for up to 20 certificates.
Enter the domain above. The checker opens a TLS connection to port 443, reads the certificate the server presents, and shows both the "valid to" date and the number of days remaining, so you can see at a glance how much runway you have.
Almost always an incomplete chain. Desktop browsers cache intermediate certificates they have seen before and can paper over a server that fails to send them; curl, Java, and older Android clients cannot. The Chain Tester will show you exactly which certificates your server is sending.
It means a verified path from the certificate to a root in the trust store could not be built. The usual causes are a missing intermediate, a self-signed certificate, a certificate issued for a different hostname, or an expired certificate somewhere in the chain.
Only if they are listed as subject alternative names on the same certificate, which the result lists in full. A wildcard SAN such as *.example.com covers one label — app.example.com but not app.eu.example.com. Subdomains served by different infrastructure will have their own certificates and need checking separately.
No. The check runs for the duration of the request and the result is returned to you. Nothing about a one-off lookup is written to a database.
