Do I need an account to check a certificate?
No. The checker on this page runs a real handshake without signing in. An account is only needed for saved monitors, daily scheduled checks, history, and email alerts.
Live handshake
SSL certificate checker
Enter a public hostname. ExpiryBeacon resolves it, opens a TLS connection from the server, and returns the certificate that endpoint actually presents — no account, no sign-up, no cached third-party record.
Try:
A real TLS connection is made from the server. URLs, IP addresses, localhost, and private ranges are refused before anything is opened.
Every field a check returns
The same fields appear in the signed-out checker and on a saved monitor, so a search visitor sees exactly what an account holder sees.
| Field | What it tells you |
|---|---|
| Valid from / valid until | The certificate's own notBefore and notAfter values, shown in UTC. |
| Days remaining | Whole days between now and notAfter, rounded down. A negative value means the certificate has already expired. |
| Trust result | Whether the chain the server sent validates against the public root store, plus a readable reason when it does not. |
| Issuer | The certificate authority that signed the leaf, taken from the issuer field rather than guessed from the hostname. |
| Subject | The common name and organisation on the leaf certificate. |
| Subject alternative names | The hostnames this certificate actually covers, including wildcard entries. |
| Chain depth | How many certificates the server presented, counting the leaf. A depth of one usually means a missing intermediate. |
| Protocol and cipher | The TLS version and cipher suite negotiated for this connection. |
| SHA-256 fingerprint and serial | Two stable identifiers you can compare against a renewal to confirm the new certificate is actually being served. |
| Resolved address | The public IP the handshake was made against, so a multi-origin hostname is not ambiguous. |
What “browser trusted” means in this result
The trust line reports whether the chain the server sent can be validated against the public root store, using the hostname you entered. That is the same question a browser asks, and it is separate from whether the certificate is still inside its validity window — a certificate can be perfectly current and still fail to validate.
When validation fails, the checker translates the underlying reason instead of printing a raw code. A self-signed certificate, a chain containing a self-signed certificate, an issuer that could not be retrieved, a leaf signature that could not be verified, and a certificate that simply does not cover the hostname all produce different, readable explanations.
The most common of these in production is a server that sends only its leaf certificate. Desktop browsers often paper over it using a cached intermediate, so the site looks fine to you and fails for a fresh client. Chain depth is shown for exactly this reason: a depth of one on a publicly issued certificate is worth investigating.
What the checker refuses, and why
The checker makes outbound connections on your behalf, so the target is validated before any socket is opened.
- Full URLs and anything with a scheme or path — enter the hostname on its own.
- Literal IP addresses, in either IPv4 or IPv6 form.
- Hostnames that resolve to loopback, private, link-local, carrier-grade NAT, documentation, or multicast addresses, including names deliberately pointed at 127.0.0.1.
- Ports other than 443, 8443, and 9443.
- Bursts above 12 inspections a minute from one address.
Turning a check into a monitor
The checker answers today's question. If the answer matters again next month, save it.
Add it to the watchlist
Signed out, the endpoint is stored in your browser and refreshed only when you ask. Nothing is sent to an account.
Sign in with Google
A saved monitor moves to your account, which is what enables the daily scheduled check at 08:00 UTC and a durable check history.
Choose a warning window
Set 30, 14, or 7 days on that monitor, and enable email alerts in the account policy if you want to be told about state changes.
Questions about ssl certificate checker
Is this reading a cached record?
No. Each check performs a fresh DNS resolution and a fresh TLS handshake from the server, and the resolved IP address is shown in the result so you can confirm which origin answered.
Why does the result differ from my browser?
Usually because of a cached intermediate certificate. Browsers can complete a chain your server did not send, so a site that looks trusted in your window can fail for a client without that cache. Chain depth in the result shows how many certificates the server actually presented.
Can I check a certificate by IP address?
No. IP literals are rejected before any connection is made, and hostnames that resolve to private or reserved ranges are refused. Certificates are validated against a hostname, so a check without one would not mean much anyway.