How to verify an SSL certificate

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:

1. Connects via TCP to the host on the given port (usually 443)
2. Sends a TLS ClientHello with the hostname in the SNI (server name indication) field
3. Receives the server's certificate chain, the leaf certificate plus all intermediate CAs
4. Reports back the chain, the validity dates, the SANs (subject alternative names), the cipher and protocol version, and the fingerprint

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. Two fields: hostname and port.

Step 2. Enter the hostname

Enter the hostname without protocol. example.com, not https://example.com. No path, no trailing slash, no port (use the port field for that). 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:

• 465 - SMTPS (legacy)
• 587 - SMTP submission with STARTTLS
• 993 - IMAPS
• 995 - POP3S
• 636 - LDAPS
• 8443 - HTTPS on an alt port

For STARTTLS-style protocols (SMTP submission on 587, 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. You'll see a result table with these fields:

Plus three badges at the top:

• Days remaining - green if >30, amber if <30, red if expired. Set a calendar reminder for any cert with <60 days; renewal can take time.
• Protocol - e.g. TLSv1.3. If you see TLSv1.0 or TLSv1.1, the server is configured insecurely.
• Cipher - the actual cipher suite negotiated, e.g. TLS_AES_256_GCM_SHA384.

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. 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.
• Commercial CA (DigiCert, Sectigo): 1 year. Renewal is manual; calendar reminder mandatory.

"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.

"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. 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.

"Why does this say expired when the renewal happened yesterday?"

Two possibilities:

1. The server is still serving the old cert because it wasn't restarted after renewal. nginx -s reload or equivalent.
2. 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. A TLSv1.0 or RC4 cipher is a fail even if the cert itself is fine. Modern ops sec wants TLSv1.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, the browser handles it via OCSP stapling. But if you suspect a revocation issue, the Qualys SSL Labs test covers OCSP in depth 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

1. Open the SSL Certificate Checker.
2. Enter the hostname users actually visit (with SNI in mind).
3. Default port 443 unless you're checking a non-standard TLS service.
4. Run. Read the Subject, Issuer, Valid to, SAN, Protocol, and Cipher fields.
5. 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.