TLS 1.3 Migration Guide: Why and How to Upgrade in 2026

This guide covers why TLS 1.3 matters, the concrete differences from TLS 1.2 that affect your configuration, how to check what your server is currently negotiating, and step-by-step migration instructions for Nginx, Apache, and Cloudflare. We'll finish with the verification commands you should run after every TLS change.

Check your site right now: Free ZeriFlow scan in 60 seconds →

Why Migrate to TLS 1.3?

Three reasons, in order of business impact.

1. Faster Handshakes

TLS 1.3 cuts the handshake from two round trips to one. For repeat connections, 0-RTT mode reduces it to zero. On a 100ms RTT connection, that's 100-200ms shaved off every new connection. For sites with global audiences and lots of new visitors, that's a measurable conversion lift on the first paint.

2. Removed Legacy Crypto

TLS 1.3 strips out everything that turned out to be a bad idea: RSA key exchange (no forward secrecy), CBC-mode ciphers (Lucky 13, BEAST), MD5 and SHA-1 in signatures, static Diffie-Hellman, weak elliptic curves. The remaining cipher set is small, modern, and AEAD-only. There's no negotiation surface for an attacker to exploit, and no way to misconfigure yourself into a weak suite.

3. Compliance and Procurement

PCI-DSS 4.0, FedRAMP, and most enterprise procurement questionnaires now require TLS 1.2 minimum and prefer 1.3. Several browsers and CDNs have started issuing deprecation warnings for TLS 1.2-only configurations. Migrating now is cheap; migrating under audit pressure is not.

TLS 1.2 vs TLS 1.3: What Actually Changed

Three differences matter operationally:

Cipher suites are simpler. TLS 1.2 had hundreds of named suites combining key exchange, authentication, encryption, and MAC. TLS 1.3 has five total: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256, and TLS_AES_128_CCM_8_SHA256. You don't pick — the protocol negotiates. The right move is to enable all five and let the client choose.

Configuration directives differ. Most servers separate TLS 1.3 cipher selection from TLS 1.2. In Nginx that's ssl_ciphers (1.2 and below) versus ssl_conf_command Ciphersuites (1.3). Get this wrong and you'll think you've configured something that the server is silently ignoring.

Session resumption is different. TLS 1.3 replaces session IDs and tickets with PSKs. If you've tuned session caches in 1.2, the equivalent settings in 1.3 are different and need separate consideration — particularly around 0-RTT, which has replay implications you should think through before enabling.

Step 1: Check Your Current TLS Configuration

Before changing anything, capture what you've got. Three commands:

If openssl s_client -tls1_3 returns "no protocols available," your server isn't negotiating 1.3. If nmap shows TLS 1.0 or 1.1 in the supported list, you have legacy protocols enabled and need to disable them as part of this migration.

For a quick external view that you can hand to a non-technical stakeholder, run a ZeriFlow scan — the TLS section reports protocol versions, cipher suites, certificate chain, and HSTS status in plain English.

Step 2: Configure TLS 1.3 on Nginx

You need OpenSSL 1.1.1+ (1.1.1 added TLS 1.3 support) and Nginx 1.13.0+. Most distributions in 2026 ship with these by default.

Reload with nginx -t && systemctl reload nginx. The -t is important — a syntax error in the SSL block will crash on reload otherwise.

Step 3: Configure TLS 1.3 on Apache

You need Apache 2.4.36+ and OpenSSL 1.1.1+.

Reload with apachectl configtest && systemctl reload apache2.

Step 4: Configure TLS 1.3 on Cloudflare

Cloudflare is the easy case. In the dashboard:

1. 1SSL/TLS → Edge Certificates → set Minimum TLS Version to 1.2.
2. 2Toggle TLS 1.3 to On.
3. 30-RTT Connection Resumption: leave off unless you've reviewed the replay implications for your application (anything non-idempotent should not use 0-RTT).
4. 4Automatic HTTPS Rewrites: on. This handles mixed content for you at the edge.
5. 5Always Use HTTPS: on.

Cloudflare handles the connection from the browser to its edge. The connection from Cloudflare to your origin is a separate setting under Edge Certificates → Origin Server. Set that to Full (strict) so Cloudflare validates your origin certificate.

Step 5: Disable TLS 1.0 and 1.1

If your config above explicitly lists TLSv1.2 TLSv1.3, you've already done this. To verify:

The first two should return "no protocols available" or a handshake error. If either succeeds, you have legacy protocol support enabled somewhere — check load balancers, CDN settings, and any reverse proxies in the path.

Step 6: Verify and Monitor

After deploying, run external verification:

• SSL Labs (`ssllabs.com/ssltest`): aim for an A+ grade with TLS 1.3 listed in supported protocols and TLS 1.0/1.1 absent.
• `testssl.sh --severity LOW yourdomain.com`: full local audit, no severity findings expected.
• ZeriFlow: continuous monitoring of TLS configuration, certificate expiry, and HSTS status. Catches regressions when someone reverts a config.

Set up alerts for two things: certificate expiry (30, 14, and 7 days) and TLS configuration changes (a diff against your last known-good scan).

For the broader configuration hardening that should sit alongside TLS, see our HTTP security headers guide.

FAQ

Q: Will enabling TLS 1.3 break old browsers or clients?

A: No, as long as you keep TLS 1.2 enabled in parallel. Every browser released since 2018 supports TLS 1.3, but plenty of older devices, IoT clients, and legacy software still negotiate 1.2. Drop 1.0 and 1.1 freely; keep 1.2 unless you have specific reason to require 1.3-only.

Q: Should I enable 0-RTT connection resumption?

A: Only after reviewing the replay implications. 0-RTT data can be replayed by an attacker — if any of your endpoints are non-idempotent (state-changing GETs, for example), an attacker could replay them. The safe default is off; enable selectively if you've audited your routes.

Q: How is TLS 1.3 different for performance?

A: TLS 1.3 reduces the handshake from two round trips (TLS 1.2) to one (TLS 1.3) or zero (0-RTT for resumed sessions). On a 100ms RTT, that's 100-200ms saved on every new connection. For high-latency regions and mobile users, the impact on time-to-first-byte is measurable.

Q: What's the right TLS configuration for a CDN-fronted site?

A: Configure TLS 1.2 + 1.3 at the CDN edge (where browsers connect) and TLS 1.2 minimum on the origin (where the CDN connects). Use Full (strict) origin validation so the CDN won't trust an unverified origin. Most CDNs handle the modern cipher set automatically.

Q: How often should I re-check my TLS configuration?

A: Continuously. TLS configurations regress through OS upgrades, control panel changes, CDN setting tweaks, and "temporary" debugging. An automated scanner that alerts on changes catches regressions in minutes instead of months.

Conclusion

TLS 1.3 migration in 2026 is short, well-documented, and supported by every relevant tool in your stack. The work is mostly verification — making sure you actually deployed what you intended to deploy, that legacy protocols are gone, and that nothing in the path quietly downgrades a connection.

Do the migration, drop TLS 1.0 and 1.1, run the verification commands, and set up continuous monitoring so you catch regressions when they happen rather than during your next compliance review.

Start your free security scan on ZeriFlow → — TLS audit, cipher inventory, certificate monitoring, and HSTS validation in 60 seconds. Free plan available, no credit card required.

Further Reading

• Mozilla SSL Configuration Generator
• RFC 8996 — Deprecating TLS 1.0 and TLS 1.1
• Google — Core Web Vitals

<!-- zf-internal-links -->