[
https://issues.apache.org/jira/browse/CXF-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748173#action_12748173
]
Wolfgang Nagele commented on CXF-2403:
--------------------------------------
I have now generated all keystores necessary for the mutual authentication via
client certificates. You can find them attached as 'client-keystore' and
'client-truststore' aswell as 'server-keystore' and 'server-truststore'.
The were generated using the following commands:
openssl genrsa -des3 -out client.key 1024
openssl req -new -x509 -key client.key -out client.crt -days 1000
openssl pkcs12 -export -out client.p12 -inkey client.key -in client.crt
keytool -importkeystore -srckeystore client.p12 -srcstoretype PKCS12
-destkeystore client-keystore
keytool -import -v -trustcacerts -file client.crt -keystore server-truststore
openssl genrsa -des3 -out server.key 1024
openssl req -new -x509 -key server.key -out server.crt -days 1000
openssl pkcs12 -export -out server.p12 -inkey server.key -in server.crt
keytool -importkeystore -srckeystore server.p12 -srcstoretype PKCS12
-destkeystore server-keystore
keytool -import -v -trustcacerts -file server.crt -keystore client-truststore
The keytool commands for the truststore's have been interchanged so the public
key's end up on the respective others side.
With this you should be able to reproduce my scenario. Let me know if you have
success without setting the extra system properties.
> Use of client certificates via http conduit configuration broken
> ----------------------------------------------------------------
>
> Key: CXF-2403
> URL: https://issues.apache.org/jira/browse/CXF-2403
> Project: CXF
> Issue Type: Bug
> Components: Configuration
> Reporter: Wolfgang Nagele
> Attachments: client-keystore, client-truststore, client.crt,
> client.key, client.p12, server-keystore, server-truststore, server.crt,
> server.key, server.p12
>
>
> To use standard SSL client certificates for authentication the following
> configuration should work:
> <http:conduit name="*.http-conduit">
> <http:tlsClientParameters>
> <sec:keyManagers keyPassword="password">
> <sec:keyStore type="JKS" password="password" file="keystore" />
> </sec:keyManagers>
> <sec:trustManagers>
> <sec:keyStore type="JKS" password="password" file="truststore" />
> </sec:trustManagers>
> </http:tlsClientParameters>
> </http:conduit>
> In this configuration we would have the public certificate of the server we
> want to connect to in the truststore and the private key and certificate in
> the keystore.
> With the current CXF implementation this results in the following exception:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> at
> sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:174)
> [na:1.6.0_13]
> at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:238)
> [na:1.6.0_13]
> at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:280)
> [na:1.6.0_13]
> ... 39 common frames omitted
> Once we additionally define the following properties it works:
> * javax.net.ssl.keyStore=keystore
> * javax.net.ssl.keyStorePassword=password
> * javax.net.ssl.trustStore=truststore
> * javax.net.ssl.trustStorePassword=password
> This however results in very ugly setups where we have to define the same
> data twice. Also we miss out on CXF's option of defining specific keystores
> and truststores per webservice.
> For further information also see: http://www.quendor.org/archiv/428
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
