SSL Definition and History
SSL stands for Secure Sockets Layer. It is a cryptographic protocol developed to provide secure communication over computer networks. SSL encrypts all communication between web servers and client browsers, ensuring that intercepted traffic remains completely unreadable.
SSL is the predecessor to TLS (Transport Layer Security). While modern systems exclusively utilize TLS 1.2 and TLS 1.3, the term "SSL" remains universally used as an umbrella term for website certificates and HTTPS encryption.
Browser and Server Communication
When you visit a website protected by HTTPS, your browser initiates a connection asking for the server's SSL certificate. The server returns the certificate, and the browser verifies its authenticity against a local list of trusted root Certificate Authorities (CAs). If valid and unexpired, a secure, symmetric session key is generated to protect subsequent data exchanges.
Establish a Secure HTTPS Connection (The Handshake)
-
1
Client Hello: The browser sends supported TLS versions, cipher suites, and the Server Name Indication (SNI) for the target domain.
-
2
Server Hello & Certificate: The server selects the strongest mutually supported cipher and sends its leaf certificate along with intermediate CA certificates.
-
3
Verification: The client verifies the certificate validity window, revocation status, Subject Alternative Names (SANs), and chain of trust.
-
4
Key Exchange & Encryption: Using Diffie-Hellman (ECDHE), both parties compute a shared symmetric session key without transmitting it over the wire.
-
5
Encrypted Tunnel: All HTTP requests and responses flow through the encrypted tunnel with full integrity and privacy in milliseconds.
What This Tool Checks, and Why Each Check Matters
An SSL test resolves two distinct pillars that are frequently conflated:
- Identity and Trust: Does the server present an authentic certificate signed by an authorized CA that a fresh client (without cached intermediates) will trust?
- Cryptographic Configuration: Even with a perfect certificate, are the protocols, key lengths, and cipher algorithms safe from modern downgrade and oracle attacks?
Every Check at a Glance
| Check | What it Detects | Why it Matters |
|---|---|---|
| Installation & Trust | Certificate present, valid, signed by trusted CA | A failure immediately blocks every browser visitor |
| Chain / Intermediates | Complete leaf-to-root validation path | Missing intermediate = silent failure on fresh clients & mobile devices |
| Expiry & Days Left | Not-after expiration date countdown | Expired certs produce hard browser security warnings |
| SAN Coverage | Hostnames the certificate protects | Name mismatch triggers "Your connection is not private" error |
| Protocol Versions | TLS 1.3 / 1.2 / 1.1 / 1.0 support | Obsolete protocols enable protocol downgrade and cipher cracking |
| Cipher Suites | Negotiated ciphers and weak algorithms | Insecure ciphers compromise data confidentiality |
| Vulnerabilities | Heartbleed, POODLE, BEAST, ROBOT, Ticketbleed | Allows remote attackers to decrypt keys or steal memory |
| Response Headers | HSTS, CSP, and security flags | Determines whether browsers strictly enforce HTTPS |
Frequently Asked Questions
What does the SSL checker actually test?
It opens a real TLS handshake to the host you enter and reports key security indicators: whether the certificate is valid and trusted; whether the intermediate chain is complete; expiration and days remaining; Subject Alternative Names (SANs); supported protocol versions; cipher suites; and known TLS vulnerabilities.
Why does my certificate show as not trusted when it works in my own browser?
Almost always a missing intermediate certificate. Your browser may have cached the intermediate CA from a previously visited site, masking the problem. A clean client, mobile application, or API consumer lacks that cache and will reject the connection. The fix is to configure the full bundle (leaf + intermediates) on your server.
Does a valid certificate mean my server is secure?
No. A certificate proves identity and enables encryption, but the server may still negotiate obsolete protocols (TLS 1.0 or 1.1), offer weak ciphers, or be exposed to vulnerabilities like POODLE or ROBOT. Certificate validity and configuration hardening are separate requirements.
How often should I check my SSL certificate?
Check after every certificate renewal or web server reconfiguration. With industry standards moving toward short-lived certificates (90 days or less), automated monitoring and timely renewal testing are essential.