Bug ID: JDK-8210846 TLSv.1.3 interop problems with OpenSSL 1.1.1 when used on the client side with mutual auth

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.

JDK 11	JDK 12	JDK 8	Other
11.0.1Fixed	12 b13Fixed	8u261Fixed	openjdk8u272Fixed

ADDITIONAL SYSTEM INFORMATION :
 /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version
java version "11" 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)


A DESCRIPTION OF THE PROBLEM :
I am currently in the process of adding TLS 1.3 support into netty-tcnative[1] which uses JNI to make use of OpenSSL for it. During this work I noticed that I received test-failures when mutual auth is used and the JDK implementation is used on the client side. When using the JDK implementation on the server and client side all works as expected. Also if I use another protocol (like TLSv1.2) all works as expected.

The problem I am observing is that the client seems to sent the certificate ������too late������ and so the server (which uses openssl) will report and error that the client did not provide an certificate (even when it was required). 

For more details and debug logs see:

http://mail.openjdk.java.net/pipermail/security-dev/2018-September/018240.html

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See:

https://github.com/normanmaurer/jdktls13bugreproducer

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Handshake and mutual auth completes successfully.
ACTUAL -
Server is not able to see the client cert.

---------- BEGIN SOURCE ----------
https://github.com/normanmaurer/jdktls13bugreproducer
---------- END SOURCE ----------

FREQUENCY : always

Original submitter built/tested using the changeset above, and confirmed this addressed his issue.
20-09-2018
Reproduced the issue on Windows 7 using the attached test case and below steps : 1. Start OpenSSL server >D:\OpenSS1.1.1\bin\openssl s_server -tls1_3 -cert src\main\resources\test.crt -key src\main\resources\test_unencrypted.pem -4 -accept 127.0.0.1:8443 -state -debug -Verify 1 2. Build and run >d:\jdk-11\bin\javac src\main\java\ReproducerClient.java -d target >d:\jdk-11\bin\java -cp target\;src\main\resources\ ReproducerClient Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received fatal alert: certificate_required at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128) at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117) at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308) at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279) at java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181) at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164) at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1155) at java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1125) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:823) at java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:758) at ReproducerClient$1.run(ReproducerClient.java:33) at java.base/java.lang.Thread.run(Thread.java:834) Tested with : JDK 11-ea+28 - Fail JDK 12-ea+10 - Fail
18-09-2018
Attached JSSE debug log.
17-09-2018
Submitter wrote: As requested I pushed a pure JDK reproducer to GitHub which you can easily use to reproduce the problem. All the details how to run it etc are in the README.md file. I also included a server to show that all works if we use the JDK on the client side and server side. Also as stated before you will see that the cert will be send even if you use OpenSSL on the serverside if you replace ��-Verify 1�� with ��-verify 1�� (which is kind of the same as setWantClientAuth(true)). Please don't hesitate to ping me if you need any more details or have any more questions. https://github.com/normanmaurer/jdktls13bugreproducer Here is the output with debugging enabled on the client side.
17-09-2018