SSL/TLS Configuration Checker
See exactly which TLS versions a server accepts and whether its certificate is actually trusted — from a real live connection, not a guess.
Also known as: SSL checker, TLS checker, SSL certificate checker, TLS protocol version checker
How it works
- 1Enter a domain to check (port 443 is checked automatically).
- 2Review which TLS protocol versions were accepted, rejected, or couldn't be tested.
- 3Check the certificate panel for issuer, expiry, and trust status.
- 4Read any warnings for legacy protocol support or certificate issues.
Why use SSL/TLS Configuration Checker
A real live TLS handshake, not a cached lookup
Actually connects to the target on port 443 and reports what genuinely happened during negotiation.
Honest about local testing limits
Distinguishes "the server rejected this protocol" from "we couldn't test this from our own TLS library" — verified against a real server known to have this exact limitation.
Full certificate trust chain checking
Reports whether the certificate is genuinely trusted by a standard CA bundle, not just whether one is present.
Verified against known-bad test certificates
Trust and expiry detection checked against badssl.com's dedicated expired and self-signed test domains.
Scoped to port 443 only
No arbitrary port scanning — this checks the standard HTTPS port and nothing else.
SSRF-guarded hostname resolution
Uses the same private/internal address blocking as every other server-side tool on this site.
Who uses SSL/TLS Configuration Checker
Checking whether legacy TLS versions are still accepted
Confirm a server has actually disabled TLSv1.0/1.1, which PCI DSS has required since 2018.
Verifying a certificate renewal actually took effect
Confirm the live certificate's expiry date reflects a recent renewal, not the old one.
Checking certificate trust after a CDN or load balancer change
Confirm the certificate served at the edge is still the one you expect, and still trusted.
Confirming a SAN certificate covers all the domains it should
Check every domain listed in a certificate's Subject Alternative Names in one view.
Spot-checking a vendor or partner's TLS configuration
Get a quick read on whether a third-party API endpoint's TLS setup is current.
Diagnosing a client that can't connect over TLS
Check whether the server actually supports the TLS version an older client would be using.
About SSL/TLS Configuration Checker
Checking a site's TLS setup properly means actually connecting to it and negotiating a handshake — there's no way to reliably determine which protocol versions a server accepts, what cipher it prefers, or whether its certificate chain is genuinely trusted without doing exactly that. This tool does the real thing: it opens a live TLS connection from our server (a browser tab has no API for raw TLS negotiation) and reports what actually happened.
To check which protocol versions a server accepts, this tool attempts a separate connection forced to each version — TLSv1.0, TLSv1.1, TLSv1.2, and TLSv1.3 — and reports which succeed. There's a real subtlety here worth being upfront about: modern server environments (including the one this tool runs on) often have TLSv1.0 and TLSv1.1 disabled at the OpenSSL level entirely, meaning an attempt to negotiate them can fail locally before a single packet reaches the target server. When that happens, this tool reports the result as "inconclusive" rather than falsely claiming the server doesn't support it — a genuine, disclosed limitation rather than a misleading pass or fail.
Certificate checking covers what actually matters day to day: whether the certificate is expired (or close to it — anything under 14 days gets an explicit warning), whether it's issued by a certificate authority that's actually trusted by a standard CA bundle, and every domain listed in its Subject Alternative Names. This logic was verified against badssl.com's dedicated test domains for expired and self-signed certificates, so the trust and expiry detection is checked against known-bad certificates, not just known-good ones.
This is scoped deliberately to port 443 — there's no option to probe an arbitrary port, which keeps this tool from being usable as a general-purpose port scanner. Hostname resolution goes through the same private-address blocking every other server-side tool on this site uses, so it can't be pointed at internal infrastructure either.
SSL/TLS Configuration Checker vs. other options
How Open Tools Library compares to desktop software and other online tools.
| Feature | Open Tools Library | Desktop software | Other online tools |
|---|---|---|---|
| Price | Free, unlimited | N/A | Often free |
| Real live handshake | Yes — actually connects and negotiates | N/A | Varies — some show cached results |
| Distinguishes local vs. remote limits | Reports "inconclusive" instead of a false negative | N/A | Rarely disclosed |
| Certificate trust verification | Checked against a standard CA bundle, verified with known-bad test certs | N/A | Varies |
| Port scanning risk | Locked to port 443 only | N/A | Varies |
| Data privacy | Only connection metadata read, nothing about site content | N/A | Varies |
Pro tips
- TLSv1.0 and TLSv1.1 showing "couldn't test" instead of a definitive result usually reflects our own server's OpenSSL configuration, not the target's — take it as inconclusive, not as a pass.
- A certificate under 14 days from expiry gets an explicit warning here — that's intentionally more proactive than waiting for a browser warning after it's already expired.
- "Not trusted" doesn't always mean something's wrong — internal/private CAs, self-signed certs for local development, and some regional CAs outside the standard bundle will all show this, and that can be expected depending on context.
- This checks port 443 only, by design — if a service runs TLS on a non-standard port, this tool won't be able to check it.
Technical specs
- Port checked
- 443 only — not configurable, to avoid port-scanning misuse
- Protocol versions probed
- TLSv1.0, TLSv1.1, TLSv1.2, TLSv1.3
- Cipher info
- Negotiated cipher name and TLS version from the primary handshake
- Certificate details
- Subject, issuer, validity dates, trust status, Subject Alternative Names
- Local-restriction handling
- Distinguishes server rejection from our own TLS library's restrictions
- Processing location
- Server-side raw TLS connection (disclosed) — required for a real handshake
Privacy & security
Checking a server's TLS setup only requires the connection itself — nothing about the site's content or visitors.
Only a TLS handshake is performed — no page content is ever requested or read.
Nothing about the check is logged or retained after the result is returned.
No account, no email, no login — just a domain in, a configuration report out.
Equally private whether you're checking your own domain or a public third-party one.
Frequently asked questions
Why can't this run entirely in my browser?
Browsers have no API for raw TLS handshake negotiation — checking which protocol versions a server accepts requires opening real TCP/TLS connections directly, which only a server-side environment can do.
Is any of the site's actual content read?
No — this only performs a TLS handshake and reads connection metadata (protocol, cipher, certificate). No HTTP request for page content is ever made.
Why does the tool distinguish "not supported" from "inconclusive"?
Forcing a connection to an old TLS version can fail locally, in our own server's TLS library, before ever reaching the target — that's a fact about our environment, not the target's, so it's reported separately rather than as a false negative.
What does "Subject Alternative Names" mean?
The full list of domains a single certificate is valid for — modern certificates almost always cover multiple domains (like example.com and www.example.com) via this field.
Can I check a specific port other than 443?
No — this tool is intentionally locked to port 443 (standard HTTPS) to avoid being usable as a general port scanner.
Is my query to check a domain sent anywhere else?
No — the TLS connection is made directly from our server to the domain you enter; nothing is logged or shared afterward.
Troubleshooting
TLSv1.0 and TLSv1.1 both show "couldn't test" — is that a bug?
No — modern server environments (including ours) often disable those protocols in OpenSSL entirely, so an attempt to negotiate them fails locally before reaching the target. This is reported honestly as inconclusive rather than a false "not supported."
The certificate shows "not trusted" but browsers accept it fine
This checks against a standard CA bundle — if the certificate is issued by an internal/private CA, a corporate root, or a CA your specific browser trusts but isn't in the standard bundle, this can show "not trusted" even when your browser is fine with it.
The connection failed entirely
The domain may not be listening on port 443, may not support TLS at all, or may point to a private/internal address that's blocked for safety — the error message will indicate which.
Why does it only check port 443?
Allowing an arbitrary port would make this tool usable as a general port scanner against any host — restricting to the standard HTTPS port keeps it scoped to its actual purpose.
Related searches
Landed here looking for something worded a little differently? SSL/TLS Configuration Checker covers all of these too:
Ready to use SSL/TLS Configuration Checker?
Free, private, and ready right now — no signup required.
Scroll to SSL/TLS Configuration Checker