[jboss-jira] [JBoss JIRA] (WFLY-11007) Using OpenShift generated certificates and client auth cause TLS errors

[Jan Lieskovsky (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-11007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632821#comment-13632821 ] 

Jan Lieskovsky commented on WFLY-11007:
---------------------------------------

{noformat}
Of course, I could trim the list down manually (by using keytool) or even remove /etc/pki/ca-trust/extracted/java/cacerts altogether but I guess this is a valid situation we have here and it's the WF that should be monitoring the length of the payload it sends (especially if there's a limit set by the RFC).

It is worth to mention that this happen only on client auth turned on. Only in this case, the server sends a list of CAs.
{noformat}

Given the above research, IMHO this is EAP server bug. Of course, one can say, if you want to get it working, don't use that much certificates. But since this might be valid usecase / need, IMHO the server should be updated to send the list of CA certs in such chunks, it won't overflow the TLS field length (like split them in more subsequent packets, having the TLS field only as that much long, as required / allowed by the RFC).

[~dlofthouse] WDYT -^?

{noformat}
I hope this answers your questions Jan Lieskovsky and Darran Lofthouse 
{noformat}

[~sebastian.laskawiec] Hey Seb, yes it does! Thank you for your investigation!

> Using OpenShift generated certificates and client auth cause TLS errors
> -----------------------------------------------------------------------
>
>                 Key: WFLY-11007
>                 URL: https://issues.jboss.org/browse/WFLY-11007
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security, Web (Undertow)
>    Affects Versions: 13.0.0.Final
>            Reporter: Sebastian Łaskawiec
>            Assignee: Stuart Douglas
>
> h2. Summary
> It seems that when using OpenShift generated certificates and client auth (with {{want-client-auth="true"}}) the TLS handshake fails with {{RECV TLSv1.2 ALERT:  fatal, record_overflow}} message.
> h2. Explanation
> I'm using {{oc cluster up}} and deploying Keycloak (WF 13 based) on OpenShift local cluster using the (1) template. The service in the the template uses OpenShift generated certificates ({{"service.alpha.openshift.io/serving-cert-secret-name": "keycloak-x509-https-secret"}}). Both files are mounted in the Keycloak pod and translated into keystore and truststore (see the configuration after the transformation (2)). Once the pod is up and running, I'm issuing a {{curl}} command as shown in (3). {{curl}} fails saying that {{* error:1408F092:SSL routines:ssl3_get_record:data length too long}}. The server logs with TLS Handshake debugging turned on might be found here (4). As shown in the link, the server has written {{16384}} bytes. 
> I also did a test with manually created certificates (5). The result might be found here (6). As shown in the link, we've written {{16050}} bytes instead of {{16384}} and the handshake was successful.
> h2. Possible solution
> Perhaps we should cut the list CAs transmitted by the server when asking for client auth when it exceeds certain number of bytes. It would be helpful to write a warn message too.
> Links:
> - (1) Keycloak OCP Template https://gist.github.com/slaskawi/57ed810a7109a02a9d884b61ce2e7f13
> - (2) Transformed configuration https://gist.github.com/slaskawi/92aead6c519b867621129b640b4a3c88
> - (3) curl command https://gist.github.com/slaskawi/3bc32b8e96c2499cb7b48c3c5cb28616
> - (4) https://gist.github.com/slaskawi/b6477fe3cd65890c879cfe6f95359450#file-logs-bad-L1485
> - (5) Keycloak and OpenShift integration demo https://github.com/keycloak/openshift-integration/blob/master/install-keycloak#L11-L22
> - (6) https://gist.github.com/slaskawi/7fd87e1f2e6c4faf657d9e8289ed3392#file-logs-good-L1383



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)