SSL/TLS Checker

Bulk TLS / SSL certificate inspector

Open a TLS handshake against a host and surface the certificate it presented — who it was issued to, which CA signed it, when it expires and which hostnames it covers. Submit up to 100 hosts in one bulk check and the result lands in a single side-by-side table you can export.

What does this tool actually do?

Per submitted target we open an outbound TLS connection (ssl://host:port, 5-second timeout), capture the certificate the server presents for that SNI, parse its X.509 fields with OpenSSL and surface the readable bits as columns. We do not validate the chain, check revocation, or grade the protocol — that's deliberately out of scope here. Use one tool for one job.

Input formats accepted

• example.com — default port 443.
• example.com:8443 — for TLS on a non-standard port (Postgres, RabbitMQ, IMAPS, custom services).
• https://example.com/path — scheme and path are stripped.
• [2001:db8::1]:443 — bracketed IPv6 syntax.

What this tool returns

Host

host:port the handshake was performed against — useful for confirming you reached the non-default port you intended.

Issued to

Subject Common Name (CN) of the certificate. With modern Let's Encrypt / public-CA certs the CN is just one of many names — see SAN for the full coverage.

Issuer

Certificate Authority that signed the leaf — the Organisation field if present, otherwise the issuer CN. Examples: Let's Encrypt, Sectigo Limited, DigiCert Inc..

Valid from

The notBefore date — when the certificate started being valid. Visible on the single-host detail card.

Valid until

The notAfter date — when the certificate expires.

Days left

Whole days remaining until expiry. 0 means the cert expires today or is already expired — sort the table by this column to surface what needs renewing now.

Serial

Hex serial number assigned by the CA. Visible on the single-host detail card.

SAN

Subject Alternative Names — every hostname the cert covers. Modern certs sometimes carry dozens of SANs; we truncate to 240 characters with a trailing … so the table cell stays readable.

Why do this?

Expiry monitoring

A 30-second bulk check is faster than logging into every CA dashboard, ACME client and load balancer. Sort by Days left and your renewal worklist drops out.

Inventory & audit

Confirm the same CA is used estate-wide, spot rogue self-signed certs, find services on non-default ports that shouldn't be there.

Post-renewal verification

After an automated renewal pipeline (cert-manager, ACME), re-check the affected hosts to confirm the new cert is actually being served. The Valid until column tells you in seconds.

SAN coverage check

Make sure every alias your apex covers is in the SAN list. Missing a SAN entry is one of the most common "TLS works on www but not on apex" causes.

What this tool does NOT do

• Validate the chain. We disable verify_peer so we can also fetch info from expired, self-signed or mis-issued certs — useful for diagnostics but not a trust verdict.
• Show the protocol / cipher. No TLS 1.2 vs 1.3, no cipher suite, no key-exchange details.
• Show the chain. Only the leaf certificate's fields are surfaced; intermediate and root CAs are not displayed.
• Check revocation. No CRL fetch, no OCSP, no stapling status.
• Check CT logs. No certificate transparency lookups.
• Grade the configuration. No Qualys- SSL-Labs-style scorecard.
• Test STARTTLS. Only direct TLS is attempted — SMTP/IMAP/POP3 STARTTLS upgrades aren't negotiated.

If any of those matter for your use case, this tool is a useful first pass — pair it with the dedicated tool for that specific question.

Bulk mode

Drop up to 100 hosts in the textarea, one per line — mixing default-port and host:port entries is fine. Each row is handshake'd, parsed and rendered into the comparison table. The result is exportable to CSV / JSON / YAML / XML. Common workflows: quarterly cert-expiry audits, pre-migration inventories, post-incident sweeps to confirm rotated certs are live.

Common reasons a check fails

• TLS handshake failed — the port isn't open, doesn't speak TLS, or refuses our IP. Common when checking internal-only services from the public internet.
• Timeout — slow upstream or firewalled. We give up after 5 seconds per host.
• No peer certificate — handshake completed but the server didn't present a cert (e.g. some test endpoints). Rare in practice.
• Cannot parse certificate — the cert is structurally broken. Rarer still, but it happens.
• SNI mismatch — host accepts a connection but presents a cert for a different name. We still parse and surface what was presented; check the Issued to and SAN columns.

Best practices we'd back

• Automate renewals — ACME / cert-manager / your CA's API. Manual renewals fail at the worst possible moment.
• Monitor expiry on every public hostname, not just www. Wildcard certs hide misses.
• Keep SANs in sync with DNS — every alias you publish should be a SAN.
• Don't pin to a single CA in operational scripts — CAs do go offline.
• Inspect the chain (and CT logs) separately when you need a trust verdict; this tool is for fast field-level inspection.

Related tools

Pair this with DNS records lookup (verify the apex / SAN names resolve where you expect), WHOIS & RDAP lookup (registrar & expiry context for the domain itself), HTTP headers (confirm Strict-Transport-Security is set once you've fixed TLS), and domain & IP lookup (GeoIP / ASN on the addresses your hostnames resolve to).

Get started

Paste one or more hostnames in the form above — with or without port, with or without https://. Single submissions render as a detail card with every parsed field; bulk submissions as a side-by-side table you can scroll horizontally and export.