3

I have decided to make a few websites that I run offer TLSv1.3 only. The server is apache 2.4.65 running on Debian bookworm 12.12 with all patches applied at the time of writing. The task should be easy enough, but I have a problem. Leaving away irrelevant stuff, this is my SSL configuration for a virtual host that is my test object:

SSLProtocol TLSv1.3
SSLCipherSuite TLS_AES_256_GCM_SHA384

When I restart apache with this configuration, it fails and writes the following into the error log of the host in question:

[Sat Dec 13 12:24:26.278551 2025] [ssl:emerg] [pid 1994080:tid 1994080] AH01898: Unable to configure permitted SSL ciphers
[Sat Dec 13 12:24:26.278559 2025] [ssl:emerg] [pid 1994080:tid 1994080] SSL Library Error: error:0480006C:PEM routines::no start line (Expecting: EC PARAMETERS) -- Bad file contents or format - or even just a forgotten SSLCertificateKeyFile?
[Sat Dec 13 12:24:26.278564 2025] [ssl:emerg] [pid 1994080:tid 1994080] SSL Library Error: error:0A0000B9:SSL routines::no cipher match

I really can't make any sense of this. First, I don't understand what the log is trying to tell me, and second, I have verified (via openssl ciphers) that the openssl installation provides the cipher that I have configured. In fact, from what I have read, it even is the only cipher that is allowed in TLSv1.3.

When I leave away the SSLCipherSuite line at all, it doesn't work either. When I replace it by SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384 (a syntax that I I've come over when researching possible causes for the problem), it does not work either.

But when I use SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384, apache starts without problem, and Firefox connects to the respective host using TLSv1.3 as desired.

I would like to understand why the syntax from the first code block causes problems although the cipher definitely is allowed in TLS 1.3, and why it works when I allow the same (?) cipher using TLSv1.2 syntax although I have disallowed TLSv1.2, and also if this means that apache under any circumstances could be made use TLSv1.2 (instead of TLSv1.3) because of the non-TLSv1.3 cipher name.

Improve this question
3
  • Same error with openssl ciphers -tls1_3 TLS_AES_256_GCM_SHA384 Commented yesterday
  • Related on SO: openssl s_client no cipher match Commented yesterday
  • 1
    @StéphaneChazelas: the nonoption argument to openssl ciphers specifies only old-style (kx/auth/cipher/MAC) suites, not the TLS1.3 cipher/PRF ones; for 1.3 you must use -ciphersuites $list which is annoying; and -tls1_3 only has effect if you also specify -s (see same link) which is just silly. openssl ciphers -ciphersuites TLS_AES_256_GCM_SHA384 NONE works on some of my systems but not debian:12 -- as McCoy said, "quite logical ... in a pig's eye!" Commented 12 hours ago

1 Answer 1

Reset to default
6

SSLCipherSuite TLSv1.3 TLS_AES_256_GCM_SHA384 is correct and should work, is documented exactly where you should expect, and does work for me using debian:12 from dockerhub. You just dismiss it without explanation so I have no way to guess what, if anything, is wrong.

Aside: that is NOT the only suite in TLS1.3. There are five currently standardized (but one sort-of withdrawn) of which OpenSSL implements three. What is true is that TLS1.3 can't use any of the suites defined for any previous protocol, whereas going from SSL3->TLS1.0->TLS1.1->TLS1.2 many of the prior suites were retained and until 1.2 only a few new ones added. (SSL2->SSL3 was also a complete replacement because it changed the code structure, but so long ago people have forgotten.)

Explanation:

OpenSSL since 1.1.1 has two APIs for configuring ciphersuites -- the old 'cipherstring/cipherlist' API that's been there 'forever' and handles the old-style kx/auth/cipher/MAC suites used from SSL2 through TLS1.2, and a new 'ciphersuite' API that handles only new-style cipher/PRFKDF TLS1.3 suites.

The pre-existing directive SSLCipherSuite stuff or now-explicit SSLCipherSuite SSL stuff uses the old API, while SSLCipherSuite TLSv1.3 stuff uses the new. SSLCipherSuite TLS_AES_256_GCM_SHA384 tells Apache to tell OpenSSL to use only that ciphersuite for TLS1.2 and below (even though your SSLProtocol prevents any such connection actually being made; that's orthogonal) and since that suite can't be used for TLS1.2 and below -- and you didn't provide any other(s) that can -- it returns the error for 'no match'. (If you configure both at least one bad cipher and at least one good cipher in the same list, OpenSSL uses the good one(s) and silently ignores the bad one(s).)

When you did SSLCipherSuite ECDHE-RSA-... (a valid 1.2-only suite) OpenSSL accepted that configuration because it is valid for 1.2, effectively ignored it because you prevented any use of 1.2, and because you didn't specify the directive for TLSv1.3 OpenSSL used its default there, which is all three implemented suites.

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.