Free tools Windows power users keep installed

One-click scans. No signup required.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

To enable TLS 1.3, configure the system that terminates HTTPS: add SSLProtocol TLSv1.2 TLSv1.3 to Apache, or ssl_protocols TLSv1.2 TLSv1.3; to Nginx, provided the server and its OpenSSL library support TLS 1.3. In Cloudflare, turn on SSL/TLS → Edge Certificates → TLS 1.3. Keep TLS 1.2 enabled unless you have confirmed every intended client and integration supports TLS 1.3, then test the negotiated protocol at the endpoint visitors actually use.

What TLS 1.3 changes—and where to enable it

TLS is the protocol that protects the connection between a client and the endpoint accepting its HTTPS connection. TLS 1.3 support depends on both the server software and its cryptographic library; a configuration directive cannot add support to an older build or library.

With a direct Apache or Nginx deployment, the web server usually terminates HTTPS, so its configuration and linked OpenSSL determine which protocol versions are available. With Cloudflare proxying a site, there can be two separate TLS connections: visitor-to-Cloudflare and Cloudflare-to-origin. Enabling TLS 1.3 at Cloudflare’s edge does not configure the origin’s TLS settings.

Endpoint Configuration surface Key requirement
Apache HTTPS server SSLProtocol in server or virtual-host configuration Apache HTTP Server 2.4.43 or newer with OpenSSL 1.1.1 or newer
Nginx HTTPS server ssl_protocols in an HTTPS configuration HTTP SSL module built in and a linked OpenSSL version supporting TLS 1.3
Cloudflare edge Edge Certificates dashboard setting or zone setting tls_1_3 Cloudflare terminates the visitor’s connection; the origin remains separately configured

The Apache version requirement is from the Apache HTTP Server project’s TLS 1.3 guidance. Nginx’s documented TLS 1.3 default applies to Nginx 1.27.3 and later when the linked OpenSSL supports the protocol. A packaged or vendor-built server may differ, so check the actual build on your host.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Before changing the configuration

  • Identify the endpoint you want to configure: the public hostname, the origin server, or both.
  • Confirm the Apache or Nginx build and its OpenSSL support. For Nginx, also confirm that ngx_http_ssl_module is present; it is not built by default and requires --with-http_ssl_module plus OpenSSL.
  • Make a backup of the active configuration and know how to restore it if the syntax check or reload fails.
  • Use a certificate and private key that already serve the HTTPS virtual host or server block. TLS 1.3 does not replace certificate setup.
  • Plan to retain TLS 1.2 unless you have checked the compatibility needs of your visitors, older clients, and upstream integrations.

Enable TLS 1.3 in Apache

Apache’s mod_ssl directive SSLProtocol controls which protocol versions the server accepts. It can be set in server configuration or a virtual host. For a typical HTTPS virtual host, use:

<VirtualHost *:443>
    ServerName example.com
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLProtocol TLSv1.2 TLSv1.3
</VirtualHost>
  1. Check that Apache is at least version 2.4.43 and uses OpenSSL 1.1.1 or newer for TLS 1.3 web serving.
  2. Add or adjust SSLProtocol in the intended virtual host, or in the server configuration if the policy should apply more broadly. Avoid conflicting settings elsewhere in the active configuration.
  3. Check the configuration using the syntax-test command for your installation, commonly apachectl configtest or httpd -t. It should report that the syntax is OK.
  4. If the check succeeds, gracefully reload Apache using the service command for your operating system, then verify the live endpoint as described below.

Use SSLProtocol TLSv1.3 only if all clients and integrations that must connect support TLS 1.3. It disables TLS 1.2 at that Apache endpoint, which can exclude older clients. Apache 2.4.42 and later can honor protocol settings per name-based virtual host when built with OpenSSL 1.1.1 or newer and the client sends SNI; older combinations may not behave as expected with different virtual-host policies.

Enable TLS 1.3 in Nginx

Put ssl_protocols inside the HTTPS server block. A basic configuration looks like this:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols       TLSv1.2 TLSv1.3;
}
  1. Confirm that your Nginx build includes ngx_http_ssl_module and is linked against an OpenSSL version with TLS 1.3 support.
  2. Add ssl_protocols TLSv1.2 TLSv1.3; to the relevant HTTPS server block. Nginx 1.27.3 and later document TLS 1.2 and TLS 1.3 as defaults when supported by OpenSSL, but setting the policy explicitly makes the intended configuration visible.
  3. Run nginx -t. Do not reload if it reports a syntax error or cannot open a referenced certificate, key, or included file.
  4. After a successful test, reload Nginx with the service command for your system and test the public endpoint.

The Nginx directive’s documented default is TLSv1.2 TLSv1.3; that does not overcome an unsupported OpenSSL build. As with Apache, a TLS-1.3-only policy can reduce compatibility and should be an intentional choice rather than a way to “enable” TLS 1.3.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Do not switch on early data without an application plan

TLS 1.3 support does not require enabling 0-RTT early data. Nginx’s ssl_early_data on; feature requires OpenSSL 1.1.1 or newer, and Nginx warns that requests sent in early data are subject to replay attacks. A replay could cause an application to process a request more than once. If early data is needed, pass the $ssl_early_data signal upstream and ensure non-idempotent operations reject early data or handle possible replay safely.

Turn on TLS 1.3 at Cloudflare

Cloudflare’s TLS 1.3 feature is available on Free, Pro, Business, and Enterprise plans. To enable it in the dashboard:

  1. Open the site’s Cloudflare dashboard.
  2. Go to SSL/TLS → Edge Certificates.
  3. Find TLS 1.3 and switch it to On.
  4. Test the public hostname from a TLS 1.3-capable client.

The zone setting is named tls_1_3. Cloudflare documents the values on, zrt (Zero Round Trip Time resumption), and off. Use the dashboard if you do not already manage zone settings through Cloudflare’s API; an API change must target the correct zone and use appropriate credentials. Cloudflare negotiates applicable TLS 1.3 cipher suites automatically through this control; it does not expose individual TLS 1.3 cipher selection there. Cipher restrictions for TLS 1.0–1.2 are a separate setting.

Keep the minimum TLS version separate from the TLS 1.3 switch

Turning on TLS 1.3 allows supported client connections to use it; the minimum-TLS control is a separate compatibility policy. Raising that minimum rejects visitors using protocols below the selected version, so assess legacy clients and integrations before changing it. Cloudflare generally recommends TLS 1.3 for security, but the right minimum depends on who must still connect.

What’s actually slowing this PC down?

Pick the symptom - the matching free tool is one click away.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Check both connections when Cloudflare proxies the origin

For a proxied hostname, first distinguish the visitor-to-Cloudflare connection from Cloudflare-to-origin. The browser’s negotiated protocol describes its connection to the edge; it does not prove the origin accepts TLS 1.3 or has a valid certificate for Cloudflare’s connection.

Configure HTTPS and port 443 at the origin, then set the origin’s protocol policy in Apache or Nginx if that is required. Check the Cloudflare encryption mode and origin certificate separately. Where appropriate, test the origin directly as well as the public Cloudflare hostname; direct-origin tests may require an origin address and the correct SNI hostname. Only enable HSTS after HTTPS is fully working and tested. HSTS makes browsers insist on HTTPS for the covered host, so a broken HTTPS deployment can prevent access until the policy expires or is otherwise cleared.

Verify the negotiated protocol

A configuration file shows what you intended to allow; a handshake test shows what a particular client actually negotiated with a particular endpoint. Run checks from a machine with an OpenSSL client that supports TLS 1.3.

openssl s_client -connect example.com:443 -servername example.com -tls1_3

In the output, find the negotiated protocol line and confirm it reports TLSv1.3. The -servername option sends SNI so the server can select the intended virtual host. If the command fails, test a TLS 1.2 connection too, then check whether the hostname resolves to Cloudflare or the origin and whether that is the endpoint you meant to inspect.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

For additional handshake and certificate diagnostics, run:

curl -I -v https://example.com/

Review which host answered, whether certificate verification succeeded, and the handshake details printed by your curl build. A successful HTTP response alone does not prove TLS 1.3 was used. Repeat the test against the public hostname and, where appropriate, the direct origin. Recheck after certificate renewal, server or OpenSSL upgrades, and Cloudflare setting changes because the active software, defaults, or endpoint may have changed.

Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Support on Ko-Fi

Troubleshooting common failures

Symptom Likely cause What to check or do
Apache rejects TLSv1.3 or a TLS 1.3 handshake fails Apache or its OpenSSL library is too old, or a different Apache binary/configuration is active Confirm the running server is Apache 2.4.43 or newer with OpenSSL 1.1.1 or newer, inspect the active configuration, then retest.
Nginx rejects ssl_protocols or TLS 1.3 is unavailable The HTTP SSL module is missing, the linked OpenSSL lacks support, or the running binary differs from the one checked Inspect the build and linked library; confirm ngx_http_ssl_module was built in. Rebuild or install a compatible package if necessary.
nginx -t or Apache’s syntax test fails Directive placement, spelling, include, certificate path, or key path is invalid Use the exact directive syntax above, read the reported file and line, fix the error, and rerun the test before reload.
The test connects but reports TLS 1.2 The client did not negotiate TLS 1.3, or the checked endpoint has a different policy Use a TLS 1.3-capable client and inspect whether DNS points to Cloudflare or the origin. Check that endpoint’s setting and linked library.
Public hostname works but direct-origin TLS differs Cloudflare edge and origin terminate separate connections Test each endpoint deliberately and configure each termination point independently.
Users or integrations fail after enabling TLS 1.3 only Some clients may require TLS 1.2 Restore TLSv1.2 alongside TLSv1.3 unless the affected clients have been upgraded or are intentionally excluded.
Cloudflare setting appears enabled, but browser tests do not show TLS 1.3 The client may not support TLS 1.3, or it may be reaching another endpoint Test with a TLS 1.3-capable client, confirm the hostname’s proxy/DNS path, and inspect the negotiated protocol rather than relying on the dashboard toggle alone.

Or skip the browser setup:

ScreenshotNeo is a website screenshot API and MCP server, not a TLS configuration or protocol-testing tool. If you have already confirmed your HTTPS endpoint and want a rendered capture, its one-call API can return an image:

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

See the ScreenshotNeo API documentation for request options. Before capture, it accepts cookie/consent banners like a visitor and removes 60+ known consent platforms, newsletter popups, and chat widgets; those steps can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers identify the page verdict and billing status. Its MCP server offers take_screenshot, get_page_info, and capture_pdf tools for AI agents. The free plan includes 1,000 screenshots per month with no card; paid plans start at $5 for 3,000.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Sign up for ScreenshotNeo’s free plan: 1,000 screenshots a month, no card required.

Frequently Asked Questions

Does enabling TLS 1.3 require changing my certificate?

No. TLS 1.3 changes the negotiated protocol, not the role of the HTTPS certificate. The certificate and private key still need to be valid for the hostname and correctly configured at the endpoint terminating TLS.

Is TLS 1.3 enough to make a website secure?

No single protocol setting is a complete security review. Certificate validity, origin protection, application behavior, protocol minimums, and safe handling of features such as early data also matter.

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.

Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.