Apache Tomcat 11.0: What's New, Release History & Support Lifecycle

What Jakarta EE 11 specifications does Apache Tomcat 11.0 implement?

Apache Tomcat 11.0 is the first Tomcat branch to implement the full Jakarta EE 11 platform specification set. This is the primary reason most teams will consider upgrading -- it brings the latest standardised API versions across every major Jakarta component:

• Servlet 6.1 -- clarified null/empty-string header behaviour, checked exceptions now permitted from request parameter processing methods
• Jakarta Pages (JSP) 4.0 -- updated JSP specification aligned with the new Servlet 6.1 APIs
• Expression Language (EL) 6.0 -- incremental improvements and technical debt reduction
• WebSocket 2.2 -- updated client API and specification clarifications
• Authentication (JASPIC) 3.1 -- aligned with Jakarta Security developments
• Annotations 3.0 -- minor specification updates

In practice, the jump from Tomcat 10.1 to 11.0 is an incremental one at the specification level -- the big migration pain point already happened with the javax.* to jakarta.* rename that started in Tomcat 10.0. If you are already on Tomcat 10.1 and your application uses jakarta.* imports, moving to 11.0 will be far less disruptive than that earlier transition. The Tomcat Migration Tool for Jakarta EE (bundled and updated throughout the 11.0.x series) is still available to help with any remaining javax.* references.

Watch out for one hard breaking change introduced with this generation: SecurityManager support has been completely removed. The SecurityManager was deprecated in Java 17 and removed from the Jakarta EE 11 specification. If your deployment relies on a configured SecurityManager in Tomcat's startup scripts, those configurations will no longer function.

What TLS and SSL configuration changes were made in Apache Tomcat 11.0?

The TLS configuration model received more attention across the 11.0.x series than any other single area, with multiple additions and several behaviour fixes that directly affect production environments.

The most significant structural change is the introduction of a dedicated cipherSuites attribute on SSLHostConfig specifically for TLS 1.3 cipher suites. Previously, mixing TLS 1.2 ciphers and TLS 1.3 cipher suites in the single ciphers attribute produced inconsistent results depending on whether you used JSSE or OpenSSL -- OpenSSL silently ignored TLS 1.3 entries in that attribute, while JSSE applied them. This inconsistency is now resolved: TLS 1.3 entries placed in ciphers are always ignored and a warning is logged. As a transitional aid in 11.0.x, those entries are automatically moved into cipherSuites, but this migration behaviour will be removed in Tomcat 12.0.x. Update your connector configuration proactively:

<SSLHostConfig
    ciphers="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256"
    cipherSuites="TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256">
  <Certificate certificateKeystoreFile="conf/keystore.jks"
               type="RSA" />
</SSLHostConfig>

OCSP is now supported for JSSE-based TLS connectors, not just OpenSSL-based ones. OCSP can be enabled per-connector for both implementations, with configurable soft-failure behaviour (disabled by default). A size limit for OCSP responses was also added to defend against oversized payloads.

The strictSni attribute on the Connector (added in 11.0.15, default true) ensures the SSLHostConfig matched via the SNI host name is consistent with the one matched via the HTTP protocol host name -- mismatches result in a rejected request. Most teams should leave this at the default; only lower it if you have unusual multi-domain configurations where SNI and Host headers legitimately diverge.

Several legacy cipher aliases -- SSLv3, EXPORT, EXPORT40, EXPORT56, KRB5, kFZA, aFZA, eFZA, FZA -- are no longer accepted in the ciphers attribute, tracking OpenSSL's own removal of these insecure options. Review your SSLHostConfig elements before upgrading.

How has HTTP/2 handling been improved and hardened in Apache Tomcat 11.0?

HTTP/2 correctness and robustness received sustained investment across the 11.0.x point releases, with fixes ranging from subtle protocol compliance gaps to outright crash-level bugs.

The most production-impactful fix was a potential integer overflow when allocating capacity from a connection-level window update to individual streams. Under high concurrency with large HTTP/2 flows, this could cause silent stream starvation or unexpected connection behaviour. This was fixed in 11.0.22.

The following HTTP/2 improvements accumulated across the branch:

• HPACK header field validation now runs earlier in the pipeline and checks for disallowed characters in addition to upper-case characters
• HPACK encoding refactored so header names are lower-cased only once per encoding pass (performance improvement under high request rates)
• Edge-case HPACK decoding bug fixed that could cause a valid header to trigger an unexpected connection close
• The :scheme pseudo-header is now validated for consistency with TLS usage
• Pseudo-header and CONNECT request validation aligned with RFC 9113 section 8.5
• HTTP/2 trailer fields are now aligned with HTTP/1.1 rules and disallowed fields are filtered out
• HTTP/2 request header read buffer is fully reset (including size restoration) after a stream reset
• A drainTimeout attribute was added to the HTTP/2 UpgradeProtocol element, letting operators control the delay between the two final GOAWAY frames sent during graceful shutdown
• Invalid HTTP/2 requests now receive a stream reset or 400 response rather than a full connection reset wherever the spec allows it, reducing disruption to other active streams

A NIO+TLS non-blocking flush bug (fixed in 11.0.21) was also significant in practice -- under certain load conditions, responses were not fully written until the connection was closed, which could manifest as truncated responses in clients that reused the connection.

What security and authentication improvements were made in Apache Tomcat 11.0?

Security hardening spans both the connector layer and the higher-level Catalina authentication stack, with several additions that are immediately actionable for production deployments.

AJP secret comparison was switched to a constant-time algorithm in 11.0.22. If you run Tomcat behind a reverse proxy using the AJP connector with the secret attribute, this eliminates a timing side-channel that could theoretically be exploited to recover the secret value. No configuration change is needed; the improvement is automatic.

CVE-2024-56337 protection was improved across the branch -- reflection is no longer used unless required for the file-system case-sensitivity checks, and the JVM is now automatically configured to mitigate the vulnerability when Tomcat detects a potentially affected web application. Where the JVM cannot be configured correctly, impacted applications are prevented from starting.

A new caseSensitive attribute on LockOutRealm gives operators explicit control over whether user names are matched case-sensitively when making account lockout decisions. The default is false (case-insensitive), which is the safer default in environments where usernames are normalised differently across systems.

The new ssoReauthenticationMode on the Tomcat-provided Authenticators provides per-Authenticator control over the SSO Valve's requireReauthentication flag. This matters if you have multiple applications in an SSO ring with different reauthentication requirements -- previously you had to apply the setting globally.

URI security was also tightened: NULL bytes are now consistently rejected during URI normalization, and URL encoding errors in the Rewrite Valve now trigger an exception rather than silently substituting a replacement character.

What operational and observability improvements are in Apache Tomcat 11.0?

Day-two operations -- startup diagnostics, monitoring, and clustering -- received meaningful attention across the 11.0.x series.

The version.sh and version.bat scripts now display APR version, Tomcat Native version, and OpenSSL version information for both the APR and FFM implementations, including compatibility warnings and third-party library information. Warnings are also logged at startup if the OpenSSL binary or Tomcat Native library are not found. In practice this drastically reduces the time spent diagnosing "why is TLS not using OpenSSL?" questions after a deployment or OS upgrade.

The Manager web application now includes web application state in its HTML and JSON complete server status output, and the output is no longer truncated when one or more applications failed to start. Both improvements matter for automated health check scripts that parse the Manager endpoint.

For Kubernetes-based clustering, raw IPv6 addresses are now supported in the Kubernetes membership provider's service host configuration, log verbosity for connection attempts and failures has been reduced, and the minimum Tomcat Native version is now tracked separately for the 1.x and 2.x branches (minimum 1.3.4 and 2.0.12 respectively from 11.0.16 onwards).

A noCompressionEncodings setting was added to the HTTP connector, allowing fine-grained control over which content-encodings are excluded from compression when the compression attribute is enabled. This is useful when you have upstream components that pre-compress specific content types but Tomcat's compression is still desirable for other responses.