Impossible de se connecter en SSL webservice avec cxf http-conduit

Je suis en train d'essayer de vous connecter à un webservice SOAP et de la nécessité de fournir un certificat d'authentification. Je suis actuellement en utilisant le cxf http conduit à localiser mon certificat. J'ai reçu un fichier p12 du service, je suis désireux de faire appel. J'ai importé le p12 dans un jks. J'ai mis le jks dans le chemin de classe avec mes cxf.xml page. J'ai modifié mon web.xml pour contenir le context-param et de l'auditeur de la classe, mais je suis encore en train de journaux à partir du serveur de dire non certificat fourni. J'ai regardé partout pour des solutions mais rien n'a fonctionné jusqu'ici. Toute aide est grandement appréciée

CXF.XML

<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sec="http://cxf.apache.org/configuration/security"
xmlns:http="http://cxf.apache.org/transports/http/configuration"
xmlns:jaxws="http://java.sun.com/xml/ns/jaxws"
xsi:schemaLocation="
http://cxf.apache.org/configuration/security
http://cxf.apache.org/schemas/configuration/security.xsd
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
<http:conduit name="*.http-conduit">
<http:tlsClientParameters>
<sec:keyManagers keyPassword="changeit">
<sec:keyStore type="JKS" password="changeit"
resource="myKeystore.jks"
/>
</sec:keyManagers>
<sec:trustManagers>
<sec:keyStore type="JKS" password="changeit"
resource="myKeystore.jks"/>
</sec:trustManagers>
<sec:cipherSuitesFilter>
<!-- these filters ensure that a ciphersuite with
export-suitable or null encryption is used,
but exclude anonymous Diffie-Hellman key change as
this is vulnerable to man-in-the-middle attacks -->
<sec:include>.*_EXPORT_.*</sec:include>
<sec:include>.*_EXPORT1024_.*</sec:include>
<sec:include>.*_WITH_DES_.*</sec:include>
<sec:include>.*_WITH_AES_.*</sec:include>
<sec:include>.*_WITH_NULL_.*</sec:include>
<sec:exclude>.*_DH_anon_.*</sec:exclude>
</sec:cipherSuitesFilter>
</http:tlsClientParameters>
<http:client AutoRedirect="true" Connection="Keep-Alive"/>
</http:conduit>
</beans>

WEB.XML

     <context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:cxf.xml</param-value>
</context-param>
<listener>
<listener-class>
org.springframework.web.context.ContextLoaderListener
</listener-class>
</listener>
InformationsquelleAutor franzke | 2014-06-04
  1. 3

    Je suis d'accord avec @hooknc dernier commentaire. Assurez-vous que votre fichier de clés contient la clé privée de l'entrée. Aussi, définir privatekey mot de passe égale à mot de passe du fichier de clés. Vous pouvez tester votre service avec code ci-dessous. Je l'ai écrit pour cxf version 3.0.0-milestone2, parce que j'ai besoin de plusieurs signatures, mais je pense que le code devrait fonctionner également avec la version stable de la branche 2.x

    private PaymentService_Service service = null;
private PaymentService iface = null;
@Before
public void setUp() throws Exception {
System.setProperty("com.sun.xml.ws.transport.http.client.HttpTransportPipe.dump", "true");
System.setProperty("javax.net.debug", "ssl");
service = new PaymentService_Service();
iface = service.getPaymentServiceImplPort();
Client client = ClientProxy.getClient(iface);
HTTPConduit http = (HTTPConduit) client.getConduit();
TLSClientParameters parameters = new TLSClientParameters();
parameters.setSSLSocketFactory(createSSLContext().getSocketFactory());
http.setTlsClientParameters(parameters);
HTTPClientPolicy httpClientPolicy = new HTTPClientPolicy();
httpClientPolicy.setConnectionTimeout(36000);
httpClientPolicy.setAllowChunking(false);
httpClientPolicy.setReceiveTimeout(32000);
http.setClient(httpClientPolicy);
}
private SSLContext createSSLContext() throws Exception{
KeyStore trustStore = KeyStore.getInstance(KeyStore.getDefaultType());
trustStore.load(new FileInputStream("/home/user/dev/project/key/http.jks"), "changeit".toCharArray());
KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
keyStore.load(new FileInputStream("/home/user/dev/project/key/client.jks"), "changeit".toCharArray());
TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
tmf.init(trustStore);
KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
kmf.init(keyStore, "changeit".toCharArray());
SSLContext sslContext = SSLContext.getInstance("SSL");
sslContext.init(kmf.getKeyManagers() , tmf.getTrustManagers(), new SecureRandom());
return sslContext;
}
@Test
public void testSomeMethod() throws Exception {
Client client = ClientProxy.getClient(iface);
client.getInInterceptors().add(new LoggingInInterceptor());
client.getOutInterceptors().add(new LoggingOutInterceptor());
String res = iface.doSomeMethod();
}
    • Merci, cela a fonctionné!
    InformationsquelleAutor user1516873
  2. 0

    Je ne crois pas, juste de mettre le truststore (jks) dans votre classpath fonctionnera de la façon dont vous pensez qu'elle le fera. Je suis assez confiant que vous devrez appeler un de nos le truststore que vous souhaitez utiliser via vm options.

    Ajoutez -Djavax.net.le protocole ssl.trustStore={file_path_to_your_jks} à votre application VM arguments. Vous pourriez aussi avoir besoin d'utiliser -Djavax.net.le protocole ssl.trustStorePassword={your_jks_password} si le mot de passe par défaut de 'changeit" n'était pas utilisé.

    • Si je devais ajouter la confiance cert pour le fichier cacerts dans mon jre, aurais-je encore besoin d'ajouter de la VM argument?
    • Si vous ajoutez le nouveau certificat par défaut le fichier cacerts vous ne nécessitant pas la vm argument, mais je vous recommande fortement contre cette stratégie. Si vous ajoutez ce certificat à votre base cacerts, puis toutes les applications java en cours d'exécution sur votre machine confiance que le nouveau certificat. Qui pourrait ne pas être trop dangereux, mais il n'est tout simplement pas super sécurisé. Aussi, lorsque vous mettez à jour votre version de java, vous devez n'oubliez pas de réinstaller le certificat de nouveau. Mais là encore, quand vous mettez à jour votre version de java, vous devez re-copier le fichier cacerts et ré-importer le certificat de toute façon.
    • Ok, ça a du sens. Dois-je besoin de changer le chemin d'accès de l'truststore dans le http-conduit dans cxf.xml pour pointer vers le fichier cacerts?
    • Donc, je ne savais pas ce CXF était jusqu'à tout à l'heure, mais un rapide coup d'oeil à leur documentation, ils expliquent comment définir un truststore: cxf.apache.org/docs/...
    • C'est le document que j'ai utilisé comme un guide
    • Compris. Donc, mon manque de compréhension de la lecture est en faute. Désolé. Est-il un moyen pour activer ssl de débogage (-Djavax.net.debug=ssl) avec cxf? Vous devez vérifier les éléments suivants: Le serveur fait la demande d'un certificat client, ce que les certificats du serveur accepte (il y aura une liste d'autorités de certification qu'ils acceptent, et, enfin, que le bon certificat client est à votre fichier de clés (keytool -list-v -keystore de magasin de clés.jks). Désolé je n'ai pas lu votre question plus attentivement la première fois.
    • Pas de problème, ce est tout nouveau pour moi. J'ai couru le debug, je peux voir où il est de spécifier la trustStore et l'emplacement, cependant, la ligne "fichier de clés est:" la page est vide, ce qui fait de moi pense que c'est de ne pas reconnaître le fichier de clés je suis en train de fournir.
    • Assurez-vous que le fichier de clés est AOK en utilisant l'utilitaire keytool -list-v -keystore <your_keystore_name_here>' de la commande. Autres choses à essayer: Utilisez le chemin d'accès complet à la fois votre fichier de clés et truststore (au lieu de simplement classpath). Il ressemble à votre fichier de clés et truststore sont le même fichier, c'est ok, mais en général, je essaie de garder les deux distincts. Le fichier de clés contient vos certificats de client alors que le truststore devrait contenir des certificats et autorités de certification de confiance.

    InformationsquelleAutor hooknc