Mirth: appel d'un service Web SSL SOAP avec un certificat client

Question

Le scénario consiste à appeler un service Web SOAP SSL externe à partir de Mirth. Le service Web requiert une connexion SSL/TLS avec un certificat client.

L'intention est d'utiliser la destination de l'expéditeur SOAP intégrée pour appeler le service Web sécurisé distant et d'inclure en quelque sorte ce certificat client.

Je comprends que vous devez d'abord installer ce certificat client dans l'environnement d'exécution Java. Cela peut être dans le magasin de certificats de l'environnement d'exécution Java ou dans le magasin de certificats Jetty.

La plate-forme:

• Windows 2003 SP2
• Mirth 1.8
• Java jre1.5.0_09

Question: quelles mesures de configuration (Mirth, magasins de certificats JRE, etc. .) suggéreriez-vous de réussir à avoir un expéditeur SOAP Mirth inclure un certificat client (* .cer) lors de l'appel d'un service Web sécurisé par SSL?

Answer 1

Mirth 1.8 ne peut pas envoyer de certificat client lors de l'appel d'un service Web SOAP.

Answer 2

L'environnement d'exécution Java, ou plus précisément le fournisseur Sun JSSE, présentera un certificat client si certaines propriétés système sont définies. Vous pouvez lire les détails dans le JSSE Reference Guide, mais les propriétés importantes sont javax.net.ssl.keyStore et javax.net.ssl.keyStorePassword.

Il y a quelques inconvénients à cette approche. Tout d'abord, la définition du mot de passe du magasin de clés en tant que propriété système le rend accessible à tout code exécuté dans ce processus —, bien que cela puisse être contrôlé si un SecurityManager est installé. Deuxièmement, ces paramètres seront utilisés pour toutes les sockets SSL créés via le "par défaut" SSLContext. Si vous avez besoin d'informations d'identification différentes pour différents terminaux, vous aurez besoin d'une solution spécifique à Mirth.

Aucun point de départ n'a été spécifié dans la question, mais si vous partez de zéro, l'approche la plus simple consiste à créer un nouveau magasin de clés Java (format «JKS») et à générer une nouvelle paire de clés et un CSR. Après avoir envoyé le CSR à l'autorité de certification et récupéré un certificat, importez-le dans le même magasin de clés. Ce magasin de clés est prêt à l'emploi.

Si un certificat est déjà disponible, il est susceptible d'être stocké avec sa clé privée correspondante au format PKCS   # 12 (fichier .p12 ou .pfx). Ceux-ci peuvent être utilisés directement par une application Java, mais la propriété javax.net.ssl.keyStoreType devra être définie sur "PKCS12"

Answer 3

Je suis en retard un peu ici pour cela mais en fait il y a une possibilité que cela pourrait. En envoyant quelques paramètres de configuration à la machine virtuelle Java, vous pouvez faire en sorte que le moteur SOAP sous-jacent passe en HTTP et fournisse le certificat approprié.

se réfèrent à cette question pour plus de détails sur les paramètres à définir pour la configuration de la machine virtuelle

Java HTTPS client certificate authentication

vous remarquerez qu'il ya assez peu de choses à prendre en charge. Normalement, les protocoles HTTP et l'authentification des clients devraient "fonctionner" une fois que vous avez configuré vos certificats de manière appropriée.MAIS il y a quelques serveurs qui ne sont pas si amicaux aux clients de style B2B donc vous devez faire attention. En utilisant JDK 6_21 et quelques ajustements avec le certificat, j'ai réussi à faire fonctionner un de ces serveurs mais c'était long et douloureux de notre côté pour quelque chose qui prend environ 15 minutes à configurer correctement sur le serveur.

Voici une autre question qui aborde ce problème (authentification côté client vers des serveurs hostiles).

Client SSL authentication causing 403.7 error from IIS