I am running Apache2 version:

Server version: Apache/2.4.29 (Ubuntu)
Server built:   2018-04-25T11:38:24

I would like to enable TLSv1.3 but I get an error below in Apache2 if I put SSLProtocol TLSv1.2 TLSv1.3 in the ssl.conf file:

# apachectl configtest

AH00526: Syntax error on line 79 of /etc/apache2/mods-enabled/ssl.conf:
SSLProtocol: Illegal protocol 'TLSv1.3'
Action 'configtest' failed.
The Apache error log may have more information.

Is it not possible to enable TLSv1.3 in Apache2 (yet)?

I know Nginx can do it, but this question aims at Apache2.


5 Answers 5


Debian Buster = TLSv1.3 supported

In Debian Buster (currently in testing), the TLSv1.3 is supported already.

The following information is dated to:

# date -I


Apache2 version:

# apache2 -v

Server version: Apache/2.4.38 (Debian)
Server built: 2019-01-31T20:54:05

Where to enable

Globally in:


Locally in:

Your VirtualHost(s) located in:


How to enable

To this date, the TLSv1.1 has been deprecated finally. So, you want only TLSv1.2 and TLSv1.3.

To do that, put this line in the above-mentioned file:

SSLProtocol -all +TLSv1.3 +TLSv1.2

Cipher suites

The cipher suites are now divided into 2 categories, that being SSL (below TLSv1.3) and TLSv1.3, you may want to use your own set of ciphers, take this only as an example:

SSLCipherSuite    TLSv1.3   TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256


One important note to the end:

There is one new curve you could / should enable: X25519.

You can do this for instance like this, again only example:

SSLOpenSSLConfCmd Curves X25519:secp521r1:secp384r1:prime256v1

Example domain test on SSLLabs

Experimental: This server supports TLS 1.3 (RFC 8446).

TLSv1.3 enabled

  • 1
    What about TLS_CHACHA20_POLY1305_SHA256?
    – Chazy Chaz
    Nov 14, 2019 at 15:24
  • @ChazyChaz I personally don't use the ChaChaPoly ciphers, which does not mean they're bad or anything like that, it's just I know little to none about them. But what will interest you more is a performance impact - AES is insanely fast due to CPU instructions AES-NI if available, that is. Nov 14, 2019 at 15:31
  • @LinuxSecurityFreak Poly1305 performs better on processors lacking AES-NI. That does typically mean pre-2011 though, so yes definitely becoming less of a requirement, but does more positive than negative to have it available. Chrome knows this, and on my i7-920 machines it favours using CHACHA20_POLY1305 over AES_256_GCM when both ciphers are available. (I can test this on any CloudFlare fronted TLS site.)
    – Adambean
    Jan 4, 2020 at 18:32

TLSv1.3 is now supported in Apache2 version 2.4.36 with OpenSSL 1.1.1 Source.


TLSv1.3 is not yet supported by Apache 2.4.

When it is supported by OpenSSL (see info here), Apache 2.4 should have it too.


Editor's Note

Beware, using a PPA might ruin your system, at least the future distribution upgrades, from my experience at least.

If you are ready to take the risk...

You may use this PPA, this command adds it to your system without any hassle:

sudo add-apt-repository ppa:ondrej/apache2

At the time of this writing, the current version was:

$ apache2 -v

Server version: Apache/2.4.37 (Ubuntu)
Server built:   2018-10-28T15:27:08

TLSv1.3 is supported in that version.

To enable it globally for all VirtualHosts, locate your ssl.conf and set:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Then restart Apache2 and it should be ready for a test, notably it on these sites:



My example result = TLSv1.3 enabled

My example result = TLSv1.3 enabled


It turned out that the update to OpenSSL 1.1.1 was not enough. Apache had to be changed as well. That change was backported to version 2.4.29. Therefore, since Monday with 2.4.29-1ubuntu4.12, Ubuntu 18.04 LTS supports TLS 1.3 out of the box now. That was the configuration mentioned by the original poster.

TLS versions, cipher suites, and curves are still a hot debate as the recent TLS 1.0 deprecation on Stack Exchange showed. testssl.sh 3.0 was quite happy with the defaults of Apache 2.4.29 and OpenSSL 1.1.1. Therefore, you should double-check if you not inadvertently disabled newer technologies like the curve X448 or TLS 1.3. For example, if you use SSLProtocol -all, you are disabling all upcoming protocol version. For example, if you use SSLOpenSSLConfCmd Curves, you are disabling all upcoming curves.

Consequently, I am not sure if it is a good idea to tweak those defaults once and then forget about them. Instead, for those who like to change the defaults, looking for a maintained configuration, I used the Mozilla generator as starting point. At the end of today—so double-check tomorrow—and thanks to the already mentioned way to configure the curves, I went for the SSL_Conf_Cmd API completely:

SSLEngine on
#SSLOpenSSLConfCmd MinProtocol TLSv1 # commented because current default in Ubuntu 18.04 LTS
SSLOpenSSLConfCmd Ciphersuites TLS_AES_128_GCM_SHA256 # if you have the computing resources, consider not to tweak this
SSLOpenSSLConfCmd Curves X25519:secp256r1:secp384r1 # if you have the computing resources, consider not to tweak this
SSLOpenSSLConfCmd Options ServerPreference,-SessionTicket

If you go for a dual ECDSA+RSA based certificate installation, for example ECC from Sectigo and RSA from RapidSSL, the above fulfills Security Level 3, still backward compatible even with very old clients.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.