SSL Certificate Checker
Web server configuration analysis and testing service for diagnosing, validating and resolving TLS/SSL certificate installation errors.
Free online tool for test SSL security
SSL definition and history
SSL is an abbreviation and stands for Secure Sockets Layer. It is a cryptographic protocol that provides secure communication between a web server and a web browser. SSL encrypts all communication between the server and the browser, so that if anyone intercepts the communication it is unreadable.
SSL is the predecessor to TLS (another abbreviation which stands for Transport Layer Security). TLS is a more modern and secure protocol than SSL, and it is the protocol that is currently used by most websites.
Browser and server communication
When you visit a website that is using SSL, your browser will send a message to the server asking for the website's SSL certificate. The server will then send the certificate back to the browser. The browser will then verify the certificate to make sure that it is valid. If the certificate is valid, the browser will establish a secure connection with the server.
A secure HTTPS connection to a domain (website) with a valid SSL certificate from a trusted certificate authority ensures that all communication between your web browser and the website is encrypted and secure. This means that your personal information, such as your credit card number and password, cannot be intercepted and read by third parties.
Establish a secure HTTPS connection
This process is also called 'handshake' and it involves the following steps:
- The client (web browser) sends a request to the server (website) for a secure connection. This request includes the client's supported cipher suites and the domain name of the website.
- The server sends its SSL certificate to the client. The SSL certificate contains information about the website, such as the domain name, the organization name, and the expiration date. It also includes the server's public key.
- The client verifies the SSL certificate. The client checks the validity of the certificate by making sure that it is issued by a trusted certificate authority and that it has not expired. The client also checks the domain name in the certificate to make sure that it matches the domain name of the website.
- The client generates a random session key and encrypts it with the server's public key. The client then sends the encrypted session key to the server. The server decrypts the session key with its private key. The server then uses the session key to encrypt all communication between the server and the client.
- This handshake between the server and your browser all takes place behind the scenes in hundredths of a second.
Once the handshake is complete, the client and the server can communicate securely.
What this tool checks, and why each check matters
An SSL check answers two different questions that are easy to conflate. The first is about identity and trust: does this server present a certificate that a clean client will accept? The second is about configuration: even with a perfect certificate, is the encryption the server actually negotiates still safe to use? The checker reports both, because a site can pass the first and fail the second.
The starting point is the chain of trust. A server should send its leaf certificate plus every intermediate up to a root that clients already trust. The single most common real-world failure is a missing intermediate: it works in your own browser because the intermediate is cached from some other site you visited, but a fresh client — a mobile app, a payment gateway, a monitoring probe — has no such cache and rejects the connection. The tool validates the chain the way a first-time visitor would, which is why it sometimes reports "not trusted" for a site that looks fine to you.
Next is validity over time. The certificate carries a fixed expiry, and an expired certificate
produces a hard browser error for every visitor at once. With certificate lifetimes shrinking toward 90 days and
below, the practical risk has shifted from "we forgot for a year" to "the renewal automation broke and nobody
noticed" — so the days-remaining figure and an expiry reminder matter more than they used to. The Subject
Alternative Names determine which hostnames the certificate is actually valid for; a certificate issued for
example.com that is served on www.example.com will fail name validation even though it is
otherwise perfect.
The configuration half is about protocols and cipher suites. A server can hold a flawless certificate and still negotiate TLS 1.0 or 1.1, both deprecated, or offer ciphers with known weaknesses. This is where the named vulnerabilities live: POODLE exploits SSL 3.0, BEAST targets older CBC ciphers in TLS 1.0, Heartbleed and Ticketbleed are memory-disclosure bugs, and ROBOT revives a padding-oracle attack against RSA key exchange. The tool enumerates what the server will negotiate and flags anything in this category, so "the certificate is valid" never gets mistaken for "the endpoint is safe."
Finally, the response headers give context the certificate cannot: whether HSTS is set, what the server advertises, and other signals that shape how strictly browsers treat the connection. Together these checks describe the endpoint as an outside client experiences it, not as it appears from inside your own network.
Every check at a glance
Each row is something the tool reports on a single run, what it detects, and why it matters operationally.
| Check | What it detects | Why it matters |
|---|---|---|
| Installation & trust | Certificate present, valid, signed by a trusted CA | A failure here breaks HTTPS for every visitor |
| Chain / intermediates | Complete leaf-to-root path | Missing intermediate = silent failure on fresh clients |
| Expiry | Not-after date and days remaining | Expired certs produce hard browser errors |
| SAN coverage | Hostnames the certificate is valid for | Name mismatch fails validation even if the cert is otherwise good |
| Protocol versions | TLS 1.0 / 1.1 / 1.2 / 1.3 support | Deprecated versions weaken the connection |
| Cipher suites | Negotiated ciphers, weak/unsafe ones | Weak ciphers undermine encryption |
| Known vulnerabilities | BEAST, POODLE, Heartbleed, Ticketbleed, ROBOT | Exploitable regardless of certificate validity |
| Response headers | HSTS and server-advertised settings | Determines how strictly browsers enforce HTTPS |
Why SSL/TLS validation matters
Misconfiguration is the common failure
Most sites have a certificate; the recurring problems are incomplete chains, expired renewals and obsolete protocols — exactly the issues a configuration check surfaces and a green padlock hides.
HTTPS is a browser & search baseline
Major browsers mark plain-HTTP pages as "Not secure," and Google has treated HTTPS as a lightweight ranking signal since 2014, so a broken certificate carries visibility costs beyond the security ones.
It's a compliance requirement
PCI DSS requires strong cryptography for cardholder data in transit, and frameworks such as GDPR and HIPAA point to encryption as a safeguard — making a correctly configured certificate part of an audit trail.
Frequently asked questions
openssl s_client -connect host:443 -servername host.