Discussion :

[cbi1net]

Bonjour,

Je vous consulte pour une problématique qui me résiste.

Environnement :
- tomcat-6.0.44-1
- Java(TM) SE Runtime Environment (build 1.6.0_29-b11)

Soit une webapp sous Tomcat qui dispose d'un client WS se connectant en https sur un serveur WS distant. En l'état, le certificat fourni est conforme, l'authentification effective et la requête émise est consommée par le serveur distant qui répond comme attendu. Le système est opérationnel.

A ce système, j'ajoute dans la webapp un serveur WS destiné à consommer des requêtes entrantes en provenance d'autres systèmes en http. Ce serveur repose sur jaxws. Il convient donc d'embarquer dans le war la librairie jaxws-rt.jar. Ce module serveur n'est pas lié au client WS précédent, il est simplement exécuté dans la même webapp.

Après cet ajout, en réalisant la même opération que précédemment (appel https au serveur WS distant), le système retourne une Exception :
com.sun.xml.ws.client.ClientTransportException: HTTP transport error: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
com.sun.xml.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:132)
...

En supprimant simplement le jaxws-rt.jar (je suis donc contraint de commenter la conf dans le web.xml) mais en conservant le code du serveur WS , l'erreur n'apparait plus.

A noter que la classe com.sun.xml.ws.transport.http.client.HttpClientTransport de laquelle est émise l'exception est contenue dans jaxws-rt.jar
J'ai essayé diverses versions de jaxws-rt.jar, rien n'y a fait.

• En cas d'absence du jaxws-rt.jar, quelle classe gère le HttpClientTransport ? celle de jre/lib/rt.jar ?
• Est-il possible d'inclure le jaxws-rt.jar tout en paramétrant l'usage d'une classe différente pour le WS client préexistant, afin de ne pas modifier son comportement ?
• Faut-il prévoir une architecture différente ? Par exemple le déploiement d'un second war ? Ou bien changer d'implémentation pour le serveur WS ?

Je suis dans une impasse à ce jour, toute aide ou conseil est donc le bienvenu.

Cordialement

[cbi1net]

Eh bien il est utile d'en parler

Pour conclure, en repassant dans le code tout en étant attentif aux packages, je suis tombé là-dessus :
bindingProvider.getRequestContext().put("com.sun.xml.internal.ws.transport.https.client.SSLSocketFactory", socketFactory);

Sachant que c’est ce socketFactory qui contient le certificat client.

Ce qu’on voit ici, c’est que le nom de la propriété est « en dur » et relatif au package com.sun.xml.internal.ws.transport.https.client, donc celui du rt.jar par défaut de la jre.

En activant jaxws-rt, il faut donc configurer la propriété ad-hoc !
En l’occurrence, en modifiant ainsi :
bindingProvider.getRequestContext().put(JAXWSProperties.SSL_SOCKET_FACTORY, socketFactory);
avec JAXWSProperties du package com.sun.xml.ws.developer de jaxws-rt, le nom de la propriété devient "com.sun.xml.ws.transport.https.client.SSLSocketFactory" (notez l’absence du « . internal. »)

Et ainsi, ça fonctionne !

Allez, bonne soirée