Hi Tomcat Support Team,
We are experiencing an issue with cipher suite configuration in Apache Tomcat
where explicitly configured cipher suites in server.xml are being filtered,
despite our expectation that explicit configuration
should override any default filtering behavior.
Environment Details:
* Apache Tomcat version: 11.X
* Java version: OpenJDK - 17
* Operating System: Linux
Issue Description:
After configuring our Tomcat connector with explicit cipher suites in
server.xml and restarting the Tomcat process, we observe a discrepancy between
the cipher suites available on our Java RMI port (2022)
versus our Tomcat HTTPS port (2309). The Java RMI port shows all configured
cipher suites, while the Tomcat port appears to be filtering out certain cipher
suites, specifically the TLS_RSA_* variants.
Current Configuration:
xml
<Connector protocol="org.apache.coyote.http11.Http11Nio2Protocol" port="2309"
maxThreads="200" scheme="https" secure="true" SSLEnabled="true"
maxHttpHeaderSize="8192" server="oamServer" xpoweredBy="false"
allowTrace="false" connectionTimeout="60000" address="X.X.X.X">
<SSLHostConfig certificateVerification="optional">
<Certificate certificateKeystoreFile="/opt/occ/etc/cert/.oam/keystore"
certificateKeystorePassword="XXXXXXXXXXX" />
<SSLHostConfig
ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA"
sslProtocol="TLSv1.2+TLSv1.3"/>
</SSLHostConfig>
</Connector>
Observed Behavior:
* **Port 2309 (Tomcat HTTPS):** Only shows ECDHE cipher suites, missing all
TLS_RSA_* variants
* **Port 2022 (Java RMI):** Shows all configured cipher suites including
TLS_RSA_* variants
Questions:
1. Is there an internal security policy or default configuration in Tomcat that
automatically filters out certain cipher suites (particularly TLS_RSA_*
variants) even when explicitly configured?
2. What mechanism is causing this filtering behaviour, and how can it be
disabled or overridden?
3. Is this filtering behaviour documented, and if so, where can we find the
complete list of filtered cipher suites?
4. How can we ensure that our explicit cipher suite configuration in server.xml
is fully honoured without any automatic filtering?
Expected Behaviour:
When cipher suites are explicitly configured in server.xml, we expect Tomcat to
honour the complete list without applying any additional filtering. The
configuration should take precedence over any default
security policies.
Request:
Please provide guidance on how to configure Tomcat to use the exact cipher
suite list specified in our configuration, or explain the rationale behind the
current filtering behaviour and how to work around it.
We appreciate your assistance in resolving this configuration issue.
Regards,
Abirami.S
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
Sent: Saturday, August 23, 2025 10:06 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 11 and JDK 17 application ciphers difference
Abirami,
On 8/22/25 2:53 AM, S Abirami wrote:
> I have a follow-up question on the below concern with SSL/TLS cipher
> configuration in our Tomcat deployment and need your assistance.
>
> Issue Description:
>
> We have explicitly configured a specific set of ciphers in our
> server.xml connector configuration, but the configuration appears to be
> ignored. Additionally, we are seeing RSA key exchange ciphers in our SSL
> handshake that we did not include in our cipher list.
>
> Environment Details:
>
> * Tomcat Version: 11.xx
> * Java Version: OpenJDK 17
> * Operating System: Linux
>
> Configuration:
>
> xml
> <Connector protocol="com.ericsson.http.protocol.Http11Nio2ProtocolDecryptProp"
> port="2309"
> maxThreads="200"
> scheme="https"
> secure="true"
> SSLEnabled="true"
> honorCipherOrder="true"
> sslProtocol="TLSv1.2+TLSv1.3"
>
> ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_CHAC
> HA20_POLY1305_SHA256,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_R
> SA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_E
> CDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_R
> SA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WIT
> H_AES_256_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_
> 256_CBC_SHA,TLS_RSA_WITH_AES_128_CBC_SHA" />
>
> Here the particular RSA key exchange ciphers are supported in JAVA. But not
> coming in the nmap command output even if we mention those ciphers in
> server.xml.
> Questions:
>
> 1. Why are the cipher configuration properties not being recognized in the
> connector configuration?
> 2. Are there any Tomcat security policies that override explicit cipher
> configurations in server.xml?
No, but there are JVM security policies which can disable the use of certain
algorithms, key sizes, etc.
> 3. If there are security configurations that disable certain cipher suites
> (particularly RSA key exchange ciphers), could you please provide:
> * The specific configuration files or properties involved
> * Documentation on how these security policies work
> * Methods to override or customize these policies if needed
>
> 4. What is the correct way to explicitly control cipher suites in Tomcat to
> ensure only our specified ciphers are available.
Can you please use this tool running on the same machine (e.g. run it on
localhost : port) using the same JVM you use for Tomcat, and post the output
back to the list?
https://github.com/ChristopherSchultz/ssltest
Please run:
$ java -jar ssltest.jar -client-info
and
$ java -jar ssltest.jar localhost[:port]
The first command will tell you what ciphers exist and which are enabled by
default at the JVM level. This is helpful to discover if you are trying to use
an algorithm, etc. that is not supported by the JVM itself.
The second will tell you which ones you are able to use to connect to your
running server.
-chris
> -----Original Message-----
> From: Mark Thomas <ma...@apache.org>
> Sent: Tuesday, August 19, 2025 5:30 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Tomcat 11 and JDK 17 application ciphers difference
>
> On 19/08/2025 12:17, S Abirami wrote:
>
> <snip/>
>
> > Questions:>
>> 1. Is Tomcat 11 intentionally filtering out RSA key exchange cipher suites
>> by default? If so, where is this documented?
>
> Yes.
> https://tomc/
> at.apache.org%2Ftomcat-11.0-doc%2Fconfig%2Fhttp.html&data=05%7C02%7Cs.
> abirami%40ericsson.com%7C8651f7781ba84997e93b08dde26323f3%7C92e84cebfb
> fd47abbe52080c6b87953f%7C0%7C0%7C638915637615612952%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO
> IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=YQ3Qn5DnX%2BumyYIswKKW
> azYKzJSUO2jCfAXR3tS0JwI%3D&reserved=0
> look for the "ciphers" attribute
>
>> 2. What is the mechanism for this filtering? Is it hardcoded in the SSL
>> implementation or configurable?
>
> https://tomc/
> at.apache.org%2Ftomcat-11.0-doc%2Fconfig%2Fhttp.html&data=05%7C02%7Cs.
> abirami%40ericsson.com%7C8651f7781ba84997e93b08dde26323f3%7C92e84cebfb
> fd47abbe52080c6b87953f%7C0%7C0%7C638915637615622326%7CUnknown%7CTWFpbG
> Zsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFO
> IjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=BK%2BBwHcQ4TmcnHR0EnQZ
> FwMMO%2Fn3GE2%2B0BqTJkfi2g4%3D&reserved=0
> look for the "ciphers" attribute
>
>> 3. Is there a system property or configuration option to disable Tomcat's
>> cipher filtering and use Java's default cipher suite selection?
>
> No.
>
> You could set the ciphers attribute to be the same as the Java default (quite
> a long list) but there is no setting for "use whatever the Java default is".
>
>> Expected Behaviour:
>> When no explicit cipher configuration is provided, I would expect Tomcat to
>> use the same cipher suites that are available to other Java applications
>> using the same JVM and security configuration.
>
> The assumption that the security configuration is the same is flawed because
> Tomcat has explicit defaults rather than simply using the JVM defaults.
>
>
> Tomcat has the defaults it has so that swapping between the JSSE and the
> OpenSSL based TLS implementations has minimal impact on behaviour.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
