About the SSL / TLS Checker
The SSL certificate checker opens a live TLS connection to a host and reads the certificate it actually presents. It reports the subject and issuer, every Subject Alternative Name (SAN) the certificate covers, the not-before and not-after dates with days remaining, the serial number and SHA-256 fingerprint, the full certificate chain from leaf to root, and whether that chain validates against the standard public trust roots. You can point it at any host and port, not just the default 443, so it also covers a mail server's SMTPS or IMAPS certificate or a service running TLS on a custom port.
Use it to catch a certificate before it expires and takes a site or a mail flow down with it, to confirm a freshly deployed certificate actually covers every hostname you serve, or to work out why a certificate that loads fine in one browser throws a trust warning somewhere else, most often a missing intermediate in the chain. It is also the fast way to see exactly what a monitoring alert or a customer's error message is reacting to, without reaching for openssl s_client on the command line.
People search for this both as an "ssl checker" and a "tls checker", and both point at the same tool. SSL is the retired name for the protocol, TLS is its current version, but the certificate itself is the same X.509 object either way, so this checker answers to both. It is a live, online check against a reachable host, not an offline parser for a certificate file you already have; the same lookup is also available as a JSON API and through the invoker.tools MCP for scripting and monitoring.
The TLS connection is made from our server, not your browser, and only the hostname you enter is sent to us to perform it. Private, loopback, link-local and other non-routable targets are refused before any connection is attempted, as an SSRF safeguard, so the checker cannot be turned into a probe against internal networks.
How to use it
- Enter the hostname you want to inspect, adding :port if it isn't the default 443, e.g. Mail.example.com:465.
- Submit to open a live TLS connection from our server to that host and port.
- Read the subject and issuer to confirm which certificate authority actually issued it.
- Check validTo and daysLeft to see how much runway is left before renewal is needed.
- Scan the SANs list to confirm every hostname you serve on that certificate is actually covered.
- Walk the chain and check the authorized field to see whether an intermediate is missing and whether the chain is trusted.
Examples
- Check mail.example.com:465 to confirm the SMTPS certificate actually matches the mail hostname, not just the main website's certificate.
- Point it at your own server's :8443 to confirm a non-standard HTTPS port serves a valid certificate before opening it to the internet.
- Compare a host's daysLeft before and after a Let's Encrypt renewal: it drops toward zero, then jumps back up to roughly 90 once renewed.
- Check a subdomain like staging.example.com and confirm the SANs actually list it, catching a certificate that only covers the apex domain.
- Try 127.0.0.1 or an internal address and get an immediate refusal, confirming the SSRF guard is doing its job.
What the check returns
Every lookup returns the same structured fields, whether you're reading them on the page or consuming the JSON API directly.
- host, port and the resolved ip actually connected to
- authorized: whether the chain validates against public trust roots
- cert.subject and cert.issuer (common name, or organization if no CN)
- cert.sans: every Subject Alternative Name on the certificate
- cert.validFrom, cert.validTo and cert.daysLeft
- cert.serialNumber and cert.fingerprint256 (SHA-256)
- chain: the subject/issuer of every certificate from leaf to root
- warnings: plain-language flags for expiry and trust problems
SSL vs TLS: same certificate, two names
SSL 2.0 and 3.0 are retired protocol versions; TLS 1.2 and 1.3 are what every modern browser and this checker actually negotiate today. The certificate format underneath, X.509, hasn't changed with the rename, which is why "SSL certificate" and "TLS certificate" describe the exact same file in practice. If a host only speaks the old SSL protocol, the connection itself fails before any certificate is even returned, so in effect every check here is a TLS check regardless of which name you searched for.
Reading the chain and common trust errors
The chain array walks issuer links from the certificate the server sent (the leaf) up to a root, so a missing hop is easy to spot. The most common trust failures and what they actually mean:
- unable to get local issuer certificate: an intermediate CA certificate is missing from what the server sends, so the path to a trusted root can't be built even though the leaf certificate itself is fine
- self signed certificate: the leaf's issuer is itself, so no public root trusts it (normal for an internal tool, a red flag on a public site)
- certificate has expired: validTo has already passed; daysLeft goes negative and a warning fires automatically
- hostname mismatch: the name you connected with isn't listed in the SANs, which browsers show as a common-name-invalid error
What this tool is not
This is a live, online check against a host and port that's actually reachable over the network. It does not accept an uploaded certificate file for offline inspection, and it checks one host per query rather than sweeping every virtual host behind a single IP. If you already have a saved certificate file, openssl x509 -in cert.pem -noout -text run locally is still the right tool for that job.
Frequently asked questions
What is the difference between an SSL checker and a TLS checker?
None in practice. SSL is the retired name for the protocol and TLS is its current version, but the certificate they both secure is the same X.509 object, so "SSL checker" and "TLS checker" describe the same lookup. This tool answers to both names.
Is this SSL certificate checker free?
Yes, it's free with no signup. The same lookup is also available as a JSON API endpoint and through the invoker.tools MCP if you want to script it or wire it into monitoring.
Can I check a certificate offline, from a file I already have?
No. This tool connects live to a host and port and inspects the certificate the server actually presents; it doesn't accept an uploaded .pem or .crt file. For a saved certificate file, run openssl x509 -in cert.pem -noout -text locally instead.
What does the certificate chain checker actually show?
The chain is the sequence of certificates from the one the server sends, the leaf, up through any intermediate authorities to a trusted root. This tool walks that chain and lists the subject and issuer of each link, so a missing intermediate, one of the most common causes of a certificate working in some clients but not others, is easy to spot.
How do I check when my SSL certificate expires?
Enter the host and read validTo and daysLeft in the result. A warning appears automatically once fewer than 15 days remain, and immediately if the certificate has already expired.
Why does it say the chain is not trusted?
Usually because an intermediate certificate is missing from what the server sends, the certificate is self-signed, or it was issued by an authority outside the standard public trust store. The authorized field and its accompanying warning explain which case applies.
Can I check a non-standard TLS port, like a mail server's?
Yes. Add the port after the host, for example mail.example.com:465 or mail.example.com:587, and the checker connects on that port instead of the default 443.
Why was my check refused for a private or internal address?
Private, loopback, link-local and other non-routable addresses are refused as an SSRF safeguard, so the checker can't be used to probe internal networks. Point it at a publicly reachable hostname instead.
Does entering a hostname route my own traffic through your server?
No. The TLS connection used to inspect the certificate is opened from our server, not your browser; only the hostname you type is sent to us to perform that connection.