SSL vs TLS: what's the difference (and why we still say 'SSL certificate')

The short version of SSL vs TLS is this: TLS is the modern, secure successor to SSL, and every "SSL" connection on the web today is actually TLS under the hood. SSL (Secure Sockets Layer) was deprecated years ago — its last version, SSL 3.0, was broken in 2014 — and TLS (Transport Layer Security) replaced it. The reason we still say "SSL certificate" is pure habit: the name stuck even though the protocol it refers to is now TLS. This guide walks through where each protocol came from, what actually changed, and why the certificate on your server is identical whether you call it SSL or TLS.

The short answer, up front

If you only remember one thing: SSL and TLS are two generations of the same protocol, and you should be running TLS. SSL 2.0 and SSL 3.0 are obsolete and insecure, disabled in every current browser and server. TLS 1.2 and TLS 1.3 are what secure connections use today.

"SSL certificate," "TLS certificate," and "SSL/TLS certificate" all describe the exact same thing — an X.509 certificate that proves a server's identity. The certificate doesn't pick the protocol. The protocol (SSL or TLS, and which version) is negotiated separately during the handshake. So nothing about your certificate changes when you move from talking about "SSL" to "TLS." Only the marketing and the muscle memory differ.

What SSL was: a quick version history

SSL was designed at Netscape in the mid-1990s to encrypt traffic between browsers and servers. It went through three versions, none of which survive today.

SSL 1.0 (1994) — never released publicly. It had serious security flaws found internally, so it never shipped.
SSL 2.0 (1995) — the first public release. It had structural weaknesses: a weak MAC construction, no protection for the handshake itself (enabling downgrade and truncation attacks), and the same key used for authentication and encryption. It was prohibited outright by RFC 6176 in 2011.
SSL 3.0 (1996) — a near-complete redesign that fixed many of SSL 2.0's problems and became the basis for TLS. It served the web for years, but its use of CBC-mode ciphers with predictable padding left it vulnerable.

The thing that finally killed SSL 3.0 was POODLE (Padding Oracle On Downgraded Legacy Encryption), disclosed in October 2014. POODLE let an attacker who could sit between client and server force a downgrade to SSL 3.0 and then decrypt bytes of the session one at a time by exploiting how SSL 3.0 handled CBC padding. Because the flaw was in the protocol's design, not a single implementation, there was no patch — the only fix was to turn SSL 3.0 off everywhere. RFC 7568 formally deprecated it in 2015. By then, every protocol named "SSL" was dead.

TLS: the protocol you actually use

TLS is what the standards body (the IETF) produced when it took over SSL 3.0 and standardized it. The version numbering is the source of a lot of confusion: TLS 1.0 is essentially SSL 3.1. They renamed it from SSL to TLS partly so it wouldn't look like a Netscape product. Here's the lineage.

TLS 1.0 (1999, RFC 2246) — the standardized successor to SSL 3.0. Close enough to SSL 3.0 that the two are often grouped together, and it inherited some of the same weaknesses (BEAST, later padding attacks).
TLS 1.1 (2006, RFC 4346) — added protection against CBC attacks by using an explicit initialization vector, plus better handling of padding errors.
TLS 1.2 (2008, RFC 5246) — the workhorse of the modern web. It added support for authenticated encryption (AEAD) cipher suites like AES-GCM, SHA-256 in place of MD5/SHA-1 in the handshake, and per-connection cipher flexibility. Still widely deployed and perfectly secure when configured well.
TLS 1.3 (2018, RFC 8446) — the current state of the art. It is a major cleanup, not an incremental bump.

TLS 1.0 and TLS 1.1 were formally deprecated in March 2021 by RFC 8996. Browsers had already removed support for them in 2020. If a server still negotiates TLS 1.0 or 1.1, treat that as a misconfiguration to fix, not a fallback to keep around.

What makes TLS 1.3 different

TLS 1.3 is worth calling out because it changed the protocol's shape, not just its cipher list.

Faster handshake. TLS 1.2 needs two round trips before application data flows. TLS 1.3 does it in one (1-RTT), and supports 0-RTT resumption for returning clients. On a high-latency connection that's a visible speedup.
AEAD-only ciphers. TLS 1.3 removed every legacy cipher mode — no more CBC, RC4, 3DES, static RSA key exchange, or compression. Only modern authenticated-encryption suites (AES-GCM, ChaCha20-Poly1305, AES-CCM) remain. This eliminates whole classes of attacks (POODLE, BEAST, Lucky 13) by construction.
Forward secrecy by default. Every TLS 1.3 handshake uses ephemeral Diffie-Hellman, so each session gets a unique key. Capturing today's traffic and stealing the server's private key later won't decrypt it. In TLS 1.2, forward secrecy was optional and depended on choosing an ECDHE cipher suite.
Encrypted handshake. More of the handshake (including the server certificate) is encrypted, leaking less metadata to a passive observer.

SSL vs TLS: the practical differences

Most of the differences between SSL and TLS, and between TLS versions, come down to how the handshake works and which cryptography is allowed. Here's the compact comparison.

| Aspect | SSL 2.0 / 3.0 | TLS 1.0 / 1.1 | TLS 1.2 | TLS 1.3 | |---|---|---|---|---| | Status | Insecure, removed | Deprecated (RFC 8996) | Secure, widely used | Secure, preferred | | Handshake round trips | 2 | 2 | 2 | 1 (0-RTT resumption) | | Cipher modes | Weak, CBC/RC4 | CBC, RC4 | CBC and AEAD | AEAD only | | Forward secrecy | No | Optional | Optional (ECDHE) | Always | | MAC construction | Weak (SSL) / HMAC | HMAC | HMAC / AEAD | AEAD | | Downgrade resistance | None | Weak | Better (with TLS_FALLBACK_SCSV) | Strong, built in |

The throughline: each version removes weak options and reduces the ways a connection can be tricked into using something it shouldn't. Downgrade resistance matters in particular — POODLE was a downgrade attack, and modern TLS specifically defends against being talked down to an older, weaker protocol.

"SSL certificate" vs "TLS certificate": same file

This is the part that trips people up, so it's worth being precise. There is no such thing as an "SSL certificate" that differs from a "TLS certificate." They are the same X.509 certificate. The certificate contains a public key, a subject (the hostname, in the Subject Alternative Name extension), an issuer, validity dates, and a signature from a certificate authority. None of those fields say "SSL" or "TLS."

The protocol — SSL 3.0, TLS 1.2, TLS 1.3 — is chosen during the handshake, when the client and server agree on the highest version both support. The certificate is presented inside that handshake to authenticate the server, but it doesn't constrain which protocol gets used. You can serve the very same certificate file over TLS 1.2 today and TLS 1.3 tomorrow by changing only your server config, never the cert.

So when a CA sells you an "SSL certificate," or your terminal output shows openssl s_client connecting over TLSv1.3, those aren't in conflict. The cert is the cert; the protocol is negotiated. If you want to see exactly what's inside one of these certificates — the SANs, issuer, and chain — the certificate chain explained post breaks down how the leaf, intermediate, and root pieces fit together.

How to check which TLS version a server negotiates

You don't have to guess what your server supports. openssl s_client can probe a specific protocol version directly, and the exit status tells you whether it succeeded. A well-configured server should accept TLS 1.2 and 1.3 and reject everything older.

Test TLS 1.3:

openssl s_client -connect example.com:443 -servername example.com -tls1_3 </dev/null

On success you'll see the negotiated protocol and cipher near the bottom of the output:

SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384

Test TLS 1.2 the same way:

openssl s_client -connect example.com:443 -servername example.com -tls1_2 </dev/null

Now confirm the old protocols are refused. This probe should fail:

openssl s_client -connect example.com:443 -servername example.com -tls1_1 </dev/null

A correctly hardened server responds with a handshake failure and a non-zero exit code:

140735...:error:0A0000BF:SSL routines:tls_setup_handshake:no protocols available

If that TLS 1.1 probe succeeds, your server is still accepting a deprecated protocol and you should disable it. If the TLS 1.3 probe fails, either your server doesn't offer 1.3 or your openssl is too old to speak it (you need OpenSSL 1.1.1 or newer). For the full set of openssl recipes — dumping dates, SANs, issuers, and chains — see how to check an SSL certificate with openssl. For a quick check from outside your network, the hosted SSL check tool reports the negotiated protocol and certificate details without any local install.

What you should actually do

The practical guidance is short and hasn't changed in years:

Serve TLS 1.2 and TLS 1.3. TLS 1.3 first, TLS 1.2 as a fallback for older clients. This covers essentially every browser and API client in use.
Disable TLS 1.0, TLS 1.1, and all SSL. They are deprecated, removed from browsers, and flagged by every compliance scan (PCI DSS, for one, has required disabling them for years).
Use AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) and enable forward secrecy. On TLS 1.3 this is automatic; on TLS 1.2 you choose ECDHE suites.

The exact config lines differ per server. The Nginx guide and Apache guide show where to set ssl_protocols / SSLProtocol and how to reload after changing them, and the Cloudflare guide covers setting the minimum TLS version at the edge.

Once your protocols are dialed in, the thing most likely to actually take you down isn't the protocol version — it's the certificate quietly expiring. That's a separate, time-based failure mode, and it's the one worth automating. The complete guide to SSL certificate monitoring covers what to watch beyond expiry, including flagging a server that regresses to a deprecated protocol.

Monitor it automatically

SSLNudge checks your certificates every day — expiry, chain, hostname match, and the TLS configuration your server negotiates — and alerts you well before anything breaks, so a forgotten renewal or a protocol regression becomes a notice instead of an outage. You configure the protocols once; let the daily check confirm they stay that way. Sign in to start monitoring and put your domains on autopilot.