The most expensive certificate problems are the ones a browser will hide for you. Chrome will accept a chain that’s missing an intermediate as long as it’s seen the intermediate elsewhere — meanwhile every curl, every Java client, every old Android, and every monitoring probe will fail. A renewal that shipped the wrong SAN list won’t show up until the first user with the wrong host visits. A weak protocol or cipher is invisible until a compliance scan flags it. The PortJar SSL/TLS Certificate Checker pulls every fact about what the server is actually serving and puts it on one page.
What the tool does
The checker opens a TLS connection to a host and port you specify (default 443) and parses the certificate the server presents. It returns the subject and issuer, the validity window, the full Subject Alternative Name list, the chain as the server actually sent it, the negotiated TLS version and cipher suite, and a verdict on whether the chain is trusted by a standard CA bundle. It flags expired certificates, self-signed ones, and chains that won’t validate against public trust roots. The result is what a fresh, well-behaved TLS client sees on the first connection — no cached intermediates, no browser-specific fix-ups.
The checker runs against any host on any port that speaks TLS, not just web servers. SMTP on 465, IMAPS on 993, LDAPS on 636, a database on a custom port — anything that completes a TLS handshake will return a certificate the tool can parse.
How to use it
Open portjar.com/tools/ssl-certificate, enter the hostname (with the port if it isn’t 443), and run. The verdict comes back in a couple of seconds. The URL is stateless and shareable — drop it into a ticket and the next person sees the same certificate when they reload.
When you’d reach for it
- Verifying a renewal actually shipped. After a Let’s Encrypt, ACM, or commercial CA renewal, the checker confirms the new validity window is in place and the SAN list still covers every host that needs it. Doing this before pointing monitoring at the certificate saves you from chasing your own tail.
- Diagnosing “it works in Chrome but breaks in curl.” Almost always a missing intermediate. The chain view tells you exactly what the server sent, which is the actual problem — Chrome filled in the missing piece from its own cache.
- Confirming a vanity or partner subdomain is on a certificate that covers it. Wildcard certificates often miss a single host added later. The SAN list shows you whether the host you care about is covered or not.
- Checking certificate health on non-web services. SMTP relays, IMAP/POP servers, LDAP directories, and database listeners all serve certificates that nobody looks at until renewal day fails. Running the checker on port 465, 993, 636, or wherever the service lives surfaces problems before they cause an outage.
- Auditing TLS posture before a compliance scan. The checker reports the negotiated TLS version and cipher suite. A server still accepting TLS 1.0 or 1.1, or one negotiating an RSA key-exchange suite, is a finding a scanner will catch in its next sweep. Better to find it yourself.
What to make of the output
Start with the validity window. A certificate expiring in less than 30 days on a production host that doesn’t auto-renew is a ticket to file today. A certificate that already expired and is still being served is the immediate cause of every TLS error the user is seeing — fix it before debugging anything else.
Read the SAN list against the list of hostnames the certificate is supposed to cover. A missing host is the single most common cause of “the site loads fine but the API subdomain throws a cert error.” Wildcards cover one level of subdomain, no more — *.example.com covers api.example.com but not eu.api.example.com.
Look at the chain. A complete chain ends in a root certificate that’s in the public trust store. A chain that stops one level short of the root is fine as long as the missing root is well-known; a chain that’s missing an intermediate is broken even if Chrome forgives it. Pair the finding with the PortJar guide on SSL certificate chain incomplete for the fix.
Look at the negotiated protocol and cipher. TLS 1.2 is the minimum acceptable today; TLS 1.3 is preferred. Anything older is a finding. Cipher suites should be modern AEAD (AES-GCM, ChaCha20-Poly1305) — anything with CBC or RC4 is a finding to escalate.
A self-signed certificate on a public host is almost always a misconfiguration — somebody pointed the wrong listener at the wrong cert. On an internal host it might be deliberate, but it’s worth confirming.
Stack Harbor handles certificate lifecycle, renewal automation, and TLS posture across many hosts as part of Monitoring and Support.