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

What changed with TLS and SSL configuration in Apache Tomcat 10.1?

TLS configuration in Tomcat 10.1 received the most significant overhaul of any area in this release series. The biggest behavioral change is that TLSv1.3 cipher suites placed in the ciphers attribute of SSLHostConfig are now always silently ignored -- this behavior was previously inconsistent between OpenSSL and JSSE implementations, which caused hard-to-debug configuration drift between environments. Starting in 10.1.51, you must use the new dedicated cipherSuites attribute for TLS 1.3 suites.

In practice, if you had mixed TLS 1.2 and TLS 1.3 suites in a single ciphers string, Tomcat will now log a warning and automatically migrate TLS 1.3 entries to cipherSuites at startup -- this helper behavior is a temporary bridge that will be removed in 12.0.x. Review your connector configuration now rather than relying on this migration aid.

<SSLHostConfig
    ciphers="TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:..."
    cipherSuites="TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256">
</SSLHostConfig>

OCSP support was substantially expanded. JSSE-based connectors now support OCSP at all (previously it was OpenSSL-only), and OCSP can now be configured per-connector independently for both OpenSSL and JSSE implementations. Soft-failure mode was added with a secure-by-default disabled flag, and OCSP response size limits were added to protect against oversized responses. The FFM (Foreign Function Memory) code path received numerous memory management fixes including freeing private keys, CA certificates, and certificate chains after use. Watch out for memory leaks if you are on versions prior to 10.1.49.

A new groups attribute on SSLHostConfig lets you restrict which named groups (curves) the SSL engine may negotiate. TLS 1.3 groups from OpenSSL 4.0 are now recognized. For teams deploying on Java 17+ and targeting forward-compatible post-quantum readiness, the new MLDSA certificate type (10.1.47) allows ML-DSA certificates to be selected based on the TLS client hello.

What HTTP/2 bugs were fixed in Tomcat 10.1 and how do they affect production deployments?

Tomcat 10.1 addressed a series of HTTP/2 correctness issues that could affect both stability and security in production. The most impactful was a potential integer overflow in connection-level window allocation (fixed in 10.1.55) -- under high stream concurrency with large window updates, capacity could overflow and be incorrectly distributed to individual streams, causing stream stalls or protocol violations.

Additional HTTP/2 fixes include:

• A header frame parsing bug that closed connections without sending a GOAWAY frame when an invalid HEADERS frame was received -- clients would see abrupt connection drops rather than graceful protocol-level errors.
• HPACK header decoding edge case that could close a valid connection unexpectedly (10.1.55).
• HTTP/2 request header read buffer was not being reset to default size after a stream reset, causing potential memory growth under stream-heavy workloads.
• Trailer field validation and filtering now aligns with HTTP/1.1 behavior, rejecting fields not permitted in trailers.
• The :scheme pseudo-header is now validated to be consistent with TLS usage, and pseudo-header and CONNECT request handling is aligned with RFC 9113 section 8.5.

A new drainTimeout attribute (10.1.53) on the HTTP/2 UpgradeProtocol element lets you control the delay between the two final GOAWAY frames Tomcat sends when gracefully closing an HTTP/2 connection. This matters if you are doing rolling restarts or load balancer draining and need tighter control over in-flight stream handling during shutdown.

<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol"
    drainTimeout="5000" />

How does Tomcat 10.1 differ from Tomcat 9 when migrating existing applications?

Tomcat 10.1 implements the Jakarta EE 10 platform, which means all javax.* package references in your application must be migrated to jakarta.* -- this is the single most impactful migration effort. Applications targeting Tomcat 9 will not run on Tomcat 10 without this namespace change. Bundled APIs include Servlet 6.0, JSP 3.1, EL 5.0, and WebSocket 2.1.

Most teams use the bundled Apache Tomcat migration tool for Jakarta EE (also available as a standalone download). You can place .war files in $CATALINA_BASE/webapps-javaee and Tomcat will automatically convert and copy them to the webapps directory at startup. This is useful for quick validation but should not be relied on for production -- do the migration offline and test thoroughly.

Tomcat 10.1 requires Java 11 or later. The javax.servlet, javax.websocket, and javax.el APIs are not bundled or compatible. Beyond the namespace change, most Tomcat-specific configuration files (server.xml, context.xml, web.xml) carry over without modification. Watch out for the TLS configuration changes described above, particularly if you have ciphers attributes with mixed TLS 1.2 and 1.3 suites.

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

Authentication and access control received meaningful hardening across several releases in the 10.1 series. The AJP secret comparison was switched to a constant-time algorithm in 10.1.55, closing a potential timing side-channel for AJP-connected setups. URIs containing NULL bytes are now consistently rejected during normalization, hardening request routing against injection-style payloads.

Security constraint handling was also corrected. Requests to URIs protected only by the special ** role (all authenticated users) were incorrectly returning 403 to unauthenticated clients rather than 401, breaking standard challenge-response authentication flows. This is fixed in 10.1.55. The RealmBase class now correctly finds all matching extension-based security constraints.

LockOutRealm gained a new caseSensitive attribute (defaults to false) that controls whether username lockout decisions treat names case-insensitively. This is important for environments where John and john are the same account but were previously tracked as separate lockout candidates. For SSO, a new ssoReauthenticationMode on individual Authenticators lets you override the global SSO Valve requireReauthentication setting per authentication type -- SPNEGO now performs a full re-authentication when reauthentication is enabled so that delegated credentials remain accessible.

WebDAV also received a new maxRequestBodySize initialization parameter (default 4096 bytes) that limits the body size for LOCK and PROPFIND requests, reducing exposure to large-body denial-of-service attempts.

What operational and diagnostics improvements came in Apache Tomcat 10.1?

Day-to-day operations got meaningfully easier in later 10.1 releases. The version.sh and version.bat scripts (10.1.54) now report APR, Tomcat Native, and OpenSSL version information alongside compatibility warnings -- previously you had to parse log output or inspect the environment manually to confirm whether the native library was actually loaded and at what version.

The Manager application now includes web application state in its HTML and JSON complete status output (10.1.50), and fixes a truncation bug that caused the output to be cut off if any application had failed to start. Rewrite Valve misconfiguration now logs at INFO rather than being silently swallowed, and suspicious appBase values on Host elements now produce warnings at startup.

Access log accuracy received several fixes: a regression that logged request start time instead of end time (10.1.51), a bug that wrote ?- instead of ? when a query string was present but empty (10.1.55), and a fix that ensures URI and query strings are properly escaped in access logs. The ExtendedAccessLogValve escaping is now aligned with the other valve implementations, making log parsing consistent across all valve types.

In the JDBC pool, a long-standing issue was fixed where a closed underlying connection would still be returned to the pool, leading to silent failures on the next borrow. This affects any deployment using tomcat-jdbc or the internal DBCP fork as the connection pool.