SSL Checker – Complete Guide to TLS Certificates, Chains and Expiry

A certificate expires on a Saturday and the monitoring that should have caught it only checked that port 443 was open. A mobile app fails with "unable to verify the first certificate" while the site works fine in desktop browsers. A new subdomain gets a certificate error because it is not on the certificate at all. All three can be seen in a single TLS handshake if you look at the right fields.

The SSL Checker connects to a host over TLS from the NetTools.tech server and reports whether the certificate is trusted and covers the hostname, how many days are left, the subject names, issuer, key size, negotiated protocol and cipher, and the certificate chain. Use it after installing or renewing a certificate, when clients report TLS errors, and to check mail, LDAP or DNS-over-TLS services on their TLS ports.

What is an SSL Checker?

In simple terms

When you connect to a site over HTTPS, the server presents a certificate: a signed statement that says "this key belongs to these hostnames, until this date", issued by a certificate authority (CA). Your client accepts it only if the signature chain leads to a CA it trusts, the dates are valid and the hostname is on the certificate. An SSL checker performs those same checks and shows you the details, so you can find the problem before your users do. ("SSL" is the old name; today the protocol is TLS.)

Technical background

Certificates follow the X.509 profile in RFC 5280. The fields that matter most:

• Subject alternative names (SAN): the DNS names (and possibly IP addresses) the certificate is valid for. Clients match the hostname against these entries; the old Common Name (CN) in the subject is no longer used for matching by modern clients. Wildcards (*.example.com) cover exactly one label. Matching rules are in RFC 6125.
• Validity: notBefore and notAfter. Outside that window the certificate is rejected.
• Issuer and chain: a server certificate (leaf) is signed by an intermediate CA, which is signed by a root CA in the client's trust store. The server is expected to send the leaf and the intermediates; the root is already on the client.

The certificate is delivered during the TLS handshake (TLS 1.3 is RFC 8446). Because many sites share an IP address, the client names the host it wants in the SNI (Server Name Indication) extension, and the server picks the matching certificate. A check without SNI can return a default certificate that has nothing to do with the site.

Why use the SSL Checker?

• Catch expiry early. See the days remaining and the exact expiry date.
• Find chain problems. A missing intermediate breaks many non-browser clients even when browsers work.
• Confirm hostname coverage. Check that every name you serve is in the SAN list before adding it to DNS.
• Verify a renewal or replacement. Confirm the new certificate is actually being served, not an old one cached in a load balancer.
• Check non-web TLS services. IMAPS, POP3S, SMTPS, LDAPS, DNS over TLS and SIP over TLS use certificates too.
• See the negotiated protocol. Confirm the server negotiates TLS 1.2 or 1.3.

Who should use it?

• System administrators and DevOps engineers deploying and renewing certificates.
• Web developers and site owners launching new domains or subdomains.
• Mail and directory administrators running IMAPS, SMTPS or LDAPS.
• Support and security teams investigating TLS errors reported by clients.

How the SSL Checker works

Your browser sends the hostname and port to the NetTools.tech server in Latvia, which then:

1. Validates the input. The host must be a public domain name; internal names are rejected. The port must be one of 443, 465, 636, 853, 993, 995, 5061, 8443 or 9443.
2. Resolves the name and refuses private, loopback, link-local and reserved addresses. The probe server currently connects over IPv4 only; a host without an IPv4 address is rejected with a message saying so.
3. Opens a TLS connection to that address and port, sending the hostname as SNI and offering ALPN h2 and http/1.1. The handshake must complete within 10 seconds. The connection is made with verification switched off so that invalid certificates can still be inspected; the verification result is recorded separately.
4. Evaluates the certificate:
   • Trust: whether the chain verifies against the trusted root certificates of the server's TLS library, with the library's error code if not.
   • Hostname: whether the leaf certificate's SAN entries cover the name you entered, using standard hostname matching.
   • Days left: whole days from now until the leaf's notAfter.
5. Walks the chain from the leaf through each issuer, up to 8 certificates, collecting subject CN, issuer CN and organization, validity dates, SAN list (up to 100 names), key size, serial number and SHA-256 fingerprint.
6. Closes the connection. Nothing is sent beyond the TLS handshake; no HTTP request is made.

It works only with implicit TLS: the handshake starts as soon as the TCP connection opens. Protocols that start in plain text and upgrade with STARTTLS (SMTP on 25/587, IMAP on 143, LDAP on 389) are not covered here; the SMTP Test handles STARTTLS for mail servers.

How to use the NetTools.tech SSL Checker

1. Open the SSL Checker.
2. Enter the hostname in the Domain field, for example example.com or www.example.com. Enter just the name: no https://, no path and no :port suffix.
3. Choose the Port from the menu. Leave 443 for websites; choose 993 for IMAPS, 465 for SMTPS, 636 for LDAPS, 853 for DNS over TLS, 995 for POP3S, 5061 for SIP over TLS, or 8443 / 9443 for alternative HTTPS ports.
4. Press Run SSL Checker, or use the example.com example chip.
5. Use Copy for the text output, or Open in terminal to run /ssl example.com --port 993 (aliases /tls and /cert) in the NetTools terminal.

Understanding the results

Common "Not trusted" codes:

• UNABLE_TO_VERIFY_LEAF_SIGNATURE or UNABLE_TO_GET_ISSUER_CERT_LOCALLY: the issuer could not be found, typically a missing intermediate certificate.
• CERT_HAS_EXPIRED: a certificate in the chain is expired.
• DEPTH_ZERO_SELF_SIGNED_CERT: the server presents a self-signed certificate.
• SELF_SIGNED_CERT_IN_CHAIN: the chain ends in a root that is not trusted, for example a private or corporate CA.
• CERT_NOT_YET_VALID: the notBefore date is in the future.

The chain table shows the chain as the TLS library assembled it. When verification succeeds, the last entry is usually the trusted root, which may come from the trust store rather than from the server, so the table is not an exact list of what the server sent. Use openssl s_client -connect example.com:443 -servername example.com -showcerts when you need that exact list.

Example: a renewal that broke mobile clients

After a manual renewal, Android users report errors on www.example.com, while desktop browsers work. The output below is illustrative.

Not trusted: UNABLE_TO_VERIFY_LEAF_SIGNATURE
Expires in 89 days (2027-01-14).
Subject      www.example.com
Issuer       Example Issuing CA R2 · Example Trust Services
Valid        2026-10-16 → 2027-01-14
Names (SAN)  www.example.com, example.com
Key          2048 bits
Protocol     TLSv1.3 · TLS_AES_256_GCM_SHA384
Server       203.0.113.80:443 · handshake 64 ms

The certificate itself is fine: new dates, correct names, a 2048-bit key. But only the leaf is being served, and without the intermediate "Example Issuing CA R2" clients cannot build a path to a trusted root. Desktop browsers had the intermediate cached; the apps did not. The admin replaces the certificate file with the full chain file from the CA (leaf followed by intermediate), reloads the web server and checks again:

Valid certificate for www.example.com.
Expires in 89 days (2027-01-14).

followed by a Chain table with the leaf at #0, the intermediate at #1 and the root.

Common use cases

• Verifying a new or renewed certificate right after deployment.
• Checking expiry dates of public endpoints.
• Confirming that a new subdomain is covered before switching DNS.
• Checking IMAPS (993), SMTPS (465) and POP3S (995) certificates on mail servers.
• Testing LDAPS (636) and DNS over TLS (853) endpoints.
• Spotting a TLS-inspecting proxy or a default hosting certificate by its issuer and subject.

Troubleshooting

Not trusted with UNABLE_TO_VERIFY_LEAF_SIGNATURE

The intermediate certificate is missing. Configure the full chain: in nginx the ssl_certificate file must contain the leaf followed by the intermediates; in Apache 2.4.8+ the same applies to SSLCertificateFile. Reload the service and check again.

Valid in the browser, failing elsewhere

This is usually a chain issue as above, or clients with an outdated trust store that do not know the CA's newer root. Compare the chain table with your CA's documentation.

The certificate does not cover the hostname

Check the Names (SAN) row. Common causes: the default certificate of a shared IP was served because the server has no matching virtual host for the name, example.com is missing from a *.example.com certificate, or a different service with its own certificate listens on that port.

TLS connection failed or no handshake within 10 s

The port may not speak TLS at all (plain HTTP on 8443, or STARTTLS on a mail port), may be firewalled, or the server may reject the offered protocol versions. Check the port with Port Check and confirm the service configuration.

The old certificate is still shown after renewal

The new files are on disk but the service has not reloaded them, or a load balancer, CDN or a different server behind the same name still serves the old one. The Server row shows which IP answered.

"No IPv6 connectivity" error

The host has only an IPv6 address. The NetTools.tech probe server cannot reach IPv6 targets yet, so test from an IPv6-capable host with openssl s_client.

Common mistakes

• Installing only the leaf certificate without the intermediate chain.
• Checking example.com when users visit www.example.com, or the other way round.
• Assuming a wildcard covers the bare domain or multi-level subdomains.
• Checking port 25 or 587 for mail TLS; those use STARTTLS and are tested with the SMTP Test.
• Renewing the certificate but forgetting to reload every service and load balancer that uses it.
• Treating a valid result as proof of a secure configuration. Protocol versions, ciphers and HSTS are separate topics.

Limitations

• One handshake from one place. The check runs from the NetTools.tech server in Latvia. Geo-routed CDNs or several servers behind one name can serve different certificates elsewhere.
• No revocation check. OCSP and CRLs are not queried.
• No protocol or cipher scan. Only the negotiated protocol and cipher are shown, not the full list of what the server accepts.
• Implicit TLS ports only. STARTTLS is not supported, and only the listed ports can be chosen.
• IPv4 only at the moment; IPv6-only hosts cannot be tested.
• Domain names only in the form, sent as SNI; servers that need a different SNI name than the hostname cannot be tested.
• Assembled chain. The chain table may include a root from the trust store; it is not a byte-for-byte list of what the server sent.
• Trust store. Trust is evaluated against the server's TLS library's root list, which can differ slightly from a given browser, operating system or device.

Security & privacy

The hostname and port are sent to the NetTools.tech server, which resolves the name and opens one TLS connection to it. The target sees a TLS handshake from the NetTools.tech server's address; no HTTP request, cookies or credentials are sent. Private and reserved addresses are blocked so the tool cannot be used against internal systems, and requests are rate limited and time limited. Certificates are public by design, so nothing sensitive is revealed by checking them. Never paste private keys into any online tool, including this one; the SSL Checker never needs them.

Related tools

• HTTP Status Checker – status codes, redirects and headers over HTTPS; guide: HTTP status checker.
• Whois – domain registration and expiry, the other date that can take a site down; guide: Whois lookup.
• MTA-STS Lookup – policies that require valid TLS certificates on mail servers; guide: MTA-STS lookup.
• Port Check – whether the TLS port is reachable at all; guide: Port check.
• SMTP Test – STARTTLS and certificate checks for mail servers; guide: SMTP test.
• Nslookup – confirm the hostname resolves to the server you expect.
• Category overview: DNS & domain tools.

Summary

The NetTools.tech SSL Checker performs one TLS handshake with SNI to a public host on a TLS port and reports whether the chain is trusted, whether the certificate covers the hostname and how many days remain, plus SANs, issuer, key size, negotiated protocol and the assembled chain. It does not check revocation, scan protocol versions or support STARTTLS. Most real-world failures it reveals are missing intermediate certificates, names missing from the SAN list and renewals that were never reloaded.