Check any domain's SSL/TLS certificate: expiry, chain completeness, SANs, protocol support and cipher strength, with a graded score and fix list.
Enter a hostname and this SSL checker opens a TLS connection to it, reads the certificate the server presents, walks the chain it sends, tests which protocol versions the server will negotiate, and reports the cipher actually agreed. You get a letter grade and a numeric score, plus a list of specific issues ranked from critical to informational — not just a green tick.
It is aimed at whoever is on the hook when a certificate expires: sysadmins, DevOps engineers, MSP technicians, and developers debugging why one client trusts a site and another does not. The checker inspects the public TLS endpoint only. It needs no agent, no credentials, and no access to the server.
example.com is fine; the port defaults to 443.The chain is complete. A server must send its leaf certificate plus every intermediate up to — but not including — a root the client already trusts. Browsers often paper over a missing intermediate using AIA fetching or a cached copy from another site, which is exactly why a site can work in your browser and fail in curl, on Android, in a Java client, or from a CI runner. If the chain view shows a leaf whose issuer does not appear as the subject of the next certificate, that gap is your bug.
Expiry is not close. Certificate lifetimes are shrinking industry-wide and renewal is increasingly automated, which makes a stale manual renewal more dangerous, not less: the failure arrives without warning at whatever hour the certificate happens to lapse. Treat anything under 30 days as an action item and confirm the automation actually ran, rather than assuming it did.
Protocol versions are current. TLS 1.2 and TLS 1.3 are the versions to support. SSL 2.0 and 3.0 are long broken. TLS 1.0 and 1.1 are deprecated, fail PCI DSS expectations, and are disabled by default in current browsers — leaving them enabled buys you nothing except downgrade surface. TLS 1.3 also removes whole categories of legacy negotiation, which is why it is the baseline for an A grade here.
The negotiated cipher is strong. Prefer AEAD suites with forward secrecy: ECDHE key exchange with AES-GCM or ChaCha20-Poly1305. Suites using RC4, 3DES, plain CBC with SHA-1, export-grade key sizes, or static RSA key exchange (no forward secrecy) should be gone. Forward secrecy matters because it means a future compromise of the server’s private key does not retroactively decrypt recorded traffic.
Key and signature strength are adequate. RSA keys of 2048 bits or more, or ECDSA at P-256 or above, signed with SHA-256 or better. SHA-1 signatures on a publicly trusted leaf certificate are a hard failure in modern clients.
The hostname matches. Match is made against the SAN list. Wildcards cover exactly one label — *.example.com matches www.example.com but not a.b.example.com and not the bare apex.
When a browser interrupts you with a certificate warning, the underlying causes fall into a few buckets, and they are worth telling apart:
| Symptom | Usual cause | Who fixes it |
|---|---|---|
| Expired certificate | Renewal automation failed or was never set up | Site owner |
| Name mismatch | Host not in the SAN list; wildcard depth wrong | Site owner |
| Unknown issuer, only on some clients | Missing intermediate in the served chain | Site owner |
| Unknown issuer, every client on one network | TLS interception by a corporate proxy, security appliance or malware injecting its own CA | Network owner — investigate |
| Not-yet-valid certificate | Client clock wrong | The visiting machine |
The interception case is the one to take seriously. If this checker, run from the public internet, reports a certificate issued by a well-known CA while your browser on a particular network sees an issuer you do not recognise, something between you and the server is terminating the connection and re-signing it. On a managed corporate device that is often sanctioned and documented. On a home or public network it is not.
Either way, the correct response to a certificate warning is to stop and find out why — never to click through. Clicking past the warning hands the plaintext of everything you subsequently send, including credentials and session cookies, to whatever presented that certificate. Fix the cause instead: renew, publish the intermediate, correct the SAN list, or get off the network you do not trust.
Missing intermediate: concatenate the CA-supplied intermediate(s) after your leaf in the certificate file your server points at, then reload the service. Verify from outside afterwards — the server will happily start with an incomplete chain.
Old protocols still enabled: set an explicit minimum of TLS 1.2 in your web server or load balancer configuration, and confirm with the protocol scan that 1.0 and 1.1 now fail to negotiate.
Weak ciphers: replace ad-hoc cipher strings with a current recommended list rather than editing one suite at a time. You can inspect what a given suite actually provides with the cipher suite lookup.
Certificate content questions: decode the PEM directly with the X.509 certificate decoder, rebuild a chain with the certificate chain builder, or check what has been issued for a domain via certificate transparency logs.
TLS is only part of the HTTPS picture. Once the handshake is clean, review HSTS and the rest of your response headers with the security headers analyzer.
It connects to the host on port 443, retrieves the presented certificate and the chain sent with it, tests which TLS protocol versions the server will negotiate, records the agreed cipher, and evaluates the result into a graded score with an itemised issue list.
Almost always a missing intermediate certificate. Browsers can often recover by fetching the missing certificate or reusing a cached one; command-line tools and mobile stacks generally cannot. Check the chain section — if there is a gap between a certificate’s issuer and the next subject, add the intermediate to your server configuration.
No. Both are deprecated, disabled by default in current browsers, and rejected under current PCI DSS expectations. Support TLS 1.2 and TLS 1.3 and disable everything below.
SSL is the retired predecessor of TLS. Every protocol version in use today is TLS; “SSL certificate” and “SSL checker” simply persist as names. The certificate itself is protocol-agnostic — the same certificate is used regardless of which TLS version is negotiated.
No. A warning means the browser cannot verify it is talking to the real server, and proceeding exposes everything you send — passwords, session cookies, form data — to whoever presented that certificate. Diagnose and fix the cause instead.
No. The check runs from the internet, so the hostname must resolve publicly and accept connections on the port. Internal-only names and IP-restricted endpoints will fail to connect.
After every certificate deployment or load balancer change, and on a schedule for anything customer-facing. Most outages caused by certificates are avoidable with a check that runs before the user finds the problem.
Exactly one label. *.example.com covers www.example.com and api.example.com, but not example.com itself and not a.b.example.com. The apex has to be listed separately in the SAN list.
It is free with no account. The domain you enter is sent to the scanning backend so the TLS connection can be made from the internet — that is inherent to the check — and only public information about a public endpoint is involved.
SSL (Secure Sockets Layer) and its successor TLS (Transport Layer Security) are cryptographic protocols that provide secure communication over computer networks. When you see HTTPS in your browser, the connection is protected by TLS.
| Version | Status | Notes |
|---|---|---|
| TLS 1.3 | Recommended | Latest standard, fastest, most secure |
| TLS 1.2 | Acceptable | Still secure when configured properly |
| TLS 1.1 | Deprecated | Known vulnerabilities, disable if possible |
| TLS 1.0 | Deprecated | Serious vulnerabilities (BEAST, POODLE) |
SSL/TLS certificates form a chain of trust from your server's certificate up to a trusted root Certificate Authority (CA).
This tool performs a real TLS handshake with the target server to analyze: the SSL/TLS certificate details (subject, issuer, validity, SANs), the certificate chain, supported protocols (TLS 1.0, 1.1, 1.2, 1.3), negotiated cipher suites, and potential security issues.
Grades range from A+ (excellent) to F (failing). A+ indicates TLS 1.3 support with strong ciphers and no issues. Lower grades indicate problems like deprecated protocols (TLS 1.0/1.1), weak ciphers, expired certificates, or trust issues.
TLS 1.0 and 1.1 have known security vulnerabilities and have been deprecated by major browsers and security standards. Websites should support TLS 1.2 at minimum, with TLS 1.3 recommended for best security.
A certificate chain is the sequence of certificates from your server's certificate up to a trusted root CA. Browsers verify this chain to establish trust. A broken or incomplete chain can cause security warnings.
Certificates can be untrusted for several reasons: self-signed certificates, expired certificates, hostname mismatch, incomplete certificate chain, or certificates issued by untrusted CAs.
Quick scan performs a single TLS connection to get certificate and cipher info. Full scan additionally tests each TLS protocol version (1.0, 1.1, 1.2, 1.3) separately to determine which protocols your server supports.
Yes, this SSL checker is completely free to use. There are no limits on the number of domains you can check.
The score starts at 100 and deducts points for issues: -40 for untrusted certificates, -50 for expired certificates, -15 for TLS 1.0 support, -10 for TLS 1.1 support, and +5 bonus for TLS 1.3 support. The final grade is based on the remaining score.