← Blog

SSL vs TLS — what's actually different, and which one are you using?

March 11, 2026

By Nick Phillips, Founder

If you've spent any time in this corner of computing, you've noticed two things. First, everyone calls the certificates "SSL certificates" — including the people selling them and the browsers warning about them. Second, every config file and library calls the protocol "TLS." Both are normal. Both are technically wrong in opposite directions.

This post explains why, what's actually different between the two, and which versions you should care about. If you only have 60 seconds: SSL is deprecated and nobody should be running it; TLS 1.2 and 1.3 are what's actually live; the certs are the same either way, the name is just sticky.

The history, in one paragraph

SSL (Secure Sockets Layer) was invented at Netscape in 1995. SSL 2.0 was broken; SSL 3.0 was better. In 1999 the IETF standardized a not-quite-compatible successor and called it TLS (Transport Layer Security) 1.0 — partly for technical reasons, partly because by then Microsoft and Netscape were in a fight and "SSL" was Netscape's brand. TLS 1.1 (2006), TLS 1.2 (2008), and TLS 1.3 (2018) followed. SSL 3.0 was formally deprecated in 2015 after the POODLE attack. The name "SSL" persisted in marketing because by then there were a billion documents saying "SSL certificate" and nobody wanted to rewrite them all.

So "SSL" is technically a dead protocol family. "TLS" is what the wire is actually speaking. And "SSL certificate" is a name we use for the X.509 certificate that authenticates both — the cert itself doesn't care which protocol you're using.

What the certificate has to do with any of this

This is the part that trips people up: the certificate is not the protocol. The certificate is a small file that binds a public key to a domain name and is signed by a certificate authority. It works exactly the same whether you're using SSL 3.0 or TLS 1.3.

When you "buy an SSL certificate," you're buying that file. The protocol your server uses to present that file to a client is configured separately — usually in your nginx, Apache, or load balancer config. The same cert works for both SSL and TLS connections; whether SSL connections are even accepted is a server config issue.

Calling it an "SSL certificate" is fine. Calling it a "TLS certificate" is more accurate but pedantic. We use "SSL certificate" throughout this site because that's what people search for.

What's actually different on the wire

If you want the protocol-level differences, here's the short version:

Cryptographic agility. SSL 3.0 hardcoded a lot of cipher choices. TLS lets the client and server negotiate. Over time TLS has dropped weak ciphers (RC4, 3DES, anything CBC-mode without proper MAC, etc.) and added strong ones (AES-GCM, ChaCha20-Poly1305).

Handshake. TLS 1.2's handshake is two round-trips. TLS 1.3 cut it to one round-trip — and added 0-RTT resumption for repeat connections, which is part of why TLS 1.3 sites feel faster on mobile networks. SSL 3.0's handshake is two round-trips with weaker key exchange.

Forward secrecy. SSL 3.0 supported it but rarely did it. TLS 1.2 made it standard. TLS 1.3 made it mandatory — every TLS 1.3 connection uses ephemeral keys, so even if the server's long-term key leaks tomorrow, traffic recorded today can't be decrypted.

Attack surface. SSL 3.0 has POODLE. TLS 1.0 has BEAST. TLS 1.1 has nothing famous but is old and dropped in most clients anyway. TLS 1.2 has been audited heavily and is fine when configured correctly. TLS 1.3 was designed from scratch with everything we'd learned about the previous twenty years, and removed entire categories of footgun.

You don't need to remember which attack hit which version. You need to remember the running advice: TLS 1.2 minimum, TLS 1.3 if possible, everything older off.

Which versions should you actually run?

Here's the support matrix as of 2026:

For nginx, the modern config is:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

That's it. Don't allow anything below 1.2; let the client and server negotiate 1.3 if both support it.

For Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Cloudflare and other CDNs expose this as a "Minimum TLS Version" toggle in the dashboard; set it to 1.2.

How to check what your site is actually using

The cheapest check is openssl:

echo | openssl s_client -tls1_2 -servername example.com -connect example.com:443
echo | openssl s_client -tls1_3 -servername example.com -connect example.com:443

If both connect, your site supports both. If a connection fails with "no protocols available," that version is off — which, for TLS 1.0 and 1.1, is what you want.

To see the negotiated version when a real browser connects, the easiest path is SSL Labs' Server Test. It runs a thorough scan, including protocol versions, cipher suites, and configuration scoring. The output is verbose; the line you care about is the "Protocols" section.

You can also see negotiated version in your browser: open DevTools → Security tab → look for "Connection - secure connection settings." Chrome and Firefox both surface this.

So which one do you say in conversation?

In real life: call it SSL when talking to non-technical people, call it TLS when configuring software. Everyone knows what "SSL certificate" means; almost no software actually uses the string "SSL" anymore (SSLProtocol -all +TLSv1.2 is the rare exception, where the directive name is historical even though the protocol is TLS). It's silly but it's the convention.

The only conversation where the distinction is load-bearing is if someone earnestly tells you their server "supports SSL 3.0 for compatibility." That should be a stop-the-meeting moment. POODLE has been in the public literature for over a decade; no client that matters has spoken SSL 3.0 since 2015.

What this means for the certificate side of things

The expiration date, issuer, key type, and chain are all properties of the X.509 certificate, not the protocol. They're the same regardless of whether you're serving over TLS 1.2 or 1.3. So:

• A cert that's about to expire is going to expire regardless of which protocol you negotiate.
• A cert with a broken chain is going to confuse old clients regardless.
• A cert that uses RSA-2048 vs. ECDSA P-256 is a key-type decision, not a protocol decision.

The protocol determines how the cert is presented and what crypto is used to protect the session. The cert itself is just an identity claim. Our explainer on why certificates expire covers the cert-side concerns; this post is purely about the wire.

If you want to know the actual expiration date of your own cert right now without spinning up a terminal, paste the domain into our free checker — it'll show you the date and the issuer in a couple of seconds. For ongoing monitoring (because the cert will expire and the protocol won't help you), signup is here.

The short version, one more time: SSL is dead, TLS is what's running, the certificates are called "SSL certificates" because that's how language works, and the version you care about is 1.2 or 1.3.