TLS guide

TLS 1.2 vs TLS 1.3: Differences and How to Enable TLS 1.3

TLS 1.3 connects faster and drops the weak options TLS 1.2 still allows. Here is what differs and how to switch it on.

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 factDetail
TLS 1.2Published as RFC 5246 (2008)
TLS 1.3Published as RFC 8446 (August 2018)
TLS 1.0 and 1.1Formally 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 checker

TLS 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.

FeatureTLS 1.2TLS 1.3
Full handshakeTwo round tripsOne round trip
Resumed connectionsSession IDs or ticketsPre-shared keys, optional 0-RTT (zero round trip)
Cipher suitesMany, including legacy CBC and RSA key exchangeFive, all AEAD (authenticated encryption)
Forward secrecyOptional – depends on cipherAlways on (ephemeral Diffie-Hellman)
Certificate during handshakeSent unencryptedSent 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

  1. 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.

  2. ServerHello and keys

    The server picks a cipher, sends its key share, and both sides derive the session keys immediately.

  3. Encrypted certificate

    The server sends its certificate and signature, already encrypted. The browser validates the certificate chain.

  4. 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.

  • 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

Related articles

Frequently asked questions

Q: What is the difference between TLS 1.2 and 1.3?

A: TLS 1.3 has a faster handshake: it needs one round trip instead of two before data flows. It also cuts the cipher list to five modern AEAD cipher suites, always uses forward secrecy and encrypts the server certificate during the handshake. TLS 1.2 still allows legacy options such as RSA key exchange and CBC ciphers, so it needs careful configuration to stay secure.

Q: Do I need a new certificate for TLS 1.3?

A: No. TLS 1.3 works with the RSA or ECDSA SSL certificate you already have. The protocol version is a setting in your server or TLS library, not a property of the certificate. You do not need to reissue, rekey or buy a new certificate. If your server cannot offer TLS 1.3, update the server software or OpenSSL version instead.

Q: Should I disable TLS 1.0/1.1?

A: Yes. TLS 1.0 and 1.1 are deprecated: RFC 8996, published in March 2021, states they must not be used, and current major browsers no longer connect with them. Disable both on your servers and keep TLS 1.2 and TLS 1.3 enabled. TLS 1.2 covers older clients and integrations that do not support TLS 1.3 yet.

Q: How do I enable TLS 1.3?

A: Enable it in your server config, using a TLS library that supports it. On Nginx 1.13.0 or later with OpenSSL 1.1.1 or later, set ssl_protocols TLSv1.2 TLSv1.3. On Apache 2.4.37 or later, use SSLProtocol -all +TLSv1.2 +TLSv1.3. Windows Server 2022 and later support TLS 1.3 in IIS. Reload the server and test with openssl s_client.