Most "the site is broken" reports turn out to be a TLS issue. An expired certificate. A missing intermediate. The wrong hostname on the SAN list. These problems are invisible until the moment they aren't, and then they take down everything.
The good news: SSL/TLS certificate verification is fast, and you can do it from a browser without any local tooling. This guide walks through the workflow, what each field on the response means, and what to do when something's wrong.
What an SSL checker actually does
An SSL verification runs the same TLS handshake your browser runs. Specifically:
- Connects via TCP to the host on the given port (usually 443)
- Sends a TLS
ClientHellowith the hostname in the SNI (server name indication) field - Receives the server's certificate chain, the leaf certificate plus all intermediate CAs
- Reports back the chain, the validity dates, the SANs (subject alternative names), the key and signature details, and which TLS versions the server accepts, with the cipher for each
If you've ever run openssl s_client -connect host:443 -servername host, the SSL Certificate Checker is the same thing with the result rendered as a readable table instead of a wall of base64.
Step 1. Open the SSL Certificate Checker
Open the SSL Certificate Checker tool. Three fields: hostname, port, and IP version. Advanced options adds an SNI override, for testing a certificate under a different name.
Step 2. Enter the hostname
Enter the hostname: example.com. If you paste a full URL such as https://example.com/, the tool strips it down for you. Use the port field for the port. If you're checking a subdomain, api.example.com, mail.example.com, that's the hostname.
If the cert is set up with SNI (and modern TLS deployments effectively always are), the hostname you enter is the one being verified. The server may return different certificates for example.com and api.example.com even if both resolve to the same IP. Check the actual hostname users hit, not the IP behind it.
Step 3. Enter the port
Defaults to 443 (HTTPS). Other common TLS ports you might verify:
- 993 - IMAPS
- 995 - POP3S
- 636 - LDAPS
- 8443 - HTTPS on an alt port
SMTP ports 25, 465 and 587 can't be checked here. The handshake runs from our London probe, and DigitalOcean blocks those three ports on every Droplet, the probe's included, so the tool tells you the port can't be tested rather than reporting on your server. To read a mail server's certificate, run openssl from a machine whose network allows outbound SMTP:
openssl s_client -connect mail.example.com:465 -servername mail.example.com
openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com
For other STARTTLS-style protocols (IMAP on 143), this tool's direct TLS handshake won't work. Those start in plaintext and upgrade. The tool is for TLS-from-the-start ports.
Step 4. Run the check
Click Inspect certificate. The probe completes in under a second for most hosts. This is the real result for example.com on 7 November 2026, trimmed to the main fields:
VALID · 48d remaining
IPV4 · LONDON
172.66.147.243
handshake 11ms
TRUST Trusted, and valid for example.com.
SUBJECT example.com
ISSUER Cloudflare TLS Issuing ECC CA 3
VALID FROM 26 Sept 2026, 22:49 UTC
VALID TO 25 Dec 2026, 22:56 UTC
SANS example.com, *.example.com
PROTOCOL SUPPORTED CIPHER
TLS 1.0 Yes (deprecated) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS 1.1 Yes (deprecated) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS 1.2 Yes TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS 1.3 Yes TLS_AES_128_GCM_SHA256
CHAIN (4)
SUBJECT ISSUER
example.com Cloudflare TLS Issuing ECC CA 3
Cloudflare TLS Issuing ECC CA 3 SSL.com TLS Transit ECC CA R2
SSL.com TLS Transit ECC CA R2 SSL.com TLS ECC Root CA 2022
SSL.com TLS ECC Root CA 2022 AAA Certificate Services
What each part means:
| Field | What it means |
|---|---|
| Trust | Whether the chain validates and the certificate covers the hostname, in plain English. |
| Subject | The identity the certificate is issued to. |
| Issuer | The CA that signed this certificate. |
| Valid from | When the cert started being valid. Anything before this is rejected. |
| Valid to | When the cert expires. The big one. |
| SANs | Subject Alternative Names. Every hostname this certificate is valid for. |
| Serial, Sig algo, Key type | Trimmed above. Useful for verifying you and a colleague are looking at the same cert. |
| TLS protocols | Each TLS version the server accepts, with the cipher it negotiates. |
| Chain | Every certificate the server sent, leaf first. |
Plus the badges at the top:
- Verdict -
valid, or the problem that matters most:expired,name mismatch,not yet valid,chain incomplete, and so on. - Days remaining - green if over 30, amber from 8 to 30, red at 7 or under or once expired. Set a calendar reminder for any cert with <60 days; renewal can take time.
- Handshake - how long the TLS handshake took from London, next to the IP that answered.
If TLS 1.0 or TLS 1.1 shows Yes (deprecated), as both do above, the server still accepts versions RFC 8996 retired. The certificate can be perfectly valid and the server still configured insecurely.
Step 5. Verify what you actually need to verify
Different problems need different checks:
"Is this certificate going to expire soon?"
Look at the Days remaining badge. Common renewal cadences:
- Let's Encrypt: 90 days, renewed every 60. Most renewals are automated; if a Let's Encrypt cert has <30 days left, the renewal job is probably broken.
- Cloudflare-managed: usually 90 days, fully managed. You shouldn't need to think about it. (The
example.comcert above runs 90 days.) - Commercial CA (DigiCert, Sectigo): 200 days at most for certs issued since 15 March 2026, falling to 100 days in March 2027 and 47 days in March 2029. Renewal is often manual, which is getting harder to sustain; the 47-day schedule is the reason to automate now.
"Does this cert cover the hostname users are actually hitting?"
Check the SAN field. If users visit www.example.com but the SAN only lists example.com, mobile Safari and Chrome will both throw certificate warnings. The browser checks the visited hostname against the SAN list, not the CN (RFC 9525 rules the CN out entirely).
"Why is the chain failing on older devices?"
Check the Issuer. If it's an intermediate CA (anything not a well-known root), the cert needs to present the full chain, leaf → intermediate → root. Many TLS deployments accidentally serve only the leaf, which works in modern browsers (they fetch missing intermediates automatically) but fails on older clients, IoT devices, and Java HTTP clients.
To verify the full chain is being served, the tool shows the full chain in the result, and a chain incomplete badge when the server doesn't send its intermediate. If only one certificate is shown when there should be three, the server config is missing intermediates. Fix: configure your web server to serve the full chain bundle. (RFC 5280 defines how clients validate that path.)
"Why does this say expired when the renewal happened yesterday?"
Two possibilities:
- The server is still serving the old cert because it wasn't restarted after renewal.
nginx -s reloador equivalent. - There are multiple workers / load balancer instances and only some refreshed. Force restart on all.
Common SSL verification mistakes
Checking the wrong hostname. If your site uses www.example.com but you verify example.com, you may get a different cert (the apex redirect rule's cert vs the canonical site's cert). Always verify the hostname users actually visit.
Trusting "valid" without checking the chain. A cert with current dates and a matching SAN can still fail in production if the intermediate isn't served. Modern browsers paper over this; older clients don't.
Ignoring the cipher. Accepting TLS 1.0 or an RC4 cipher is a fail even if the cert itself is fine. Modern ops sec wants TLS 1.2+ with AEAD ciphers (anything with GCM or CHACHA20).
Forgetting OCSP / CRL. This tool checks the cert's static contents. It doesn't verify the cert hasn't been revoked. For revocation status, clients rely on CRLs and OCSP, and OCSP is on its way out: Let's Encrypt ended OCSP support in 2025. If you suspect a revocation issue, the Qualys SSL Labs test reports revocation status as a complement to this tool.
Set a renewal reminder
The number-one cause of "the site just stopped working" incidents is an expired certificate that nobody noticed. Automate or calendar it:
- For Let's Encrypt: monitor the cron / certbot logs. If a renewal fails three times in a row, page someone.
- For commercial CAs: a calendar reminder 30 days before expiry, with the renewal owner clearly identified.
A quarterly run of this tool against every domain you operate takes about 5 minutes per domain and is cheap insurance.
Related tools
- DNS Lookup - verify the hostname resolves to the expected IP first.
- Port Checker - confirm 443 is reachable before debugging the cert.
- HTTP Header Checker - once TLS is fine, the next layer.
TL;DR
- Open the SSL Certificate Checker.
- Enter the hostname users actually visit (with SNI in mind).
- Default port 443 unless you're checking a non-standard TLS service. SMTP ports 25, 465 and 587 can't be tested from our London probe.
- Run. Read the Trust line, then Issuer, Valid to, SANs, the TLS protocols table, and the Chain.
- The most common issues are expired, missing intermediate, and SAN mismatch. Each has a different fix and the tool surfaces enough info to tell which.