How it works
Enter a hostname (for example cxo.tools) and a port: 443 is the default for HTTPS, but you can test TLS on other services such as 465 (SMTPS), 993 (IMAPS) or 636 (LDAPS). The tool opens a live TLS connection, reads the certificate the server presents, and reports it exactly as visitors see it right now.
The panel leads with a status badge, Valid, Expires ≤30 days or Expired, followed by an Issues box (a green line means none were found). Read the rest top to bottom:
- Days left / Valid to, the most actionable number. Certificates fail closed: the day they expire, browsers show a full-page block. Renew well before this reaches zero.
- Hostname match, must be Yes; it confirms the hostname appears in the certificate's Subject Alternative Names. A No triggers a name-mismatch warning for real users.
- Issuer, the CA that signed it. A recognised public CA is normal; a blank or unexpected issuer is worth investigating.
- Self-signed, should be No for public sites; a self-signed certificate does not chain to a trusted root, so browsers reject it.
- Protocol & Cipher, the version and suite that were actually negotiated. You want TLS 1.2 or TLS 1.3; TLS 1.0 and 1.1 are formally deprecated (RFC 8996).
- Subject Alternative Names, every hostname the certificate covers. A subdomain missing here is not protected.
- Certificate chain, the leaf certificate up through its intermediates. A missing intermediate causes "authority invalid" errors on some clients even when the certificate is otherwise fine.
Reading the output: what each field should show
| Field | What it tells you | Healthy value |
|---|---|---|
| Days left | Time until expiry | > 0, ideally renewed well before 30 |
| Hostname match | Hostname is listed in the SANs | Yes |
| Self-signed | Whether it chains to a trusted CA | No |
| Issuer | The signing Certificate Authority | A recognised public CA |
| Protocol | Negotiated TLS version | TLS 1.2 or TLS 1.3 |
| Chain | Leaf plus intermediate certificates served | Complete, in order |
| Issues | Problems detected during the check | None |
Public TLS certificates now have a maximum validity of 398 days, and 90-day certificates are common, which is why automated renewal, not a calendar reminder, is the reliable fix.
Frequently asked questions
My certificate is valid but users still get a warning, why?
The usual cause is a missing intermediate. Your server must send the leaf plus any intermediates; the root lives in the client's trust store and is not sent. If the chain shown here is incomplete, some browsers and many command-line clients report "authority invalid" even though the certificate is legitimate.
What is the difference between the Common Name and the hostname match?
Modern browsers ignore the certificate's Common Name and validate the hostname against the Subject Alternative Names (SANs). A certificate can have a plausible Common Name yet still fail if the exact hostname is absent from the SAN list, so trust the Hostname match field over the CN.
How early should I renew before expiry?
Leave enough buffer to catch a failed automated renewal: a week or more for short-lived certificates, and treat anything under 30 days as a warning. Expiry is a common avoidable outage precisely because the certificate works right up until the moment it does not.
Does this check whether the certificate was revoked?
No. This tool reads what the server presents - expiry, chain, hostname coverage and the negotiated protocol - but it does not query OCSP or CRL revocation status. A certificate can be validly dated and correctly chained yet still have been revoked by its CA, which is checked separately by the client at connection time.
Can I check a mail server or a non-web port?
Yes. Set the port to the TLS port of the service, for example 993 for IMAPS or 465 for SMTPS. The tool performs a direct TLS handshake on that port, so it works for any service that presents a certificate on connection.
This check is server-side: only the hostname and port you enter are queried, over a single live TLS connection, and nothing you enter is stored. It reads the public-facing certificate exactly as the server presents it, it does not check certificate revocation (OCSP/CRL) or inspect anything behind the connection. For a full audit, confirm the chain is complete and revocation status is current using your own tooling as well.