TLS 1.2 vs TLS 1.3 comes down to speed and simplicity. TLS 1.3 completes the handshake in one round trip instead of two, allows only modern ciphers, always uses forward secrecy and encrypts more of the handshake. TLS 1.2 is still safe when configured well, so most servers run both. Your existing SSL certificate works with either version.
This guide covers protocol versions only. For the naming history of the two protocols, see SSL vs TLS.
| Key fact | Detail |
|---|---|
| TLS 1.2 | Published as RFC 5246 (2008) |
| TLS 1.3 | Published as RFC 8446 (August 2018) |
| TLS 1.0 and 1.1 | Formally deprecated by RFC 8996 (March 2021): “MUST NOT be used” |
| New certificate needed? | No – the same certificate works with TLS 1.2 and TLS 1.3 |
Changing protocol settings? Check your certificate after every change.
Confirm your certificate, chain and hostname still validate once the server restarts.
Open the SSL checkerTLS 1.2 vs TLS 1.3: what is the difference?
TLS 1.3 has a shorter handshake and a much smaller set of ciphers. A handshake is the opening exchange where browser and server agree on keys. A cipher suite is the combination of algorithms they use. TLS 1.3 removed every option that had a known weakness in TLS 1.2.
| Feature | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Full handshake | Two round trips | One round trip |
| Resumed connections | Session IDs or tickets | Pre-shared keys, optional 0-RTT (zero round trip) |
| Cipher suites | Many, including legacy CBC and RSA key exchange | Five, all AEAD (authenticated encryption) |
| Forward secrecy | Optional – depends on cipher | Always on (ephemeral Diffie-Hellman) |
| Certificate during handshake | Sent unencrypted | Sent encrypted |
| Removed features | – | RSA key exchange, static DH, RC4, 3DES, compression, renegotiation |
Forward secrecy means a stolen server key cannot decrypt traffic recorded in the past. In TLS 1.2 you get it only if you pick ECDHE or DHE ciphers. In TLS 1.3 it is built in.
The saved round trip matters most on mobile networks and for visitors far from your server, where each round trip adds noticeable delay. TLS 1.3 is also the version in which browsers negotiate hybrid quantum-resistant key exchange – see post-quantum SSL for the timeline.
How the TLS 1.3 handshake works
ClientHello with key share
The browser lists its supported ciphers and already sends its half of the key exchange, guessing the server's preferred group.
ServerHello and keys
The server picks a cipher, sends its key share, and both sides derive the session keys immediately.
Encrypted certificate
The server sends its certificate and signature, already encrypted. The browser validates the certificate chain.
Application data
After one round trip, the browser sends the HTTP request. TLS 1.2 needs a second round trip first.
Do I need a new certificate for TLS 1.3?
No. TLS 1.3 works with the RSA or ECDSA certificate you already have. The protocol version is a server setting, not a certificate property. You do not need to reissue, rekey or buy anything to enable it.
Behind the scenes, TLS 1.3 signs the handshake with RSA-PSS when you use an RSA key. Your TLS library handles this automatically. If your server software is too old to support TLS 1.3, update the software – the certificate stays the same.
Tip: 0-RTT lets returning visitors send data in the very first packet, but that early data can be replayed by an attacker. Leave 0-RTT off unless your application only accepts safe, repeatable requests in it.
Should I disable TLS 1.0 and 1.1?
Yes. TLS 1.0 and 1.1 are deprecated, and RFC 8996 says they must not be used. Current major browsers no longer connect over them. Keeping them enabled only exposes you to weak ciphers and downgrade attacks.
Keep TLS 1.2 enabled alongside TLS 1.3 for older clients, payment terminals and integrations that do not support TLS 1.3 yet. If a client and server share no protocol version, the connection fails – in Chrome often as ERR_SSL_PROTOCOL_ERROR.
Recommended protocol settings (as of October 2026)
TLS 1.3: on
Fastest and safest. Supported by all current major browsers.
TLS 1.2: on
Keep for compatibility. Allow only ECDHE ciphers with AES-GCM or ChaCha20.
TLS 1.0 and 1.1: off
Deprecated by RFC 8996 in March 2021.
SSL 2.0 and 3.0: off
Broken for years. No current browser supports them.
How to enable TLS 1.3
You enable TLS 1.3 in your web server’s configuration, using a TLS library that supports it – OpenSSL 1.1.1 or later on Linux. Install your certificate as usual first; the steps below only change the protocol list.
Nginx
Nginx needs version 1.13.0 or later, built with OpenSSL 1.1.1 or later. In your server block:
ssl_protocols TLSv1.2 TLSv1.3;
Certificate setup on this server is covered in installing a certificate on Nginx.
Apache
Apache needs version 2.4.37 or later with OpenSSL 1.1.1 or later. In your virtual host or ssl.conf:
SSLProtocol -all +TLSv1.2 +TLSv1.3
Certificate setup is covered in installing a certificate on Apache.
IIS (Windows Server)
Windows Server 2022 and later support TLS 1.3 through Schannel, the Windows TLS component. Earlier Windows Server versions do not. Make sure TLS 1.3 is not disabled under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols, then restart the server. Certificate binding is covered in installing a certificate on IIS.
Hosting panels and CDNs
On shared hosting or behind a CDN, TLS versions are set in the provider’s dashboard. Many already enable TLS 1.3 for you. If a CDN terminates TLS, the visitor-facing version is set at the CDN, and the connection from the CDN to your origin server is configured separately.
Reload the server, then test from the command line:
openssl s_client -connect example.com:443 -tls1_3
A successful connection shows Protocol: TLSv1.3. For server-specific certificate setup, see how to install an SSL certificate.
Verify your HTTPS setup in seconds
Run your domain through our SSL checker to confirm the certificate, chain and hostname after enabling TLS 1.3.
Open the SSL checker