Tomcat’s TLS Cipher Change and What it Means for Spring Boot Apps

A recent Tomcat update changed how TLS cipher suites are configured, affecting Spring Boot's integration for anyone who explicitly sets TLSv1.3 ciphers. We caught it during our regular testing cycle and have shipped a fix across all NES Spring Boot versions. 

Here's what happened, and how you can check if you're affected.

‍

Our Process

At HeroDevs, we maintain Never-Ending Support (NES) releases for Spring Boot and other open-source frameworks that have reached the end of their community support lifecycle. This includes Spring Boot 2.7, 3.2, 3.3, and 3.4.

Part of that commitment means we don't just apply patches. We perform monthly dependency upgrades across our NES Spring Boot releases. When a new version of Tomcat, Netty, Hibernate, or any other transitive dependency is released, we pull it in, rebuild, and run the full test suite.

This is how we keep NES releases current with security fixes and bug fixes from the broader ecosystem.

To do this at scale across multiple Spring Boot lines, each with its own dependency matrix, we rely heavily on automated testing pipelines. Every upgrade goes through integration tests that exercise extensive real application behavior, not just unit-level checks. We run actual Spring Boot apps with TLS enabled, perform cipher negotiations etc, and verify that what's configured is what's offered.

‍

How We Discovered This Issue

During a routine monthly upgrade of Tomcat to 9.0.115 (for NES Spring Boot 2.7) and 10.1.52 (for NES Spring Boot 3.2–3.4), our integration tests failed. Specifically, tests that verify TLSv1.3 cipher enforcement started failing.

The failures flagged that servers configured with an explicit set of TLSv1.3 ciphers were suddenly offering ciphers that should not have been available. 

That prompted investigation, which led us to the root cause: a breaking change in Tomcat that splits TLS cipher configuration into two separate attributes and silently discards TLSv1.3 ciphers from the old one.

We traced the upstream fix in Spring Boot's OSS releases (3.5.11 and 4.0.3) and backported it to all relevant NES Spring Boot versions. The fix was included in our next release cycle with no action required from our customers. Both server.ssl.ciphers and SSL Bundle options.ciphers work correctly again.

The takeaway here goes beyond this specific bug. 

It's a reminder of the value of integration-level testing, something the Spring Boot project does really well. The Boot test suite doesn't just check that things compile or that the app starts; it exercises real behavior like TLS handshakes with restricted cipher sets. We adopt those integration tests as part of our own validation process, and in this case, that rigor is exactly what surfaced the issue.

‍

Are You Affected?

You may be impacted if your Spring Boot application:

‍

1. Uses embedded Tomcat (the default for Spring MVC apps)
2. Runs on Tomcat 9.0.115+, 10.1.52+, or 11.0.18+
3. Using EOL versions of Spring Boot 2.x, 3.x or OSS versions without the fix (starting at 3.5.11 and 4.0.3)
4. Explicitly configures TLSv1.3 cipher suites, either via server.ssl.ciphers or via options.ciphers in an SSL Bundle applied to the connection with server.ssl.bundle

‍

Note: See details on the fixed versions of NES for Spring Boot in our release notes.

‍

If you don't explicitly configure cipher suites, the Tomcat defaults apply in both cases, and you are probably not affected. However it’s still worth checking just-in-case and it’s straightforward to examine your running servers.

‍

How to Check Your Running Server(s)

‍

If your application is already running, you can use nmap to enumerate every cipher the server is willing to negotiate:

nmap --script ssl-enum-ciphers -p 8443 localhost

‍

Compare the output against your application.yml. If you see ciphers you didn't configure, your restrictions are not being enforced.

‍

Note: Spring Boot 3.4.13 (the final OSS release) ships with Tomcat 10.1.50, which predates the breaking change. The issue will surface when 3.4.x users independently upgrade Tomcat to 10.1.52+ without also having the Spring Boot-side cipher fix.

Learn More

For the full technical deep-dive on what Tomcat changed, why it breaks Spring Boot's cipher configuration, and how the fix works, read our companion article on FooJay,

Silent Cipher Downgrade: How a Tomcat Update Could Weaken Your TLS Configuration.