You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2025/12/17 19:58:42 UTC
[VOTE] Release Apache Tomcat Native 2.0.11
The key differences in version 2.0.11 compared to 2.0.9 are:
- The windows binaries in this release have been built with OpenSSL
3.5.4 and APR 1.7.6
- OCSP support is included (but not enabled) by default with various
improvements to the OCSP checks
- Add the ability to configure TLS 1.3 ciphers
The 2.0.x branch is primarily intended for use with Tomcat 10.1.x
onwards but can be used with earlier versions as long as the APR/native
connector is not used.
The proposed release artifacts can be found at [1],
and the build was done using tag [2].
The Apache Tomcat Native 2.0.11 release is
[ ] Stable, go ahead and release
[ ] Broken because of ...
Thanks,
Mark
[1]
https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/native/2.0.11
[2]
https://github.com/apache/tomcat-native/commit/ea9ce74ebcf67f5e74ec9a704e7c53dff276169b
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Mark Thomas <ma...@apache.org>.
On 18/12/2025 11:18, Mark Thomas wrote:
> On 18/12/2025 01:28, Rainer Jung wrote:
<snip/>
>> So it seems our new code is not yet working as expected.
>
> Agreed.
>
>> Therefore I vote -1 for 2.0.11 and 1.3.2.
>
> ACK
>
> I suspect we will need new releases. Fortunately, that should be quite
> quick. The slow part is building APR and OpenSSL but I can re-use those
> builds and link them to the new Tomcat Native build.
I can confirm new releases will be required.
> I'd like to create some Tomcat unit tests that trigger these issues
> before I try fixing anything. Any hints / pointers or complete tests
> appreciated.
I've added a coupe of tests to 9.0.x and will port them to the other
branches shortly.
I'll look for other failure modes when I fix the Tomcat Native code but
if anyone spots additional failure modes please do feel free to add some
tests (or ping the list and I can add the test if you are short on time).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Christopher Schultz <ch...@christopherschultz.net>.
All,
On 12/18/25 6:18 AM, Mark Thomas wrote:
> On 18/12/2025 01:28, Rainer Jung wrote:
>> Am 18.12.25 um 01:26 schrieb Rainer Jung:
>
> <snip/>
>
>>> I ran those unit tests from TC 9.0.113 and 10.1.50 which are TLS
>>> based with the new tcnative versions 2.0.11 and 1.3.2. They fail in
>>> TestClientCertTls13 for NIO and NIO2 with the following error:
>>>
>>> Testcase: testClientCertPost[OpenSSL] took 0.104 sec
>>> Caused an ERROR
>>> Protocol handler initialization failed
>
> <snip/>
>
>> I added some debug lines.
>>
>> - the error "error:12800067:DSO support routines::could not load the
>> shared library" is shown, because "SSL_ERR_clear();" is missing
>> somewhere. If I add that in setCipherSuite, the SSL library error
>> thrown changes to "error:0A0000B9:SSL routines::no cipher match"
>
> We should definitely add the call to SSL_ERR_clear()
I think this indicates that we have some code path where we aren't
checking for, flushing, and reporting errors.
So cleaning errors before making a call to OpenSSL isn't a great plan,
though it does allow us to make progress, here.
I *think* the root cause of this hidden error is elsewhere in the
tcnative code.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Rémy Maucherat <re...@apache.org>.
On Fri, Dec 19, 2025 at 1:33 PM Mark Thomas <ma...@apache.org> wrote:
>
> On 18/12/2025 17:01, Rainer Jung wrote:
> > Am 18.12.25 um 17:17 schrieb Mark Thomas:
>
> <snip/>
>
> >> Hmm. We currently have:
> >>
> >> SSLContext.setCipherSuite
> >> and
> >> SSL.setCipherSuites
> >>
> >> so the original name for the new method won't work. How about:
> >>
> >> public static native boolean setCipherSuitesEx(long ctx, String
> >> cipherSuites)
> >>
> >> on both SSLContext and SSL
> >>
> >> I can also reproduce the "... Tomcat interprets the [ciphers]
> >> attribute..." warning now as well.
> >>
> >> There are a lot of moving parts here and I want to get to the bottom
> >> of all of the various issues we are seeing and make sure that they are
> >> resolved - or at least documented and understood - for all the various
> >> combinations of Tomcat version, OpenSSL version, Java version, Tomcat
> >> Native version etc.
> >>
> >> I think a tag this week is currently looking less likely than I
> >> thought a few hours ago.
> >
> > Since the OpenSSL methods for setting ciphers for TLS < 1.3 and == 1.3
> > behave so different, I wonder whether a uniform approach can work.
> >
> > The httpd web server reused its existing SSLCipherSuite config
> > directive, but in effect you can use it like before, which only sets the
> > cipher list for TLS < 1.3 or you can use it with the additional token
> > "TLS1.3" before the ciphers, which then sets the TLS 1.3 ciphers. And
> > you can use it twice, once for the non 1.3 ciphers and once for the 1.3
> > ciphers. So httpd makes no attempt to unify those two cases. They are
> > configured and handled separately.
> >
> > Since it might not be clear, which protocol client and server negotiate,
> > I am not sure how easy it is to get to a uniform cipher configuration.
> > Whether we provide two API methods (< 1.3 and == 1.3) or some syntactic
> > cipher list sugar that we can use to split the two intended cases (<1.3
> > and == 1.3) from one config string might be a question of style. But I
> > think we need a way to express different cipher configurations for < 1.3
> > and == 1.3.
> >
> > Hope that makes sense, but maybe I did not yet fully understand the
> > scope of the discussion.
>
> Thanks Rainer, I do understand where you are coming from.
>
> Things aren't quite so clear cut in Tomcat because we need to support
> both JSSE and OpenSSL, converting between the two as required.
>
> We can't re-use the httpd trick of defining the directive twice as we
> use XML configuration files. We could actually handle calling the setter
> twice. It is the getter that would be the issue for the store config code.
>
> JSSE uses a single configuration value for TLS <= 1.2 and TLS >= 1.3
> ciphers whereas OpenSSL uses two.
>
> OpenSSL will accept a combined value for both individual configuration
> values and just ignore the unrecognised ciphers.
>
> Internally, Tomcat stores ciphers using OpenSSL format and Tomcat has
> code to convert between JSSE cipher names and OpenSSL cipher names as
> required.
>
> I agree that there are two options.
>
> A. Have two cipher settings, one for TLS <= 1.2 and one for TLS >= 1.3.
> Use the separate ones for OpenSSL. Combine them when calling JSSE.
>
> B. Have one cipher setting. Use the single value when calling JSSE and
> for OpenSSL call both OpenSSL setters with the same value.
>
> I have been thinking about various use cases, trying to see if one
> option works better than the other.
>
> On balance, I think option A is better as with option B there is a
> backwards compatibility issue. Currently, if a user explicitly lists
> TLS1.2 ciphers, they will get TLS 1.2 ciphers + the TLS 1.3 default
> ciphers. With option B this would change to just TLS 1.2 ciphers.
>
> The drawback with option A is that excluding TLS 1.3 ciphers can't be
> done with the ciphers attribute. The user would have to use protocols.
>
> I'm going to proceed with option A. If I find any blockers, we can
> re-evaluate.
>
> I'm not planning on tagging Tomcat Native until I have a set of local
> changes for Tomcat 12.0.x that works with then current Tomcat Native 2.0.x
I agree with option A. I wanted to avoid it since it sounded horrible.
However, having to configure ciphers for TLS 1.3 is not likely at all.
As a result, I think this is the way to go.
Rémy
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Mark Thomas <ma...@apache.org>.
On 19/12/2025 18:52, Christopher Schultz wrote:
<snip/>
>> I agree that there are two options.
>>
>> A. Have two cipher settings, one for TLS <= 1.2 and one for TLS >=
>> 1.3. Use the separate ones for OpenSSL. Combine them when calling JSSE.
>>
>> B. Have one cipher setting. Use the single value when calling JSSE and
>> for OpenSSL call both OpenSSL setters with the same value.
>>
>> I have been thinking about various use cases, trying to see if one
>> option works better than the other.
>>
>> On balance, I think option A is better as with option B there is a
>> backwards compatibility issue. Currently, if a user explicitly lists
>> TLS1.2 ciphers, they will get TLS 1.2 ciphers + the TLS 1.3 default
>> ciphers.
>
> Why is this the case? Because it's tough to know whether "ALL" should
> apply to only the TLS.1.2 ciphers or the TLS1.3 ones, or both?
Because OpenSSL configures TLS 1.2 and TLS 1.3 completely separately.
The ciphers setting for Tomcat maps to the TLS 1.2 ciphers so Tomcat
users always get the default TLS 1.3 ciphers with OpenSSL.
> Actual TLSv1.3 cipher suite names are (currently) completely unique and
> there is no overlap with TLSv1.2 cipher suite names.
>
> so the only ambiguity could be with the meta-names like "ALL" and "!CBC"
> and the like.
No ambiguity. Those only apply to TLS 1.2
> So if a user "explicitly lists TLSv1.2 ciphers" then I don't see why
> they would get *any* TLSv1.3 ciphers at all.
Because OpenSSL configures TLS 1.2 and TLS 1.3 completely separately.
See above.
>> With option B this would change to just TLS 1.2 ciphers.
>>
>> The drawback with option A is that excluding TLS 1.3 ciphers can't be
>> done with the ciphers attribute. The user would have to use protocols.
>
> Why not allow syntax like "!TLSv1.3"? We already support syntax like
> that to remove ciphers like "!CBC" so why not do the same with the
> protocol-level matches? Or are those details being handled by OpenSSL
> today and we'd have to implement that kind of matching ourselves if we
> wanted to do this?
We currently mimic OpenSSL and OpenSSL doesn't do that. We could
implement extensions to the syntax to do that but I have multiple concerns:
- it will have different behaviour to OpenSSL which could cause confusion
- if OpenSSL ever adds a similar feature we could get a naming conflict
> I will note that "!" on the command line doesn't seem to work as I expect:
>
> $ openssl ciphers -v 'TLSv1.2'
> [list of 89 cipher suites]
>
> $ openssl ciphers -v '!TLSv1.2'
> Error in cipher list
> 802B8C6E337F0000:error:0A0000B9:SSL routines:SSL_CTX_set_cipher_list:no
> cipher match:../ssl/ssl_lib.c:2779:
>
> Nor does attempting to select TLSv1.3 ciphers:
>
> $ openssl ciphers -v 'TLSv1.3'
> Error in cipher list
> 80DB93DC417F0000:error:0A0000B9:SSL routines:SSL_CTX_set_cipher_list:no
> cipher match:../ssl/ssl_lib.c:2779:
>
> ... but maybe that's part of the problem, here.
Look at the -ciphersuites option for the ciphers command.
> This really just seems doable to me; maybe I'm missing some subtle yet
> important point.
My main concern is backwards compatibility. I've spent a while looking
at this and mimicking OpenSSL and having TLS 1.3 config to be completely
separate avoids all the backwards compatibility issues.
And there was me thinking the OCSP changes would be the biggest headache
with these native releases.
Mark
>> I'm going to proceed with option A. If I find any blockers, we can re-
>> evaluate.
>>
>> I'm not planning on tagging Tomcat Native until I have a set of local
>> changes for Tomcat 12.0.x that works with then current Tomcat Native
>> 2.0.x
>
> -chris
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 12/19/25 7:32 AM, Mark Thomas wrote:
> On 18/12/2025 17:01, Rainer Jung wrote:
>> Am 18.12.25 um 17:17 schrieb Mark Thomas:
>
> <snip/>
>
>>> Hmm. We currently have:
>>>
>>> SSLContext.setCipherSuite
>>> and
>>> SSL.setCipherSuites
>>>
>>> so the original name for the new method won't work. How about:
>>>
>>> public static native boolean setCipherSuitesEx(long ctx, String
>>> cipherSuites)
>>>
>>> on both SSLContext and SSL
>>>
>>> I can also reproduce the "... Tomcat interprets the [ciphers]
>>> attribute..." warning now as well.
>>>
>>> There are a lot of moving parts here and I want to get to the bottom
>>> of all of the various issues we are seeing and make sure that they
>>> are resolved - or at least documented and understood - for all the
>>> various combinations of Tomcat version, OpenSSL version, Java
>>> version, Tomcat Native version etc.
>>>
>>> I think a tag this week is currently looking less likely than I
>>> thought a few hours ago.
>>
>> Since the OpenSSL methods for setting ciphers for TLS < 1.3 and == 1.3
>> behave so different, I wonder whether a uniform approach can work.
>>
>> The httpd web server reused its existing SSLCipherSuite config
>> directive, but in effect you can use it like before, which only sets
>> the cipher list for TLS < 1.3 or you can use it with the additional
>> token "TLS1.3" before the ciphers, which then sets the TLS 1.3
>> ciphers. And you can use it twice, once for the non 1.3 ciphers and
>> once for the 1.3 ciphers. So httpd makes no attempt to unify those two
>> cases. They are configured and handled separately.
>>
>> Since it might not be clear, which protocol client and server
>> negotiate, I am not sure how easy it is to get to a uniform cipher
>> configuration. Whether we provide two API methods (< 1.3 and == 1.3)
>> or some syntactic cipher list sugar that we can use to split the two
>> intended cases (<1.3 and == 1.3) from one config string might be a
>> question of style. But I think we need a way to express different
>> cipher configurations for < 1.3 and == 1.3.
>>
>> Hope that makes sense, but maybe I did not yet fully understand the
>> scope of the discussion.
>
> Thanks Rainer, I do understand where you are coming from.
>
> Things aren't quite so clear cut in Tomcat because we need to support
> both JSSE and OpenSSL, converting between the two as required.
>
> We can't re-use the httpd trick of defining the directive twice as we
> use XML configuration files. We could actually handle calling the setter
> twice. It is the getter that would be the issue for the store config code.
>
> JSSE uses a single configuration value for TLS <= 1.2 and TLS >= 1.3
> ciphers whereas OpenSSL uses two.
>
> OpenSSL will accept a combined value for both individual configuration
> values and just ignore the unrecognised ciphers.
>
> Internally, Tomcat stores ciphers using OpenSSL format and Tomcat has
> code to convert between JSSE cipher names and OpenSSL cipher names as
> required.
>
> I agree that there are two options.
>
> A. Have two cipher settings, one for TLS <= 1.2 and one for TLS >= 1.3.
> Use the separate ones for OpenSSL. Combine them when calling JSSE.
>
> B. Have one cipher setting. Use the single value when calling JSSE and
> for OpenSSL call both OpenSSL setters with the same value.
>
> I have been thinking about various use cases, trying to see if one
> option works better than the other.
>
> On balance, I think option A is better as with option B there is a
> backwards compatibility issue. Currently, if a user explicitly lists
> TLS1.2 ciphers, they will get TLS 1.2 ciphers + the TLS 1.3 default
> ciphers.
Why is this the case? Because it's tough to know whether "ALL" should
apply to only the TLS.1.2 ciphers or the TLS1.3 ones, or both?
Actual TLSv1.3 cipher suite names are (currently) completely unique and
there is no overlap with TLSv1.2 cipher suite names.
so the only ambiguity could be with the meta-names like "ALL" and "!CBC"
and the like.
So if a user "explicitly lists TLSv1.2 ciphers" then I don't see why
they would get *any* TLSv1.3 ciphers at all.
> With option B this would change to just TLS 1.2 ciphers.
>
> The drawback with option A is that excluding TLS 1.3 ciphers can't be
> done with the ciphers attribute. The user would have to use protocols.
Why not allow syntax like "!TLSv1.3"? We already support syntax like
that to remove ciphers like "!CBC" so why not do the same with the
protocol-level matches? Or are those details being handled by OpenSSL
today and we'd have to implement that kind of matching ourselves if we
wanted to do this?
I will note that "!" on the command line doesn't seem to work as I expect:
$ openssl ciphers -v 'TLSv1.2'
[list of 89 cipher suites]
$ openssl ciphers -v '!TLSv1.2'
Error in cipher list
802B8C6E337F0000:error:0A0000B9:SSL routines:SSL_CTX_set_cipher_list:no
cipher match:../ssl/ssl_lib.c:2779:
Nor does attempting to select TLSv1.3 ciphers:
$ openssl ciphers -v 'TLSv1.3'
Error in cipher list
80DB93DC417F0000:error:0A0000B9:SSL routines:SSL_CTX_set_cipher_list:no
cipher match:../ssl/ssl_lib.c:2779:
... but maybe that's part of the problem, here.
This really just seems doable to me; maybe I'm missing some subtle yet
important point.
> I'm going to proceed with option A. If I find any blockers, we can re-
> evaluate.
>
> I'm not planning on tagging Tomcat Native until I have a set of local
> changes for Tomcat 12.0.x that works with then current Tomcat Native 2.0.x
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Mark Thomas <ma...@apache.org>.
On 18/12/2025 17:01, Rainer Jung wrote:
> Am 18.12.25 um 17:17 schrieb Mark Thomas:
<snip/>
>> Hmm. We currently have:
>>
>> SSLContext.setCipherSuite
>> and
>> SSL.setCipherSuites
>>
>> so the original name for the new method won't work. How about:
>>
>> public static native boolean setCipherSuitesEx(long ctx, String
>> cipherSuites)
>>
>> on both SSLContext and SSL
>>
>> I can also reproduce the "... Tomcat interprets the [ciphers]
>> attribute..." warning now as well.
>>
>> There are a lot of moving parts here and I want to get to the bottom
>> of all of the various issues we are seeing and make sure that they are
>> resolved - or at least documented and understood - for all the various
>> combinations of Tomcat version, OpenSSL version, Java version, Tomcat
>> Native version etc.
>>
>> I think a tag this week is currently looking less likely than I
>> thought a few hours ago.
>
> Since the OpenSSL methods for setting ciphers for TLS < 1.3 and == 1.3
> behave so different, I wonder whether a uniform approach can work.
>
> The httpd web server reused its existing SSLCipherSuite config
> directive, but in effect you can use it like before, which only sets the
> cipher list for TLS < 1.3 or you can use it with the additional token
> "TLS1.3" before the ciphers, which then sets the TLS 1.3 ciphers. And
> you can use it twice, once for the non 1.3 ciphers and once for the 1.3
> ciphers. So httpd makes no attempt to unify those two cases. They are
> configured and handled separately.
>
> Since it might not be clear, which protocol client and server negotiate,
> I am not sure how easy it is to get to a uniform cipher configuration.
> Whether we provide two API methods (< 1.3 and == 1.3) or some syntactic
> cipher list sugar that we can use to split the two intended cases (<1.3
> and == 1.3) from one config string might be a question of style. But I
> think we need a way to express different cipher configurations for < 1.3
> and == 1.3.
>
> Hope that makes sense, but maybe I did not yet fully understand the
> scope of the discussion.
Thanks Rainer, I do understand where you are coming from.
Things aren't quite so clear cut in Tomcat because we need to support
both JSSE and OpenSSL, converting between the two as required.
We can't re-use the httpd trick of defining the directive twice as we
use XML configuration files. We could actually handle calling the setter
twice. It is the getter that would be the issue for the store config code.
JSSE uses a single configuration value for TLS <= 1.2 and TLS >= 1.3
ciphers whereas OpenSSL uses two.
OpenSSL will accept a combined value for both individual configuration
values and just ignore the unrecognised ciphers.
Internally, Tomcat stores ciphers using OpenSSL format and Tomcat has
code to convert between JSSE cipher names and OpenSSL cipher names as
required.
I agree that there are two options.
A. Have two cipher settings, one for TLS <= 1.2 and one for TLS >= 1.3.
Use the separate ones for OpenSSL. Combine them when calling JSSE.
B. Have one cipher setting. Use the single value when calling JSSE and
for OpenSSL call both OpenSSL setters with the same value.
I have been thinking about various use cases, trying to see if one
option works better than the other.
On balance, I think option A is better as with option B there is a
backwards compatibility issue. Currently, if a user explicitly lists
TLS1.2 ciphers, they will get TLS 1.2 ciphers + the TLS 1.3 default
ciphers. With option B this would change to just TLS 1.2 ciphers.
The drawback with option A is that excluding TLS 1.3 ciphers can't be
done with the ciphers attribute. The user would have to use protocols.
I'm going to proceed with option A. If I find any blockers, we can
re-evaluate.
I'm not planning on tagging Tomcat Native until I have a set of local
changes for Tomcat 12.0.x that works with then current Tomcat Native 2.0.x
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.12.25 um 17:17 schrieb Mark Thomas:
> On 18/12/2025 13:28, Mark Thomas wrote:
>> On 18/12/2025 12:58, Rainer Jung wrote:
>>
>>> I was analyzing it using 9.0.113 but I think I also saw it for
>>> 10.1.50. JVM was from various 1.8.0 vendor for TC 9 and at least
>>> adopt 11 for 10.1.50 (I then stopped testing).
>>
>> Bingo. Now I know what is going on.
>>
>> Those versions have a default value of ciphers of:
>> "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
>>
>> That doesn't include the default TLS 1.3 ciphers so when we run a test
>> that uses only TLS 1.3 the new native code fails because no TLS 1.3
>> ciphers are set.
>>
>> I was testing with 9.0.x etc where the default for ciphers is now:
>>
>> "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!
>> kRSA:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
>>
>> We need to figure out how to make this work for older versions.
>>
>> I think we need to be able to differentiate between Tomcat <= 11.0.15,
>> <= 10.1.50 and <= 9.0.113 configuring protocols="TLSv1.3" and the
>> default ciphers that only includes TLSv1.2 ciphers (should use default
>> ciphers for TLSv1.3) and newer versions of Tomcat that configure
>> protocols="TLSv1.3" and an explicit ciphers value without any TLSv1.3
>> ciphers (should fail).
>>
>> I think the only way to do this is with a new Tomcat Native method
>> that sets cipher suites for TLS 1.2 and TLS 1.3. I think that is the
>> only way to distinguish between these scenarios.
>>
>> How about:
>>
>> public static native boolean setCipherSuites(long ctx, String
>> cipherSuites)
>>
>> (note the extra "s" at the end of the method name)
>
> Hmm. We currently have:
>
> SSLContext.setCipherSuite
> and
> SSL.setCipherSuites
>
> so the original name for the new method won't work. How about:
>
> public static native boolean setCipherSuitesEx(long ctx, String
> cipherSuites)
>
> on both SSLContext and SSL
>
> I can also reproduce the "... Tomcat interprets the [ciphers]
> attribute..." warning now as well.
>
> There are a lot of moving parts here and I want to get to the bottom of
> all of the various issues we are seeing and make sure that they are
> resolved - or at least documented and understood - for all the various
> combinations of Tomcat version, OpenSSL version, Java version, Tomcat
> Native version etc.
>
> I think a tag this week is currently looking less likely than I thought
> a few hours ago.
Since the OpenSSL methods for setting ciphers for TLS < 1.3 and == 1.3
behave so different, I wonder whether a uniform approach can work.
The httpd web server reused its existing SSLCipherSuite config
directive, but in effect you can use it like before, which only sets the
cipher list for TLS < 1.3 or you can use it with the additional token
"TLS1.3" before the ciphers, which then sets the TLS 1.3 ciphers. And
you can use it twice, once for the non 1.3 ciphers and once for the 1.3
ciphers. So httpd makes no attempt to unify those two cases. They are
configured and handled separately.
Since it might not be clear, which protocol client and server negotiate,
I am not sure how easy it is to get to a uniform cipher configuration.
Whether we provide two API methods (< 1.3 and == 1.3) or some syntactic
cipher list sugar that we can use to split the two intended cases (<1.3
and == 1.3) from one config string might be a question of style. But I
think we need a way to express different cipher configurations for < 1.3
and == 1.3.
Hope that makes sense, but maybe I did not yet fully understand the
scope of the discussion.
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Mark Thomas <ma...@apache.org>.
On 18/12/2025 13:28, Mark Thomas wrote:
> On 18/12/2025 12:58, Rainer Jung wrote:
>
>> I was analyzing it using 9.0.113 but I think I also saw it for
>> 10.1.50. JVM was from various 1.8.0 vendor for TC 9 and at least adopt
>> 11 for 10.1.50 (I then stopped testing).
>
> Bingo. Now I know what is going on.
>
> Those versions have a default value of ciphers of:
> "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
>
> That doesn't include the default TLS 1.3 ciphers so when we run a test
> that uses only TLS 1.3 the new native code fails because no TLS 1.3
> ciphers are set.
>
> I was testing with 9.0.x etc where the default for ciphers is now:
>
> "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!
> kRSA:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
>
> We need to figure out how to make this work for older versions.
>
> I think we need to be able to differentiate between Tomcat <= 11.0.15,
> <= 10.1.50 and <= 9.0.113 configuring protocols="TLSv1.3" and the
> default ciphers that only includes TLSv1.2 ciphers (should use default
> ciphers for TLSv1.3) and newer versions of Tomcat that configure
> protocols="TLSv1.3" and an explicit ciphers value without any TLSv1.3
> ciphers (should fail).
>
> I think the only way to do this is with a new Tomcat Native method that
> sets cipher suites for TLS 1.2 and TLS 1.3. I think that is the only way
> to distinguish between these scenarios.
>
> How about:
>
> public static native boolean setCipherSuites(long ctx, String cipherSuites)
>
> (note the extra "s" at the end of the method name)
Hmm. We currently have:
SSLContext.setCipherSuite
and
SSL.setCipherSuites
so the original name for the new method won't work. How about:
public static native boolean setCipherSuitesEx(long ctx, String
cipherSuites)
on both SSLContext and SSL
I can also reproduce the "... Tomcat interprets the [ciphers]
attribute..." warning now as well.
There are a lot of moving parts here and I want to get to the bottom of
all of the various issues we are seeing and make sure that they are
resolved - or at least documented and understood - for all the various
combinations of Tomcat version, OpenSSL version, Java version, Tomcat
Native version etc.
I think a tag this week is currently looking less likely than I thought
a few hours ago.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Mark Thomas <ma...@apache.org>.
On 18/12/2025 12:58, Rainer Jung wrote:
> I was analyzing it using 9.0.113 but I think I also saw it for 10.1.50.
> JVM was from various 1.8.0 vendor for TC 9 and at least adopt 11 for
> 10.1.50 (I then stopped testing).
Bingo. Now I know what is going on.
Those versions have a default value of ciphers of:
"HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA"
That doesn't include the default TLS 1.3 ciphers so when we run a test
that uses only TLS 1.3 the new native code fails because no TLS 1.3
ciphers are set.
I was testing with 9.0.x etc where the default for ciphers is now:
"HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"
We need to figure out how to make this work for older versions.
I think we need to be able to differentiate between Tomcat <= 11.0.15,
<= 10.1.50 and <= 9.0.113 configuring protocols="TLSv1.3" and the
default ciphers that only includes TLSv1.2 ciphers (should use default
ciphers for TLSv1.3) and newer versions of Tomcat that configure
protocols="TLSv1.3" and an explicit ciphers value without any TLSv1.3
ciphers (should fail).
I think the only way to do this is with a new Tomcat Native method that
sets cipher suites for TLS 1.2 and TLS 1.3. I think that is the only way
to distinguish between these scenarios.
How about:
public static native boolean setCipherSuites(long ctx, String cipherSuites)
(note the extra "s" at the end of the method name)
with the old method deprecated?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.12.25 um 13:47 schrieb Mark Thomas:
> On 18/12/2025 12:31, Rainer Jung wrote:
>> Am 18.12.25 um 12:18 schrieb Mark Thomas:
>>> On 18/12/2025 01:28, Rainer Jung wrote:
>>>> Am 18.12.25 um 01:26 schrieb Rainer Jung:
>>>> - the error "error:12800067:DSO support routines::could not load the
>>>> shared library" is shown, because "SSL_ERR_clear();" is missing
>>>> somewhere. If I add that in setCipherSuite, the SSL library error
>>>> thrown changes to "error:0A0000B9:SSL routines::no cipher match"
>>>
>>> We should definitely add the call to SSL_ERR_clear()
>>>
>>>> - the error happens in the "if (maxProtoVer >= TLS1_3_VERSION) {"
>>>> branch.
>>>>
>>>> - the CipherSuite used is "!aNULL:!eNULL:!EXP:ALL" and "!aNULL:!
>>>> eNULL:! EXP:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA".
>>>
>>> Where are those coming from? Have you modified the tests / Tomcat to
>>> use different default ciphers?
>>
>> No modification, except for debug output. I think the part "!aNULL:!
>> eNULL:!EXP:" comes from prefixing SSL_CIPHERS_ALWAYS_DISABLED in case
>> of "#ifndef HAVE_EXPORT_CIPHERS" in the tcnative code for
>> setCipherSuite(). I do not know, where the ALL comes from. A couple of
>> classes underneath test/org/apache/tomcat/util/net/ use it, but not
>> obviously related to the falling test.
>
> OK. I am making progress.
>
> "ALL" comes from line 77 of o.a.t.u.n.openssl.OpenSSLEngine and should
> succeed.
>
> I can only trigger a failure if I specify a protocol of TLSv1.3 and then
> list only TLSv1.2 ciphers. Previously, that would have defaulted to
> using the default TLsv1.3 cipher list. Now it fails.
>
> I don't think we can (easily) distinguish between a list of just TLSv1.2
> ciphers and a list of unsupported TLSv1.3 ciphers.
>
> I'm currently leaning towards calling this working as designed.
>
> What I can't figure out is what is triggering the test failures you are
> seeing.
>
> Ah! I have a theory. Which Tomcat version are you using for testing?
I was analyzing it using 9.0.113 but I think I also saw it for 10.1.50.
JVM was from various 1.8.0 vendor for TC 9 and at least adopt 11 for
10.1.50 (I then stopped testing).
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Mark Thomas <ma...@apache.org>.
On 18/12/2025 12:31, Rainer Jung wrote:
> Am 18.12.25 um 12:18 schrieb Mark Thomas:
>> On 18/12/2025 01:28, Rainer Jung wrote:
>>> Am 18.12.25 um 01:26 schrieb Rainer Jung:
>>> - the error "error:12800067:DSO support routines::could not load the
>>> shared library" is shown, because "SSL_ERR_clear();" is missing
>>> somewhere. If I add that in setCipherSuite, the SSL library error
>>> thrown changes to "error:0A0000B9:SSL routines::no cipher match"
>>
>> We should definitely add the call to SSL_ERR_clear()
>>
>>> - the error happens in the "if (maxProtoVer >= TLS1_3_VERSION) {"
>>> branch.
>>>
>>> - the CipherSuite used is "!aNULL:!eNULL:!EXP:ALL" and "!aNULL:!
>>> eNULL:! EXP:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA".
>>
>> Where are those coming from? Have you modified the tests / Tomcat to
>> use different default ciphers?
>
> No modification, except for debug output. I think the part "!aNULL:!
> eNULL:!EXP:" comes from prefixing SSL_CIPHERS_ALWAYS_DISABLED in case of
> "#ifndef HAVE_EXPORT_CIPHERS" in the tcnative code for setCipherSuite().
> I do not know, where the ALL comes from. A couple of classes underneath
> test/org/apache/tomcat/util/net/ use it, but not obviously related to
> the falling test.
OK. I am making progress.
"ALL" comes from line 77 of o.a.t.u.n.openssl.OpenSSLEngine and should
succeed.
I can only trigger a failure if I specify a protocol of TLSv1.3 and then
list only TLSv1.2 ciphers. Previously, that would have defaulted to
using the default TLsv1.3 cipher list. Now it fails.
I don't think we can (easily) distinguish between a list of just TLSv1.2
ciphers and a list of unsupported TLSv1.3 ciphers.
I'm currently leaning towards calling this working as designed.
What I can't figure out is what is triggering the test failures you are
seeing.
Ah! I have a theory. Which Tomcat version are you using for testing?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.12.25 um 12:18 schrieb Mark Thomas:
> On 18/12/2025 01:28, Rainer Jung wrote:
>> Am 18.12.25 um 01:26 schrieb Rainer Jung:
>> - the error "error:12800067:DSO support routines::could not load the
>> shared library" is shown, because "SSL_ERR_clear();" is missing
>> somewhere. If I add that in setCipherSuite, the SSL library error
>> thrown changes to "error:0A0000B9:SSL routines::no cipher match"
>
> We should definitely add the call to SSL_ERR_clear()
>
>> - the error happens in the "if (maxProtoVer >= TLS1_3_VERSION) {" branch.
>>
>> - the CipherSuite used is "!aNULL:!eNULL:!EXP:ALL" and "!aNULL:!
>> eNULL:! EXP:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA".
>
> Where are those coming from? Have you modified the tests / Tomcat to use
> different default ciphers?
No modification, except for debug output. I think the part
"!aNULL:!eNULL:!EXP:" comes from prefixing SSL_CIPHERS_ALWAYS_DISABLED
in case of "#ifndef HAVE_EXPORT_CIPHERS" in the tcnative code for
setCipherSuite(). I do not know, where the ALL comes from. A couple of
classes underneath test/org/apache/tomcat/util/net/ use it, but not
obviously related to the falling test.
The second cipher suite might be an unrelated debug messages from the
same native code triggered by
test/org/apache/tomcat/util/net/openssl/ciphers/TestOpenSSLCipherConfigurationParser.java,
which seems to use "HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5" (and
others). It seems it is not really related to a test failure.
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Mark Thomas <ma...@apache.org>.
On 18/12/2025 01:28, Rainer Jung wrote:
> Am 18.12.25 um 01:26 schrieb Rainer Jung:
<snip/>
>> I ran those unit tests from TC 9.0.113 and 10.1.50 which are TLS based
>> with the new tcnative versions 2.0.11 and 1.3.2. They fail in
>> TestClientCertTls13 for NIO and NIO2 with the following error:
>>
>> Testcase: testClientCertPost[OpenSSL] took 0.104 sec
>> Caused an ERROR
>> Protocol handler initialization failed
<snip/>
> I added some debug lines.
>
> - the error "error:12800067:DSO support routines::could not load the
> shared library" is shown, because "SSL_ERR_clear();" is missing
> somewhere. If I add that in setCipherSuite, the SSL library error thrown
> changes to "error:0A0000B9:SSL routines::no cipher match"
We should definitely add the call to SSL_ERR_clear()
> - the error happens in the "if (maxProtoVer >= TLS1_3_VERSION) {" branch.
>
> - the CipherSuite used is "!aNULL:!eNULL:!EXP:ALL" and "!aNULL:!eNULL:!
> EXP:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA".
Where are those coming from? Have you modified the tests / Tomcat to use
different default ciphers?
> - when using those with "openssl ciphers -ciphersuites" I get the same
> SSL library error on the commandline.
>
> - the code of the openssl commandline binary shows, it is using the same
> call to SSL_CTX_set_ciphersuites() as our code
>
> - the openssl CLI command works, as soon as I use a list of explicit TLS
> 1.3 ciphers. It does not work using group names like ALL or AES.
Hmm. That contradicts the information in
https://github.com/apache/tomcat-native/pull/32 that Rémy tested and
reported no issues.
> I suspect, the implementation of SSL_CTX_set_ciphersuites() might not
> resolve cipher group names.
>
> So it seems our new code is not yet working as expected.
Agreed.
> Therefore I vote -1 for 2.0.11 and 1.3.2.
ACK
I suspect we will need new releases. Fortunately, that should be quite
quick. The slow part is building APR and OpenSSL but I can re-use those
builds and link them to the new Tomcat Native build.
I'd like to create some Tomcat unit tests that trigger these issues
before I try fixing anything. Any hints / pointers or complete tests
appreciated.
In terms of timing, I had hoped to get the Tomcat Native releases out by
the end of this week. That isn't going to happen. My new plan is to be
bale to tag by the end of this week. Given the holiday period, I'm
expecting the release vote to be longer than usual. Worst case, if we
aren't in a position to tag by the end of the week, we'll need to tag in
early January which will push back the Tomcat releases.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.12.25 um 02:28 schrieb Rainer Jung:
> Am 18.12.25 um 01:26 schrieb Rainer Jung:
>> Am 17.12.25 um 20:58 schrieb Mark Thomas:
>>> The key differences in version 2.0.11 compared to 2.0.9 are:
>>>
>>> - The windows binaries in this release have been built with OpenSSL
>>> 3.5.4 and APR 1.7.6
>>>
>>> - OCSP support is included (but not enabled) by default with various
>>> improvements to the OCSP checks
>>>
>>> - Add the ability to configure TLS 1.3 ciphers
>>>
>>> The 2.0.x branch is primarily intended for use with Tomcat 10.1.x
>>> onwards but can be used with earlier versions as long as the APR/
>>> native connector is not used.
>>>
>>> The proposed release artifacts can be found at [1],
>>> and the build was done using tag [2].
>>>
>>> The Apache Tomcat Native 2.0.11 release is
>>> [ ] Stable, go ahead and release
>>> [ ] Broken because of ...
>>
>> I ran those unit tests from TC 9.0.113 and 10.1.50 which are TLS based
>> with the new tcnative versions 2.0.11 and 1.3.2. They fail in
>> TestClientCertTls13 for NIO and NIO2 with the following error:
>>
>> Testcase: testClientCertPost[OpenSSL] took 0.104 sec
>> Caused an ERROR
>> Protocol handler initialization failed
>> org.apache.catalina.LifecycleException: Protocol handler
>> initialization failed
>> at
>> org.apache.catalina.connector.Connector.initInternal(Connector.java:1084)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
>> at
>> org.apache.catalina.core.StandardService.initInternal(StandardService.java:520)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
>> at
>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:984)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
>> at
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:155)
>> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:437)
>> at
>> org.apache.catalina.startup.TomcatBaseTest$TomcatWithFastSessionIDs.start(TomcatBaseTest.java:902)
>> at
>> org.apache.tomcat.util.net.TestClientCertTls13.testClientCertPost(TestClientCertTls13.java:93)
>> Caused by: java.lang.IllegalArgumentException: Error creating SSLContext
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:78)
>> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:256)
>> at
>> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1497)
>> at
>> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1510)
>> at
>> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:667)
>> at
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80)
>> at
>> org.apache.catalina.connector.Connector.initInternal(Connector.java:1082)
>> Caused by: java.security.KeyManagementException: Error initializing
>> SSL context
>> at
>> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:447)
>> at
>> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:262)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
>> Caused by: java.lang.Exception: Unable to configure permitted SSL
>> ciphers (error:12800067:DSO support routines::could not load the
>> shared library)
>> at org.apache.tomcat.jni.SSLContext.setCipherSuite(Native Method)
>> at
>> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:332)
>>
>> Testcase: testClientCertGet[OpenSSL] took 0.033 sec
>> Caused an ERROR
>> Protocol handler initialization failed
>> org.apache.catalina.LifecycleException: Protocol handler
>> initialization failed
>> at
>> org.apache.catalina.connector.Connector.initInternal(Connector.java:1084)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
>> at
>> org.apache.catalina.core.StandardService.initInternal(StandardService.java:520)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
>> at
>> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:984)
>> at
>> org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
>> at
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:155)
>> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:437)
>> at
>> org.apache.catalina.startup.TomcatBaseTest$TomcatWithFastSessionIDs.start(TomcatBaseTest.java:902)
>> at
>> org.apache.tomcat.util.net.TestClientCertTls13.testClientCertGet(TestClientCertTls13.java:81)
>> Caused by: java.lang.IllegalArgumentException: Error creating SSLContext
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:78)
>> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:256)
>> at
>> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1497)
>> at
>> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1510)
>> at
>> org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:667)
>> at
>> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80)
>> at
>> org.apache.catalina.connector.Connector.initInternal(Connector.java:1082)
>> Caused by: java.security.KeyManagementException: Error initializing
>> SSL context
>> at
>> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:447)
>> at
>> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:262)
>> at
>> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
>> Caused by: java.lang.Exception: Unable to configure permitted SSL
>> ciphers (error:12800067:DSO support routines::could not load the
>> shared library)
>> at org.apache.tomcat.jni.SSLContext.setCipherSuite(Native Method)
>> at
>> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:332)
>>
>>
>> Although this looks like an integration issue on my side ("could not
>> load the shared library") the same tests using the same scripts dot
>> not fail for 2.0.9 and for 1.3.1. And other TLS based tests do not
>> fail for the new tcnative versions, only those. Since the tcnative
>> code in sslcontext.c changed in setCipherSuite() it is likely a
>> failure caused by the change.
>>
>> Can anyone reproduce this?
>
> I added some debug lines.
>
> - the error "error:12800067:DSO support routines::could not load the
> shared library" is shown, because "SSL_ERR_clear();" is missing
> somewhere. If I add that in setCipherSuite, the SSL library error thrown
> changes to "error:0A0000B9:SSL routines::no cipher match"
>
> - the error happens in the "if (maxProtoVer >= TLS1_3_VERSION) {" branch.
>
> - the CipherSuite used is "!aNULL:!eNULL:!EXP:ALL" and "!aNULL:!eNULL:!
> EXP:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA".
>
> - when using those with "openssl ciphers -ciphersuites" I get the same
> SSL library error on the commandline.
>
> - the code of the openssl commandline binary shows, it is using the same
> call to SSL_CTX_set_ciphersuites() as our code
>
> - the openssl CLI command works, as soon as I use a list of explicit TLS
> 1.3 ciphers. It does not work using group names like ALL or AES.
>
> I suspect, the implementation of SSL_CTX_set_ciphersuites() might not
> resolve cipher group names.
Aha, from the OpenSSL docs:
SSL_CTX_set_ciphersuites() is used to configure the available TLSv1.3
ciphersuites for ctx. This is a simple colon (":") separated list of
TLSv1.3 ciphersuite names in order of preference. Valid TLSv1.3
ciphersuite names are:
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_SHA384_SHA384 - integrity-only
TLS_SHA256_SHA256 - integrity-only
So no mention of using group names like "ALL". Looking at the OpenSSL
impl of SSL_CTX_set_ciphersuites() versus SSL_CTX_set_cipher_list(), I
have the impression, the latter calls code (ssl_create_cipher_list())
which seems to handle group aliases like "ALL".
> So it seems our new code is not yet working as expected.
>
> Therefore I vote -1 for 2.0.11 and 1.3.2.
>
> Best regards,
>
> Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Rainer Jung <ra...@kippdata.de>.
Am 18.12.25 um 01:26 schrieb Rainer Jung:
> Am 17.12.25 um 20:58 schrieb Mark Thomas:
>> The key differences in version 2.0.11 compared to 2.0.9 are:
>>
>> - The windows binaries in this release have been built with OpenSSL
>> 3.5.4 and APR 1.7.6
>>
>> - OCSP support is included (but not enabled) by default with various
>> improvements to the OCSP checks
>>
>> - Add the ability to configure TLS 1.3 ciphers
>>
>> The 2.0.x branch is primarily intended for use with Tomcat 10.1.x
>> onwards but can be used with earlier versions as long as the APR/
>> native connector is not used.
>>
>> The proposed release artifacts can be found at [1],
>> and the build was done using tag [2].
>>
>> The Apache Tomcat Native 2.0.11 release is
>> [ ] Stable, go ahead and release
>> [ ] Broken because of ...
>
> I ran those unit tests from TC 9.0.113 and 10.1.50 which are TLS based
> with the new tcnative versions 2.0.11 and 1.3.2. They fail in
> TestClientCertTls13 for NIO and NIO2 with the following error:
>
> Testcase: testClientCertPost[OpenSSL] took 0.104 sec
> Caused an ERROR
> Protocol handler initialization failed
> org.apache.catalina.LifecycleException: Protocol handler initialization
> failed
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1084)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:520)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:984)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:155)
> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:437)
> at
> org.apache.catalina.startup.TomcatBaseTest$TomcatWithFastSessionIDs.start(TomcatBaseTest.java:902)
> at
> org.apache.tomcat.util.net.TestClientCertTls13.testClientCertPost(TestClientCertTls13.java:93)
> Caused by: java.lang.IllegalArgumentException: Error creating SSLContext
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:78)
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:256)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1497)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1510)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:667)
> at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80)
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1082)
> Caused by: java.security.KeyManagementException: Error initializing SSL
> context
> at
> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:447)
> at
> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:262)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
> Caused by: java.lang.Exception: Unable to configure permitted SSL
> ciphers (error:12800067:DSO support routines::could not load the shared
> library)
> at org.apache.tomcat.jni.SSLContext.setCipherSuite(Native Method)
> at
> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:332)
>
> Testcase: testClientCertGet[OpenSSL] took 0.033 sec
> Caused an ERROR
> Protocol handler initialization failed
> org.apache.catalina.LifecycleException: Protocol handler initialization
> failed
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1084)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:520)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:984)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:155)
> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:437)
> at
> org.apache.catalina.startup.TomcatBaseTest$TomcatWithFastSessionIDs.start(TomcatBaseTest.java:902)
> at
> org.apache.tomcat.util.net.TestClientCertTls13.testClientCertGet(TestClientCertTls13.java:81)
> Caused by: java.lang.IllegalArgumentException: Error creating SSLContext
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:78)
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:256)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1497)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1510)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:667)
> at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80)
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1082)
> Caused by: java.security.KeyManagementException: Error initializing SSL
> context
> at
> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:447)
> at
> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:262)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
> Caused by: java.lang.Exception: Unable to configure permitted SSL
> ciphers (error:12800067:DSO support routines::could not load the shared
> library)
> at org.apache.tomcat.jni.SSLContext.setCipherSuite(Native Method)
> at
> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:332)
>
>
> Although this looks like an integration issue on my side ("could not
> load the shared library") the same tests using the same scripts dot not
> fail for 2.0.9 and for 1.3.1. And other TLS based tests do not fail for
> the new tcnative versions, only those. Since the tcnative code in
> sslcontext.c changed in setCipherSuite() it is likely a failure caused
> by the change.
>
> Can anyone reproduce this?
I added some debug lines.
- the error "error:12800067:DSO support routines::could not load the
shared library" is shown, because "SSL_ERR_clear();" is missing
somewhere. If I add that in setCipherSuite, the SSL library error thrown
changes to "error:0A0000B9:SSL routines::no cipher match"
- the error happens in the "if (maxProtoVer >= TLS1_3_VERSION) {" branch.
- the CipherSuite used is "!aNULL:!eNULL:!EXP:ALL" and
"!aNULL:!eNULL:!EXP:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!kRSA".
- when using those with "openssl ciphers -ciphersuites" I get the same
SSL library error on the commandline.
- the code of the openssl commandline binary shows, it is using the same
call to SSL_CTX_set_ciphersuites() as our code
- the openssl CLI command works, as soon as I use a list of explicit TLS
1.3 ciphers. It does not work using group names like ALL or AES.
I suspect, the implementation of SSL_CTX_set_ciphersuites() might not
resolve cipher group names.
So it seems our new code is not yet working as expected.
Therefore I vote -1 for 2.0.11 and 1.3.2.
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Mark Thomas <ma...@apache.org>.
On 18/12/2025 09:04, Rémy Maucherat wrote:
<snip/>
> However, I always get "WARNING [main]
> org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets
> the [ciphers] attribute" in the logs with the new changes, as the
> default cipher list is a concat of TLS 1.2 and TLS 1.3 ciphers, so
> it's never going to be able to enable everything ...
> Maybe (as I was doing in the FFM code before) we should disable the
> warning if the cipher suite has not been configured from its default
> value ?
I'm not seeing this. Which test reports this error? OS, OpenSSL versions?
I'd like to try and get a unit test set up for this too.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Dec 18, 2025 at 1:27 AM Rainer Jung <ra...@kippdata.de> wrote:
>
> Am 17.12.25 um 20:58 schrieb Mark Thomas:
> > The key differences in version 2.0.11 compared to 2.0.9 are:
> >
> > - The windows binaries in this release have been built with OpenSSL
> > 3.5.4 and APR 1.7.6
> >
> > - OCSP support is included (but not enabled) by default with various
> > improvements to the OCSP checks
> >
> > - Add the ability to configure TLS 1.3 ciphers
> >
> > The 2.0.x branch is primarily intended for use with Tomcat 10.1.x
> > onwards but can be used with earlier versions as long as the APR/native
> > connector is not used.
> >
> > The proposed release artifacts can be found at [1],
> > and the build was done using tag [2].
> >
> > The Apache Tomcat Native 2.0.11 release is
> > [ ] Stable, go ahead and release
> > [ ] Broken because of ...
>
> I ran those unit tests from TC 9.0.113 and 10.1.50 which are TLS based
> with the new tcnative versions 2.0.11 and 1.3.2. They fail in
> TestClientCertTls13 for NIO and NIO2 with the following error:
>
> Testcase: testClientCertPost[OpenSSL] took 0.104 sec
> Caused an ERROR
> Protocol handler initialization failed
> org.apache.catalina.LifecycleException: Protocol handler initialization
> failed
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1084)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:520)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:984)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:155)
> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:437)
> at
> org.apache.catalina.startup.TomcatBaseTest$TomcatWithFastSessionIDs.start(TomcatBaseTest.java:902)
> at
> org.apache.tomcat.util.net.TestClientCertTls13.testClientCertPost(TestClientCertTls13.java:93)
> Caused by: java.lang.IllegalArgumentException: Error creating SSLContext
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:78)
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:256)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1497)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1510)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:667)
> at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80)
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1082)
> Caused by: java.security.KeyManagementException: Error initializing SSL
> context
> at
> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:447)
> at
> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:262)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
> Caused by: java.lang.Exception: Unable to configure permitted SSL
> ciphers (error:12800067:DSO support routines::could not load the shared
> library)
> at org.apache.tomcat.jni.SSLContext.setCipherSuite(Native Method)
> at
> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:332)
>
> Testcase: testClientCertGet[OpenSSL] took 0.033 sec
> Caused an ERROR
> Protocol handler initialization failed
> org.apache.catalina.LifecycleException: Protocol handler initialization
> failed
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1084)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.core.StandardService.initInternal(StandardService.java:520)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at
> org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:984)
> at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:155)
> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:437)
> at
> org.apache.catalina.startup.TomcatBaseTest$TomcatWithFastSessionIDs.start(TomcatBaseTest.java:902)
> at
> org.apache.tomcat.util.net.TestClientCertTls13.testClientCertGet(TestClientCertTls13.java:81)
> Caused by: java.lang.IllegalArgumentException: Error creating SSLContext
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:78)
> at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:256)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1497)
> at
> org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1510)
> at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:667)
> at
> org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80)
> at
> org.apache.catalina.connector.Connector.initInternal(Connector.java:1082)
> Caused by: java.security.KeyManagementException: Error initializing SSL
> context
> at
> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:447)
> at
> org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:262)
> at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
> Caused by: java.lang.Exception: Unable to configure permitted SSL
> ciphers (error:12800067:DSO support routines::could not load the shared
> library)
> at org.apache.tomcat.jni.SSLContext.setCipherSuite(Native Method)
> at
> org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:332)
>
>
> Although this looks like an integration issue on my side ("could not
> load the shared library") the same tests using the same scripts dot not
> fail for 2.0.9 and for 1.3.1. And other TLS based tests do not fail for
> the new tcnative versions, only those. Since the tcnative code in
> sslcontext.c changed in setCipherSuite() it is likely a failure caused
> by the change.
>
> Can anyone reproduce this?
I'm not getting this error.
However, I always get "WARNING [main]
org.apache.tomcat.util.net.SSLUtilBase.getEnabled Tomcat interprets
the [ciphers] attribute" in the logs with the new changes, as the
default cipher list is a concat of TLS 1.2 and TLS 1.3 ciphers, so
it's never going to be able to enable everything ...
Maybe (as I was doing in the FFM code before) we should disable the
warning if the cipher suite has not been configured from its default
value ?
Rémy
> Best regards,
>
> Rainer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Rainer Jung <ra...@kippdata.de>.
Am 17.12.25 um 20:58 schrieb Mark Thomas:
> The key differences in version 2.0.11 compared to 2.0.9 are:
>
> - The windows binaries in this release have been built with OpenSSL
> 3.5.4 and APR 1.7.6
>
> - OCSP support is included (but not enabled) by default with various
> improvements to the OCSP checks
>
> - Add the ability to configure TLS 1.3 ciphers
>
> The 2.0.x branch is primarily intended for use with Tomcat 10.1.x
> onwards but can be used with earlier versions as long as the APR/native
> connector is not used.
>
> The proposed release artifacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 2.0.11 release is
> [ ] Stable, go ahead and release
> [ ] Broken because of ...
I ran those unit tests from TC 9.0.113 and 10.1.50 which are TLS based
with the new tcnative versions 2.0.11 and 1.3.2. They fail in
TestClientCertTls13 for NIO and NIO2 with the following error:
Testcase: testClientCertPost[OpenSSL] took 0.104 sec
Caused an ERROR
Protocol handler initialization failed
org.apache.catalina.LifecycleException: Protocol handler initialization
failed
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1084)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:520)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:984)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:155)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:437)
at
org.apache.catalina.startup.TomcatBaseTest$TomcatWithFastSessionIDs.start(TomcatBaseTest.java:902)
at
org.apache.tomcat.util.net.TestClientCertTls13.testClientCertPost(TestClientCertTls13.java:93)
Caused by: java.lang.IllegalArgumentException: Error creating SSLContext
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:78)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:256)
at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1497)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1510)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:667)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1082)
Caused by: java.security.KeyManagementException: Error initializing SSL
context
at
org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:447)
at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:262)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
Caused by: java.lang.Exception: Unable to configure permitted SSL
ciphers (error:12800067:DSO support routines::could not load the shared
library)
at org.apache.tomcat.jni.SSLContext.setCipherSuite(Native Method)
at
org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:332)
Testcase: testClientCertGet[OpenSSL] took 0.033 sec
Caused an ERROR
Protocol handler initialization failed
org.apache.catalina.LifecycleException: Protocol handler initialization
failed
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1084)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
at
org.apache.catalina.core.StandardService.initInternal(StandardService.java:520)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
at
org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:984)
at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:122)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:155)
at org.apache.catalina.startup.Tomcat.start(Tomcat.java:437)
at
org.apache.catalina.startup.TomcatBaseTest$TomcatWithFastSessionIDs.start(TomcatBaseTest.java:902)
at
org.apache.tomcat.util.net.TestClientCertTls13.testClientCertGet(TestClientCertTls13.java:81)
Caused by: java.lang.IllegalArgumentException: Error creating SSLContext
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:115)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:78)
at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:256)
at
org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEndpoint.java:1497)
at
org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1510)
at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:667)
at
org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80)
at
org.apache.catalina.connector.Connector.initInternal(Connector.java:1082)
Caused by: java.security.KeyManagementException: Error initializing SSL
context
at
org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:447)
at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java:262)
at
org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:113)
Caused by: java.lang.Exception: Unable to configure permitted SSL
ciphers (error:12800067:DSO support routines::could not load the shared
library)
at org.apache.tomcat.jni.SSLContext.setCipherSuite(Native Method)
at
org.apache.tomcat.util.net.openssl.OpenSSLContext.init(OpenSSLContext.java:332)
Although this looks like an integration issue on my side ("could not
load the shared library") the same tests using the same scripts dot not
fail for 2.0.9 and for 1.3.1. And other TLS based tests do not fail for
the new tcnative versions, only those. Since the tcnative code in
sslcontext.c changed in setCipherSuite() it is likely a failure caused
by the change.
Can anyone reproduce this?
Best regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [VOTE] Release Apache Tomcat Native 2.0.11
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Mark,
On 12/17/25 2:58 PM, Mark Thomas wrote:
> The key differences in version 2.0.11 compared to 2.0.9 are:
>
> - The windows binaries in this release have been built with OpenSSL
> 3.5.4 and APR 1.7.6
>
> - OCSP support is included (but not enabled) by default with various
> improvements to the OCSP checks
>
> - Add the ability to configure TLS 1.3 ciphers
>
> The 2.0.x branch is primarily intended for use with Tomcat 10.1.x
> onwards but can be used with earlier versions as long as the APR/native
> connector is not used.
>
> The proposed release artifacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 2.0.11 release is
> [ ] Stable, go ahead and release
> [ ] Broken because of ...
+1 for stable release
Build cleanly with deprecation warnings on MacOS aarch64 using clang and
the Tomcat 11 unit tests pass.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[VOTE][CANCELLED] Release Apache Tomcat Native 2.0.11
Posted by Mark Thomas <ma...@apache.org>.
Formally cancelling this vote.
Mark
On 17/12/2025 19:58, Mark Thomas wrote:
> The key differences in version 2.0.11 compared to 2.0.9 are:
>
> - The windows binaries in this release have been built with OpenSSL
> 3.5.4 and APR 1.7.6
>
> - OCSP support is included (but not enabled) by default with various
> improvements to the OCSP checks
>
> - Add the ability to configure TLS 1.3 ciphers
>
> The 2.0.x branch is primarily intended for use with Tomcat 10.1.x
> onwards but can be used with earlier versions as long as the APR/native
> connector is not used.
>
> The proposed release artifacts can be found at [1],
> and the build was done using tag [2].
>
> The Apache Tomcat Native 2.0.11 release is
> [ ] Stable, go ahead and release
> [ ] Broken because of ...
>
> Thanks,
>
> Mark
>
>
> [1]
> https://dist.apache.org/repos/dist/dev/tomcat/tomcat-connectors/
> native/2.0.11
> [2] https://github.com/apache/tomcat-native/commit/
> ea9ce74ebcf67f5e74ec9a704e7c53dff276169b
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org