Is Your Site on TLS 1.3? Check and Enable It (Apache, Nginx, WHM)

You may already be on TLS 1.3, but "may" is a guess, and you can replace that guess with one command in about ten seconds. If the test fails, the correction may be a protocol setting in Nginx, Apache or WHM, or it may require a newer OpenSSL or operating system. Keep TLS 1.2 switched on while you do it, because some visitors and older devices may still need it.

Here is the fact that made me write this. On 16 July 2026 the IETF published RFC 9852, titled "New Protocols Using TLS Must Require TLS 1.3", as part of BCP 195. For any new protocol built on TLS, version 1.3 is now the required default and TLS 1.2 is only an optional extra. The old default has flipped.

By the end of this guide you will be able to test your own site for TLS 1.3, turn it on in WHM, Nginx or Apache if it is missing, and prove that it worked.

What TLS 1.3 actually is, and what the new RFC really says

TLS (Transport Layer Security) is the encryption layer behind the padlock in the browser. When someone visits https://example.com, their browser and your server first agree on a TLS version and a set of ciphers (the encryption recipes), then they talk privately.

Think of it like two people picking a shared language before a meeting: they use the newest one both speak. TLS 1.3 is the newest, and TLS 1.2 is the older one almost everyone still understands.

RFC 9852 updates RFC 9325, and its rule is about new protocols: "Any new protocol that uses TLS MUST specify TLS 1.3 as its default", and such a protocol "MAY specify TLS 1.2 as an additional, non-default option." It does not order existing websites to drop TLS 1.2. The RFC also says it does not apply to DTLS (the version of TLS used over UDP).

Why this matters: the RFC is a strong signal about where the standards world is heading. It says "TLS 1.2 can be configured securely", but that it is "much more difficult" than using TLS 1.3, and that fixing TLS 1.2's weak spots takes "bespoke configuration." It also points to RFC 9851, titled "TLS 1.2 is in Feature Freeze." So TLS 1.2 is still allowed and still useful, but TLS 1.3 is the version that gets the attention from here on.

That is why this guide has one simple goal: make sure TLS 1.3 works on your site, and leave TLS 1.2 on. If you also want to switch off the really old versions, that is a separate job, covered in how to disable TLS 1.0 and 1.1 safely.

Before you start

• A terminal with openssl installed. Linux and macOS usually have it; on Windows you can use WSL or any Linux server you can SSH into.
• Your domain name, for example example.com.
• For WHM: a root login to WHM. A normal cPanel user login cannot change this setting.
• For Nginx or Apache on a VPS: SSH access and sudo rights, plus a text editor such as nano.
• A backup of the config file you plan to edit. I will show you the copy command at each step.
• Time and risk vary by server. A protocol-only change can be brief when you have console access and a tested rollback; an OpenSSL or operating-system upgrade needs a planned maintenance window.

Heads up: if you are on shared hosting, you cannot edit the server's TLS settings yourself. You can still run the test in Step 1, and then send the result to your host. More on that in Step 2.

Step-by-step: check and enable TLS 1.3

Step 1: Test what your site supports right now

This is the part everyone should do, whatever kind of hosting you have. We use openssl s_client, a small test client that connects to a server and reports what it negotiated.

Three options matter here. -connect sets the host and port. -servername sends the domain name in the handshake as SNI (Server Name Indication), which tells a shared server which site you want. -brief prints a short summary instead of a wall of certificate text. The -tls1_3 and -tls1_2 options force one exact TLS version, so the test only succeeds if the server supports that version.

This command asks your server to connect using TLS 1.3 only:

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

What you should see: a short summary of the connection that names TLSv1.3 as the protocol, plus the cipher suite it picked. If the server does not support TLS 1.3, you get a handshake error instead of a summary.

This command runs the same test with TLS 1.2 only, which should also succeed:

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

This command tries TLS 1.1, which on a well-configured server should fail:

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

Quick tip: this guide is about making TLS 1.3 work, so the TLS 1.3 and TLS 1.2 results are the ones you care about most. The TLS 1.1 test is a quick sanity check. If it unexpectedly succeeds, that is a job for the separate TLS 1.0 and 1.1 guide linked above.

Now read your results:

• TLS 1.3 works and TLS 1.2 works: you are done. Skip to "How to check it worked" if you want extra confidence.
• TLS 1.3 fails and TLS 1.2 works: keep reading, the fix is below.
• Both fail: this is a bigger problem than TLS 1.3, such as a wrong port, a firewall, or no certificate. Check the Troubleshooting section first.

Made-up example: Priya runs a small bakery site on a VPS a freelancer set up years ago. Her TLS 1.2 test succeeds, but TLS 1.3 fails. The cause is a single hand-typed SSLProtocol line that lists only TLS 1.2, and changing that line fixes it.

Step 2: On shared hosting, ask your host

If you use shared hosting with a cPanel user account, the TLS protocol list is set at the server level by your host. I could not find a user-facing TLS version toggle in the cPanel user docs, so I will not promise you one.

What you can do is send your host the output of the Step 1 commands and ask a direct question. There is a ready-to-send message at the end of this guide.

If your site sits behind Cloudflare, read Step 6 before you contact anyone, because the test above may be talking to Cloudflare, and your host's server may never see that connection.

Step 3: Enable TLS 1.3 in WHM (cPanel servers, root access)

If you manage your own cPanel server, WHM controls the Apache protocol list for every site on it. Do not edit Apache's config files by hand on a cPanel server; use WHM so your change survives rebuilds.

cPanel's documentation lists the default for this setting as all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1. On paper, all should already include TLS 1.3 on a modern OpenSSL. But cPanel's own pages are not perfectly clear on whether TLS 1.3 is active by default on every server, so trust your Step 1 test, not the default.

Before you change anything, note down the current value of the field, so you can put it back if needed. A screenshot or a copy into a text file is enough.

1. Log in to WHM as root.
2. Go to WHM Home > Service Configuration > Apache Configuration > Global Configuration.
3. Find the SSL/TLS Protocols field. This is Apache's SSLProtocol setting.
4. Set it to the value below.
5. Click Save at the bottom of the page.
6. Click Rebuild Configuration and Restart Apache.

This is the exact value cPanel's support article gives for enabling TLS 1.3 while keeping TLS 1.2:

All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2 +TLSv1.3

What you should see: after you click Save, WHM shows a new screen with the rebuild button. After the rebuild, Apache restarts and every site on the server uses the new list.

Heads up: leave the SSL Cipher Suite field alone. cPanel recommends the default cipher setting, and TLS 1.3 brings its own cipher suites, so you do not need to touch ciphers to enable it.

The cPanel Global Configuration docs I used are marked valid for version 130 and later, so older versions may look different.

Step 4: Enable TLS 1.3 in Nginx (VPS or dedicated server)

Good news first: the Nginx docs say the TLSv1.3 parameter is used by default since Nginx 1.23.4. The documented default for ssl_protocols is TLSv1.2 TLSv1.3. So if you run a recent Nginx and never set ssl_protocols yourself, TLS 1.3 is likely already on.

The catch is OpenSSL. The Nginx docs say TLSv1.3 "works only when OpenSSL 1.1.1 or higher is used." An old server with old OpenSSL cannot speak TLS 1.3, whatever the config says.

This command, which is standard Nginx usage, prints the Nginx version and the OpenSSL version it was built with:

nginx -V 2>&1 | head -n 3

This command searches your Nginx config folder for any hand-written ssl_protocols lines, which is where old settings hide:

sudo grep -rn "ssl_protocols" /etc/nginx/

If the effective configuration for the hostname lists only TLSv1.2, or older versions, you have found a likely cause. Use sudo nginx -T to view the configuration Nginx actually loaded, including files pulled in with include. Back up the file outside the active Nginx include tree before editing it (replace the source path with the file you will change):

sudo install -d -m 700 /root/config-backups
sudo cp -p /etc/nginx/nginx.conf "/root/config-backups/nginx.conf.$(date -u +%Y%m%dT%H%M%SZ).bak"

Then change the line so it reads exactly like this. The directive works in the http block or a server block:

ssl_protocols TLSv1.2 TLSv1.3;

Why this matters: ssl_protocols can appear at http or server scope, and virtual-host selection can make the default server's settings relevant during the handshake. Change only the scope that is meant to control the affected hostname. Do not delete every other match: a scoped directive may be intentional. Compare the affected server block, its listen address, the default server for that address and the inherited http setting.

These commands are standard Nginx practice: the first tests the config for errors, and the second reloads Nginx only if the test passed:

sudo nginx -t && sudo systemctl reload nginx

What you should see: nginx -t reports that the configuration test passed, and the reload runs quietly. If the test reports an error, the && stops the reload, and your site keeps running on the old config. Fix the error and try again.

Heads up: while you are in there, you may see ssl_early_data. This turns on TLS 1.3 "0-RTT" (zero round trip) mode, which lets returning visitors send data a tiny bit sooner. It is off by default, and the Nginx docs warn that requests sent in early data "are subject to replay attacks", meaning an attacker could resend them. Leave it off unless a developer has made your app check the $ssl_early_data variable.

Step 5: Enable TLS 1.3 in Apache (VPS without cPanel)

The Apache docs list the SSLProtocol default as all -SSLv3 (up to version 2.4.16 it was plain all). The all shortcut covers the protocol versions that the linked OpenSSL library supports. TLS 1.3 is available only when Apache uses OpenSSL 1.1.1 or later.

So, again, a modern Apache that nobody tweaked should already offer TLS 1.3. The usual reason it does not is an old hand-typed SSLProtocol line, like in Priya's made-up story.

This command searches the common Apache config folders for SSLProtocol lines (Debian and Ubuntu use /etc/apache2, RHEL-family systems use /etc/httpd):

sudo grep -rni "SSLProtocol" /etc/apache2/ /etc/httpd/ 2>/dev/null

Back up the file you are about to change outside the active Apache include tree; replace the source path with the one grep showed you:

sudo install -d -m 700 /root/config-backups
sudo cp -p /etc/apache2/mods-available/ssl.conf "/root/config-backups/ssl.conf.$(date -u +%Y%m%dT%H%M%SZ).bak"

Then set the line like this. It uses Apache's documented [+|-]protocol syntax: switch everything off, then switch on exactly TLS 1.2 and TLS 1.3:

SSLProtocol -all +TLSv1.2 +TLSv1.3

SSLProtocol works in the main server config or inside a virtual host. Here is a detail from the Apache docs that catches people out. Before OpenSSL 1.1.1, the protocol for name-based virtual hosts always came from the base virtual host, meaning the first one declared on that IP and port. Since Apache 2.4.42 with OpenSSL 1.1.1 or later, each virtual host's own SSLProtocol is honored when the client sends SNI. If a virtual host has no SSLProtocol of its own, the global value applies when one is set.

Do not touch SSLCipherSuite for this job. The Apache docs explain that TLS 1.3 ciphers are set separately with a TLSv1.3 specifier, and TLS 1.3 ciphers cannot be set in a directory context. The defaults are fine.

These commands are standard Apache practice: the first checks the config for errors, the second reloads Apache only if the check passed. On Debian and Ubuntu the service is apache2:

sudo apachectl configtest && sudo systemctl reload apache2

On RHEL, AlmaLinux and Rocky Linux the service is usually called httpd, so use this version instead:

sudo apachectl configtest && sudo systemctl reload httpd

What you should see: configtest reports that the syntax is fine, and the reload runs. If it prints an error, the && stops the reload. Fix the line it points to and try again.

Step 6: If your site is behind Cloudflare, test two connections

When Cloudflare proxies your site (the orange cloud), there are two separate TLS connections. One runs from the visitor to Cloudflare, called the edge. The other runs from Cloudflare to your server, called the origin.

Your Step 1 test against example.com reaches Cloudflare's edge, so it tells you nothing about your own server. For the edge, Cloudflare's docs describe a TLS 1.3 toggle on the Edge Certificates page of the dashboard; switch it to On. The docs say it is available on all plans, Free through Enterprise. They also note you cannot pick individual TLS 1.3 cipher suites there.

For your origin, test your server directly. This command connects to your server's IP address while still sending your domain name as SNI (replace 192.0.2.10 with your real server IP):

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

Heads up: Cloudflare's TLS 1.3 page does not say how the toggle affects the Cloudflare-to-origin connection, so I will not guess. Make each side work on its own. If you are also fixing SSL modes or redirect loops, see Cloudflare SSL mode Full (strict) without redirect loops.

Step 7: Re-test

Run the three commands from Step 1 again. If you use Cloudflare, also run the origin test from Step 6.

What you want: TLS 1.3 succeeds, TLS 1.2 succeeds, and TLS 1.1 fails. That combination means modern browsers get the newest version and older clients still connect.

How to check it worked

Your main protocol proof is the openssl s_client test with -tls1_3. A negotiated TLS 1.3 summary proves that the endpoint accepted that protocol. By default, s_client can continue after certificate verification errors, so protocol success alone does not prove that the certificate is trusted or valid for the hostname. For a stricter combined check on a current OpenSSL client, add -verify_return_error -verify_hostname example.com and investigate any non-zero exit.

For a second opinion, cPanel's support article suggests the free SSL Labs SSL Test at https://www.ssllabs.com/ssltest/. Enter your domain, let the scan finish, and look for the list of supported protocol versions in the report. You want to see TLS 1.3 and TLS 1.2 listed as supported.

Quick tip: test the exact hostnames people use. If you serve both example.com and www.example.com, test both, because they can point to different virtual hosts or even different servers.

If you want to go further after this and look at newer HTTP versions, see how to enable HTTP/3 on Cloudflare and check it with curl.

Troubleshooting

The TLS 1.3 test fails, but your config says TLSv1.3

Likely cause: your web server is linked against an OpenSSL older than 1.1.1. Both the Nginx and Apache docs say TLS 1.3 needs OpenSSL 1.1.1 or later. Fix: run nginx -V or check your Apache build, and update the OS packages. On a very old OS, this may mean moving to a newer OS release, which is a job to plan carefully or hand to your host.

openssl s_client says the option -tls1_3 is unknown

Likely cause: the openssl on the computer running the test is itself too old to know TLS 1.3. This is about your laptop, not your server. Fix: run the test from a newer machine or a recent Linux server, or use the SSL Labs test.

You changed the file, but nothing changed

Likely cause: a different ssl_protocols or SSLProtocol scope controls the affected hostname, or the service was not reloaded. Fix: inspect the effective configuration with nginx -T or Apache's virtual-host dump, identify the default and named virtual hosts for the same address and port, then change only the directive that controls the target hostname. Keep intentional per-site settings and retest after a successful reload.

Your edit on a cPanel server disappeared

Likely cause: you edited Apache files by hand, and WHM rebuilt the config from its own settings. Fix: make the change in WHM Home > Service Configuration > Apache Configuration > Global Configuration as in Step 3, then click Rebuild Configuration and Restart Apache.

nginx -t or apachectl configtest reports an error after your edit

Likely cause: a typo, such as a missing semicolon at the end of the Nginx line, or TLSV1.3 with the wrong letter case. Fix: compare your line character by character with the code blocks above. If you are stuck, restore your backup with cp and test again, and your site stays on the old config the whole time.

Only one of several sites on a server gets TLS 1.3

Likely cause: the hostname is landing on a different address, port or virtual host, or Apache and OpenSSL are old enough that the base virtual host controls protocol negotiation. Fix: inspect Apache's virtual-host map and the base virtual host for that address, then set the intended protocol policy at the controlling scope. Do not remove valid per-site lines blindly.

A few pro tips

Leave TLS 1.2 on. RFC 9852 is about new protocols, and nothing in it tells you to remove TLS 1.2 from a public website. Older devices and tools may still depend on it.

Ask a developer or your host when the fix means upgrading OpenSSL or the operating system. That needs a maintenance window and a full server backup.

While you are thinking about TLS, it is worth knowing that certificate lifetimes are getting shorter too. Here is what shorter SSL certificate lifetimes mean for site owners.

The one message worth forwarding

Copy this to your host, developer or whoever runs your server:

"Hi, could you check whether our site supports TLS 1.3? When I run openssl s_client -connect example.com:443 -servername example.com -tls1_3 -brief, the result is: [paste result]. Please make sure the server uses OpenSSL 1.1.1 or later and that the protocol setting allows both TLS 1.2 and TLS 1.3 (for example SSLProtocol -all +TLSv1.2 +TLSv1.3 on Apache, ssl_protocols TLSv1.2 TLSv1.3; on Nginx, or the SSL/TLS Protocols field in WHM Global Configuration). Please keep TLS 1.2 enabled. Thank you."

The takeaway: one openssl command tells you whether TLS 1.3 negotiates. If it does not, check the effective virtual-host configuration and the OpenSSL build before changing anything, and keep TLS 1.2 enabled for compatibility.