Slawomir Nowak created CXF-8037:
-----------------------------------

             Summary: Apache CXF (AsyncHTTPConduit) ignores system keyStore 
property
                 Key: CXF-8037
                 URL: https://issues.apache.org/jira/browse/CXF-8037
             Project: CXF
          Issue Type: Bug
          Components: WS-* Components
    Affects Versions: 3.3.1, 3.2.5
            Reporter: Slawomir Nowak


I'm using play-soap library to connect to a webservice, which under the hoods 
uses Apache CXF library (3.2.5).

I need to use mutual TLS and it's difficult to configure play-soap, so I 
thought the underlying CXF would respect system properties.
However, it seems like it completely ignores the javax.net.ssl.keyStore 
property. 

So I tried to set the following properties:
{code:java}
System.setProperty("javax.net.ssl.trustStore", "truststore.jks")
System.setProperty("javax.net.ssl.trustStorePassword", "changeit")
System.setProperty("javax.net.ssl.keyStore", "keystore.p12")
System.setProperty("javax.net.ssl.keyStoreType", "PKCS12")
System.setProperty("javax.net.ssl.keyStorePassword", "changeit")
System.setProperty("javax.net.debug", "ssl,handshake"){code}


However, I'm getting SSL Hanshake exception and according to the logs, the SSL 
client is not able to find proper client certificate requested by the server 
(even though the certificate exists in p12 file).

I think this is caused by the 

org.apache.cxf.transport.http.asyncclient.AsyncHTTPConduit.getSSLContext which 
ignores the key managers completely:
{code:java}
KeyManager[] keyManagers = tlsClientParameters.getKeyManagers();
org.apache.cxf.transport.https.SSLUtils.configureKeyManagersWithCertAlias(
tlsClientParameters, keyManagers);

TrustManager[] trustManagers = tlsClientParameters.getTrustManagers();
if (trustManagers == null) {
trustManagers = 
org.apache.cxf.configuration.jsse.SSLUtils.getDefaultTrustStoreManagers(LOG);
}{code}


I think that simply adding
{code:java}
if (keyManagers == null) {
keyManagers = 
org.apache.cxf.configuration.jsse.SSLUtils.getDefaultKeyStoreManagers(LOG);
}{code}

should solve the issue



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to