SSL and TLS are the same family of protocol at two stages of its life: SSL (Secure Sockets Layer) is the deprecated original, and TLS (Transport Layer Security) is its renamed, hardened successor. Netscape shipped SSL 2.0 in 1995 and SSL 3.0 in 1996. When the IETF took over standardization in 1999, they renamed the protocol to TLS to avoid the Netscape trademark — TLS 1.0 (RFC 2246) was literally "SSL 3.1" under a neutral name. Every SSL version is now broken and disabled everywhere; the only protocols any modern server should speak are TLS 1.2 and TLS 1.3. When a vendor sells you an "SSL certificate," you are buying an X.509 certificate that your server presents during a TLS handshake — the certificate itself is protocol-agnostic; the word "SSL" is marketing inertia, not a technical fact.
That's the summary an AI Overview will hand you. What it won't show you is the full version timeline with the exact RFC that killed each one, a byte-level look at how to tell which protocol a server actually negotiated, and a copy-paste decision matrix for what to enable. Here's what you can't flatten into a sentence.
The complete SSL/TLS version timeline
Every version, when it shipped, when it died, and why. This is the table people actually come to this page for.
| Version | Released | Standard | Status (2026) | What killed it |
|---|---|---|---|---|
| SSL 1.0 | never | Netscape (internal) | Never shipped | Serious flaws found in review; never released publicly |
| SSL 2.0 | 1995 | Netscape | Prohibited (RFC 6176, 2011) | Weak MAC, no handshake protection, same key for auth & encryption |
| SSL 3.0 | 1996 | Netscape / RFC 6101 | Deprecated (RFC 7568, 2015) | POODLE attack (2014) breaks CBC padding |
| TLS 1.0 | 1999 | RFC 2246 | Deprecated (RFC 8996, 2021) | BEAST, weak SHA-1/MD5, no modern AEAD |
| TLS 1.1 | 2006 | RFC 4346 | Deprecated (RFC 8996, 2021) | Superseded; no AEAD cipher support |
| TLS 1.2 | 2008 | RFC 5246 | Recommended | Secure with modern cipher suites (ECDHE + AES-GCM) |
| TLS 1.3 | 2018 | RFC 8446 | Preferred | Current best practice — faster and safer |
The single most useful fact in that table: SSL and TLS are one continuous lineage, not two competing technologies. TLS 1.0's own spec says its differences from SSL 3.0 are "not dramatic." The rename was legal and organizational, not a clean-room rewrite.
SSL vs TLS: what actually changed
The name is the smallest difference. Each generation removed broken cryptography and added protection the previous one lacked.
| Dimension | SSL 3.0 (dead) | TLS 1.2 (secure) | TLS 1.3 (preferred) |
|---|---|---|---|
| Handshake round trips | 2-RTT | 2-RTT | 1-RTT (0-RTT on resume) |
| Key exchange | RSA, static DH | RSA, DHE, ECDHE | ECDHE / DHE only |
| Forward secrecy | Optional, rare | Optional | Mandatory |
| Bulk ciphers | RC4, 3DES, CBC | AES-GCM, AES-CBC, ChaCha20 | AEAD only (AES-GCM, ChaCha20-Poly1305) |
| Hashing in PRF | MD5 + SHA-1 | SHA-256 / SHA-384 | SHA-256 / SHA-384 |
| Handshake privacy | Cleartext | Cleartext | Encrypted after ServerHello |
| Renegotiation | Insecure | Fixed (RFC 5746) | Removed entirely |
| Cipher suites listed | dozens, many weak | dozens | 5 total, all safe |
| Known fatal attacks | POODLE | none if configured well | none known |
The headline in that table is the forward secrecy row. With SSL 3.0's static RSA key exchange, an attacker who records your traffic today and steals your server's private key in five years can decrypt everything retroactively. TLS 1.3 forbids that mode — every session gets an ephemeral key that's discarded when the connection closes, so a future key compromise reveals nothing about past sessions.
Why "SSL certificate" is a misnomer (but you'll keep saying it)
Here's the mental model that resolves the confusion. The certificate and the protocol are separate things that meet during the handshake:
So when you renew your "SSL certificate," nothing about it forces SSL. Whether a connection uses SSL 3.0 or TLS 1.3 is decided entirely by your server config (the ssl_protocols directive in nginx, SSLProtocol in Apache) and the client's supported versions. The certificate is an innocent bystander.
The handshake: what SSL/TLS actually does on the wire
Both SSL and TLS follow the same shape — negotiate, authenticate, derive keys, then encrypt. TLS 1.3 collapses the round trips, which is why it feels faster:
That one saved round trip matters at scale: on a mobile connection with 100 ms latency, TLS 1.3 shaves roughly 100 ms off every new connection. TLS 1.3 also encrypts the certificate and the rest of the handshake after ServerHello, so a passive network observer can no longer see which certificate the server presented.
Decision matrix: what should I actually enable?
Skip the theory — here's the copy-paste answer for common situations.
| Your situation | Enable | Disable | Notes |
|---|---|---|---|
| New public website (2026) | TLS 1.2 + TLS 1.3 | SSL 2/3, TLS 1.0/1.1 | The default correct answer for 99% of sites |
| PCI DSS in scope | TLS 1.2 + TLS 1.3 | Everything below 1.2 | PCI DSS mandates TLS 1.2 minimum |
| Internal API, you control both ends | TLS 1.3 only | Everything else | No legacy clients = go 1.3-only |
| Must support ancient embedded clients | TLS 1.2 + 1.3, plan migration | SSL 2/3, TLS 1.0/1.1 | Never re-enable TLS 1.0 — upgrade the client instead |
| Bank/gov high-assurance | TLS 1.3 (1.2 fallback) | 1.0/1.1 and CBC suites | Restrict to AEAD cipher suites only |
| Behind a CDN/load balancer | Set policy at the edge | — | Terminate TLS at the edge; enforce 1.2+ there |
The one rule that never bends: do not enable TLS 1.0 or 1.1 for "compatibility." RFC 8996 formally deprecated both in March 2021. Any device that genuinely cannot do TLS 1.2 has a cryptographic stack old enough that it has other, worse vulnerabilities — the fix is upgrading that device, not weakening your server for it.
How to check what your server actually negotiates
Don't trust config files — verify from the client side. Use our SSL Checker for a one-click report, or run these locally:
# Test whether a specific version is accepted (handshake succeeds = enabled)
openssl s_client -connect example.com:443 -tls1_3 </dev/null
openssl s_client -connect example.com:443 -tls1_2 </dev/null
# These SHOULD fail on a well-configured server:
openssl s_client -connect example.com:443 -tls1_1 </dev/null # expect: handshake failure
openssl s_client -connect example.com:443 -tls1 </dev/null # expect: handshake failure
# See the negotiated version and cipher at a glance
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | grep -E "Protocol|Cipher"
For a graded external audit, SSL Labs remains the reference — aim for an A+ with only TLS 1.2 and 1.3 enabled and forward-secret cipher suites. To inspect the certificate itself rather than the protocol, our X.509 Decoder breaks down the fields, extensions, and chain.
The bottom line
SSL is dead; you're using TLS whether you call it that or not. Treat "SSL" as a legacy label for the same protocol family, disable everything below TLS 1.2, and prefer TLS 1.3 for its faster, forward-secret, encrypted handshake. If you take one action from this page, verify your server rejects TLS 1.0 and 1.1 — that's still the most common misconfiguration in the wild. From there, dig into the TLS 1.3 vs TLS 1.2 security differences and how certificate lifecycle management keeps those connections trusted over time.