Bug ID: JDK-8373478 Possible regression of JDK-8235311

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
tbdResolved

ADDITIONAL SYSTEM INFORMATION :
Rockylinux in docker container 

A DESCRIPTION OF THE PROBLEM :
https://bugs.openjdk.org/browse/JDK-8235311 using default TLSv1.3 against Azure Application Gateway version is having this same tag mismatch error. 

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Using jmeter against Azure Application Gateway version 2 for TLS offloading.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Works fine in TLS 1.3
ACTUAL -
Fails up to 40% of the time with tag mismatch error.   Solved through setting protocol on client/java code to TLSv1.2

Closing as suggested by the submitter.
22-12-2025
Additional information from the submitter: According to the following information https://learn.microsoft.com/en-us/azure/firewall/firewall-known-issues TLS 1.3 support TLS 1.3 is partially supported. The TLS tunnel from client to the firewall is based on TLS 1.2, and from the firewall to the external Web server is based on TLS 1.3. Updates are being investigated. Because of this information please close this bug report.
22-12-2025
We were unable to reproduce the issue. All handshakes completed normally. In order to narrow down the source of the problem, could you try running the program with the following VM flags, and see if any of them help? -XX:+UnlockDiagnosticVMOptions -XX:-UseAESIntrinsics -XX:-UseGHASHIntrinsics -Djdk.tls.client.useCompatibilityMode=false Also, capturing the SSL keys (for example using the code from https://github.com/openjdk/jdk/pull/2896) and checking if Wireshark can decode the captured traffic would confirm if the server traffic is well-formed. The TLS 1.2 traffic is using cipher suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f), and TLS 1.3 is using: TLS_AES_256_GCM_SHA384 (0x1302); if would be interesting to know if TLS 1.2 with TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) would also fail.
16-12-2025
The observations on Windows 11: JDK 17: Passed. All tests success. JDK 25: Passed. JDK 26ea+17: Passed.
16-12-2025
Requested the URL from the submitter to investigate the issue.
12-12-2025
This is jmeter running on linux-x86, correct? Does the problem happen only in jmeter, or does it affect other apps as well? Does it happen when the client app is run on a different machine? Looking at the logs, it seems that the client was able to decrypt EncryptedExtensions, but then failed to decrypt the following message using the same encryption keys (TLS1.3 only changes the encryption keys again after processing the Finished message). This would suggest a problem with either the peer or the network, and since it works with TLS1.2, the peer is the main suspect. Is it possible to extract the encryption keys from the server? If it is, you could use Wireshark to confirm if there's a problem with encryption on the server side; Java does not log encryption keys.
11-12-2025
Need external applications to observed the issue. Impact -> H (Regression) Likelihood -> M (Somewhere in-between the extremes) Workaround -> L (A workaround provided) Priority -> P3
11-12-2025