Frage

Das Szenario um ruft eine externe SSL SOAP Webservice aus Mirth. Der Webservice ist erfordert eine SSL / TLS-Verbindung zusammen mit einem Client-Zertifikat.

Die Absicht ist es, die eingebaute in SOAP-Sender Destination zu verwenden, um den sicheren Remote-Web-Service anrufen, und irgendwie ist das Client-Zertifikat.

Ich verstehe, dass Sie zum ersten Mal, dass die Client-Zertifikat in den Java-Runtime installieren. Dies kann innerhalb der Java-Runtime-Zertifikatspeicher oder der Jetty certstore sein.

Die Plattform:

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

Frage : Welche Konfigurationsschritte (Mirth, JRE Zertifikatspeicher, etc.) würden Sie vorschlagen, um erfolgreich einen Mirth SOAP Sender haben, gehört ein Client-Zertifikat (* .cer), wenn ein Web-Service-Aufruf gesichert von SSL?

War es hilfreich?

Lösung 2

Mirth 1.8 kann kein Client-Zertifikat senden, wenn eine SOAP-Web-Service aufrufen.

Andere Tipps

Der Java-Runtime, oder genauer gesagt, Anbieter die Sun JSSE, wird ein Client-Zertifikat präsentieren, wenn einige Systemeigenschaften festgelegt werden. Einzelheiten entnehmen Sie bitte der JSSE Reference lesen Guide, aber die wichtigen Eigenschaften sind javax.net.ssl.keyStore und javax.net.ssl.keyStorePassword.

Es gibt ein paar Nachteile dieses Ansatzes. Zuerst als Systemeigenschaft des Schlüsselspeicher-Passworts macht es jeden Code zugänglich in diesem laufenden Prozess-obwohl dies gesteuert werden kann, wenn ein SecurityManager installiert ist. Zweitens werden diese Einstellungen für alle SSL-Sockets über die „default“ SSLContext erstellt verwendet werden. Wenn Sie andere Anmeldeinformationen für verschiedene Endpunkte benötigen, müssen Sie eine Mirth spezifische Lösung.

Es wurde kein Ausgangspunkt in der Frage angegeben, aber wenn von vorne anfängt, ist der einfachste Ansatz ein neuen Java Key Store ( „JKS“ Format) zu erstellen und ein neues Schlüsselpaar und eine CSR generieren. Nach der CSR an die CA zu senden und ein Zertifikat zurück erhalten, importieren Sie sie in der gleichen Schlüsselspeicher. Das Schlüsselspeicher ist nun einsatzbereit.

Wenn ein Zertifikat bereits vorhanden ist, ist es wahrscheinlich in einem mit seinem entsprechenden privaten Schlüssel im PKCS # 12-Format (P12 oder PFX-Datei) gespeichert werden. Diese können direkt von einer Java-Anwendung verwendet werden, aber die javax.net.ssl.keyStoreType Eigenschaft muß "PKCS12" zu setzen

Ich bin ein bisschen spät hier dafür, aber eigentlich gibt es eine Möglichkeit, dass es könnte. ein paar Konfigurationsparameter an die JVM Durch das Absenden der zugrunde liegende SOAP-Engine zu HTTPs und geben Sie die richtige Zertifikat wechseln konnte.

beziehen sich auf diese Frage Einzelheiten zu dem für die Konfiguration der VM setzen Parameter

Java HTTPS-Client-Zertifikat-Authentifizierung

werden Sie feststellen, es gibt durchaus ein paar Dinge zu kümmern. Normalerweise sollte HTTPs und Client-Authentifizierung „funktionieren“, wenn Sie Ihre Zertifikate entsprechend konfiguriert. Aber es gibt einige Server gibt, die auf B2B-Stil Kunden nicht so freundlich sind, so muss man aufpassen.

Mit JDK 6_21 und ein paar Veränderungen mit dem Zertifikat ich in der Lage war einen von ihnen Server zu verhalten zu bekommen, aber es war lang und schmerzhaft auf unserer Seite für etwas, das etwa 15 Minuten dauert, auf dem Server richtig zu konfigurieren.

hier ist eine andere Frage, die dieses sehr Problem (Client-Seite Authentifizierung gegenüber unfreundlich Server) Adresse.

Client-SSL-Authentifizierung verursacht 403.7 Fehler von IIS

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top