Connection fails when using verify-client in undertow

[jasim]

Hello,

  I have tried to use verify-client (both REQUIRED or REQUESTED) in undertow module, but the connection from an web service subscriber always fails.

java version "1.8.0"

Java(TM) SE Runtime Environment (build pap3280sr2fp10-20160108_01(SR2 FP10))

IBM J9 VM (build 2.8, JRE 1.8.0 AIX ppc-32 20160106_284759 (JIT enabled, AOT enabled)

J9VM - R28_20160106_1341_B284759

JIT  - tr.r14.java_20151209_107110.02

GC  - R28_20160106_1341_B284759

J9CL - 20160106_284759)

JCL - 20151231_01 based on Oracle jdk8u71-b15

The JRE has been patched to unrestricted security policy.

wildfly 10.0.0.Final

I have configured https, providing a ssl-realm

          <security-realm name="SSLRealm">

                <server-identities>

                    <ssl protocol="TLS">

                        <keystore path="server.keystore" relative-to="jboss.server.config.dir" keystore-password="#######"/>

                    </ssl>

                </server-identities>

                <authentication>

                    <truststore provider="jks" path="server.truststore" relative-to="jboss.server.config.dir" keystore-password="#######"/>

                </authentication>

            </security-realm>

and an https-listener

  <https-listener name="default-https" security-realm="SSLRealm" socket-binding="https" verify-client="REQUIRED"/>

I have patched

  <http-connector name="http-remoting-connector" connector-ref="default-https" security-realm="ApplicationRealm"/>

Thus, the https conection works.

As I need mutual client authentication I added

  <security-constraint>

      <web-resource-collection>

            <web-resource-name>MyService</web-resource-name>

            <url-pattern>/MyService</url-pattern>

            <http-method>GET</http-method>

            <http-method>POST</http-method>

        </web-resource-collection>

      <user-data-constraint>

            <transport-guarantee>CONFIDENTIAL</transport-guarantee>

      </user-data-constraint>

  </security-constraint>

  <login-config>

  <auth-method>CLIENT-CERT</auth-method>

  <realm-name>SSLRealm</realm-name>

  </login-config>

to web.xml.

I call the webservice from locally - on the AIX box. The certificated are issued by an official CA. The server and client keystores and truststores contains actually the same certificates.

After I switched ssl debugging on I see

main, WRITE: TLSv1.2 Change Cipher Spec, length = 1

%% Invalidated:  [Session-1, SSL_ECDHE_RSA_WITH_AES_256_CBC_SHA384]

main, SEND TLSv1.2 ALERT:  fatal, description = handshake_failure

main, WRITE: TLSv1.2 Alert, length = 2

main, Exception sending alert: java.net.SocketException: Invalid argument

main, called closeSocket()

I don't know what SSL going on here. Possibly, the client is already verified and the SSL fails to process "Change Cipher Spec" operation.

The connection works without the verify-client parameter.

I will appreciate an idea. Thanks.

The full ssl debug log is attached.

[mchoma]

I assume provided log is from client side. If so, can you provide also tls debug information of server?

If one way authentication works well, I suppose there will be some problem with client certificate/server truststore.

[jasim]

while debugging the server side, I figured out that the truststore in the ssl-realm is not configured well. (an additional parameter was there, probably a remaining of server upgrade. I have not spot any error message and CLI script actually also did not complain too, but after removing it works

[mchoma]

Jaroslav,

can you please write down here, exactly which parameter you had to remove and what was your error in server log. Thank you.

[jasim]

Hello Martin,

  finally, it was really a minor issue.

  I had the misfortune to configure keystore-provider=jks instead of "JKS" for the truststore in a security realm. (jks is a possible corresponding value in JSSE, but obviously in in wildfly)

  The CLI configuration script works also with keystore-provider=jks, but after activating of verify-client=REQUIRED in the https-listener,

  no connection is possible. At the first glance, it was not obvious that the problem is the wrong truststore configuration, so I get messed around.

  SSL-debugging of server helped, finally.

  I removed the superfluous call for keystore-provider as JKS is default after all and it works now.

Best regards

Jaro

[jaikiran]

Jaroslav Simak wrote:

Hello Martin,

  finally, it was really a minor issue.

  I had the misfortune to configure keystore-provider=jks instead of "JKS" for the truststore in a security realm. (jks is a possible corresponding value in JSSE, but obviously in in wildfly)

  The CLI configuration script works also with keystore-provider=jks, but after activating of verify-client=REQUIRED in the https-listener,

  no connection is possible. At the first glance, it was not obvious that the problem is the wrong truststore configuration, so I get messed around.

  SSL-debugging of server helped, finally.

This looks like something that can be improved. So I filed a JIRA [WFCORE-1597] Do a lenient case insensitive check for JKS keystore provider type in the configured truststore of a secur… and sent pull requests to have it enhanced. If they get accepted and merged, the enhancement would probably be available in the next WildFly release.