What are you trying to do?
Call a third-party API hosted on Microsoft-IIS/10.0 using OkHttp (Java HTTP client) from a containerized Spring Boot application.

Expected behaviour:
TLS handshake should complete successfully and the API call should succeed, as it did with eclipse-temurin:21 resolving to OpenJDK 21.0.9 (2025-10-21 LTS).

Observed behaviour:
After eclipse-temurin:21 resolved to OpenJDK 21.0.11 (2026-04-21 LTS) in our latest build, all HTTPS calls to this specific IIS 10.0 endpoint fail with:

java.net.SocketException: Connection reset
at sun.security.ssl.SSLSocketImpl.startHandshake()
at okhttp3.internal.connection.RealConnection.connectTls()

SSL debug logging (-Djavax.net.debug=ssl:handshake) confirmed:

• Java sends a valid TLS 1.3 ClientHello (436 bytes) successfully
• Server responds with a TCP RST — zero bytes returned, no ServerHello, no TLS alert
• 59ms after ClientHello, connection is dead

The same endpoint works fine with curl from the same container, which uses OpenSSL and formats the TLS ClientHello differently, successfully negotiating TLS 1.2.

Any other comments:
This appears to be a TLS ClientHello compatibility change between OpenJDK 21.0.9 and 21.0.11 that exposes a bug in Microsoft SChannel's handling of Java JSSE's TLS 1.3
ClientHello format. Would like to understand what specifically changed in TLS extension formatting or cipher suite ordering between these two versions that causes this regression
in interoperability with IIS 10.0 / Windows SChannel.