[
https://issues.apache.org/jira/browse/CXF-7876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16662018#comment-16662018
]
Freeman Fang commented on CXF-7876:
-----------------------------------
Thanks [~coheigea]!
I eventually figured out what's going on under the hood.
With SSL debug log
{code}
-Djavax.net.debug=all
{code}
I found that only with OpenJDK JAVA11, during the 8 secs sleep in
SAMLRenewTest, the SSLSocket used for the HTTPS connection will be
closed(Keep-Alive-Timer kick in so it would be a TTL thing)
{code}
avax.net.ssl|DEBUG|01|main|2018-10-24 17:27:51.594
CST|SSLSocketInputRecord.java:249|READ: TLSv1.2 application_data, length = 24
javax.net.ssl|DEBUG|01|main|2018-10-24 17:27:51.594
CST|SSLCipher.java:1915|Plaintext after DECRYPTION (
0000: 0D 0A 30 0D 0A 0D 0A ..0....
)
======> sleep
javax.net.ssl|DEBUG|25|Keep-Alive-Timer|2018-10-24 17:27:56.297
CST|SSLSocketImpl.java:473|duplex close of SSLSocket
javax.net.ssl|DEBUG|25|Keep-Alive-Timer|2018-10-24 17:27:56.297
CST|SSLSocketOutputRecord.java:71|WRITE: TLS13 alert(user_canceled), length = 2
javax.net.ssl|DEBUG|25|Keep-Alive-Timer|2018-10-24 17:27:56.297
CST|SSLCipher.java:2020|Plaintext before ENCRYPTION (
0000: 01 5A 15 00 00 00 00 00 00 00 00 00 00 00 00 00 .Z..............
0010: 00 00 00 ...
)
javax.net.ssl|DEBUG|25|Keep-Alive-Timer|2018-10-24 17:27:56.298
CST|SSLSocketOutputRecord.java:85|Raw write (
0000: 17 03 03 00 23 C4 E0 07 B7 68 9F 65 63 CF BB 24 ....#....h.ec..$
0010: 8B 4E 80 FC E6 B4 4C EB 0F 42 DD 29 8F 13 12 97 .N....L..B.)....
0020: CD D1 18 EE 13 6F 06 8C .....o..
)
javax.net.ssl|DEBUG|25|Keep-Alive-Timer|2018-10-24 17:27:56.298
CST|SSLSocketOutputRecord.java:71|WRITE: TLS13 alert(close_notify), length = 2
{code}
So when the client want to send the request again after sleep, actually the
underlying socket used by the HTTPS connection is reset.
And then when do hostname verification in AllowAllHostnameVerifier
this line
{code}
Certificate[] certs = session.getPeerCertificates();
{code}
will throw SSLException since the session is kinda out-of-data, hence the
AllowAllHostnameVerifier return false, that's why we saw hostname verification
error.
The commit here[1] fixed this issue.
Basically the HTTPConduit get chance to re-connect to obtain a valid SSLSession
if the original one is stale.
[1]https://github.com/apache/cxf/commit/0cdc4bb5e37fabbf6afeef47ce7c9913f3282103
Cheers
Freeman
> several tests failed with OpenJDK 11
> ------------------------------------
>
> Key: CXF-7876
> URL: https://issues.apache.org/jira/browse/CXF-7876
> Project: CXF
> Issue Type: Task
> Reporter: Freeman Fang
> Assignee: Freeman Fang
> Priority: Major
> Fix For: 3.3.0
>
>
> Though they are ok with Oracle one.
> They are
> {code}
>
> rt/bindings/xml/src/test/java/org/apache/cxf/binding/xml/interceptor/XMLMessageInInterceptorTest.java
>
> rt/bindings/xml/src/test/java/org/apache/cxf/binding/xml/interceptor/XMLMessageOutInterceptorTest.java
>
> rt/transports/http-netty/netty-client/src/test/java/org/apache/cxf/transport/http/netty/client/integration/SSLNettyClientTest.java
>
> rt/transports/http-netty/netty-server/src/test/java/org/apache/cxf/transport/http/netty/server/integration/SSLNettyServerTest.java
>
> rt/transports/http-netty/netty-server/src/test/java/org/apache/cxf/transport/http/netty/server/integration/SSLNettySpringServerTest.java
>
> services/sts/sts-core/src/test/java/org/apache/cxf/sts/token/provider/SAMLProviderLifetimeTest.java
>
> services/sts/systests/advanced/src/test/java/org/apache/cxf/systest/sts/renew/SAMLRenewTest.java
>
> systests/transports/src/test/java/org/apache/cxf/systest/https/ciphersuites/CipherSuitesTest.java
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
