2016-05-25 4 views
1

Ich habe eine funktionierende App, die eine Verbindung zu vielen externen Diensten herstellt. Ich füge einen neuen SOAP-Client hinzu, der eine Client-Authentifizierung erfordert. Ich kann es zum Laufen bringen, aber nicht ohne andere Dinge in der App zu brechen, also bin ich wirklich verwirrt darüber, was vor sich geht. Einige schnelle Hintergründe:Java Client Zertifikatskonflikt

  1. Wir verwenden die Standardcacerts-Datei und haben dort viele vertrauenswürdige Zertifikate importiert.
  2. Wir haben einen privaten Schlüssel erstellt, eine Zertifikatsanforderung generiert, ein Zertifikat zurückerhalten und eine p12-Datei mit dem Zertifikat und dem privaten Schlüssel erstellt, die für die Clientauthentifizierung verwendet werden.
  3. Wenn wir diese p12-Datei als Schlüsselspeicher für die App geben Sie den SOAP-Client funktioniert:

-Djavax.net.ssl.keyStore = "keystore.p12" -Djavax.net.ssl.keyStorePassword =“ Passwort“-Djavax.net.ssl.keyStoreType = "pkcs12"

  1. Wenn wir die oben nicht tun, sondern importieren diese in die Datei cacerts tun:

keytool -importkeystore -srckeystore keystore.p12 -deskeystore cacerts -srcstoretypkkcs12

es funktioniert nicht! Es funktioniert auch nicht, wenn wir dies tun und cacerts als Keystore pro Schritt 3 angeben (mit Ausnahme des letzten Arguments, da es sich um einen anderen Geschäftstyp handelt, richtig?)

So, mit den Schritten 1-3 haben wir unsere neue Integration funktioniert , aber das Problem ist, dass andere Sachen in der App jetzt brechen! Vorher wurde kein anderer Keystore angegeben (mein Verständnis ist, dass er ohnehin auf cacerts voreingestellt ist). Wir haben jetzt Fehler wie mit AWS SES (E-Mail) Service Ausnahmen wie Werfen:

  • java.lang.RuntimeException: Kann nicht instanziiert Instanz der Klasse com.amazonaws.services.simpleemail.AmazonSimpleEmailServiceClient
  • com .amazonaws.AmazonClientException: Kann nicht Zugriff Standard-SSL-Kontext
  • java.security.NoSuchAlgorithmException: Fehler der Konstruktion Implementierung (Algorithmus: Standard, provider: SunJSSE, Klasse: sun.security.ssl.SSLContextImpl $ DefaultSSLContext)
  • java.security .UnrecoverableKeyException: Schlüssel
  • kann nicht wiederhergestellt werden

Kann mir jemand erklären, was diesen Konflikt verursacht und wie er gelöst werden kann? Vielen Dank für Ihre Hilfe!

Jeff

+0

Haben Sie überprüft, ob Sie über Administratorrechte für den Zugriff auf jre-Sicherheitsbibliotheken/-ordner verfügen?Manchmal, wenn Sie keine Administratorrechte haben, können Sie diese Art von Ausnahmen erhalten. –

+0

Cacerts ist der Trust Store nicht der Schlüsselspeicher. – beny23

+0

Ich habe Zugang zu cacerts - ich habe hinzugefügt, um vertrauenswürdig dort vorher und das hat gut funktioniert. Ich bin verwirrt über den Unterschied zwischen einem Schlüssel und Trust Store. Konzeptionell verstehe ich es, aber wenn ich einen bestimmten Schlüsselspeicher spezifiziere, bricht anderes Zeug und nichts anderes wird konfiguriert. Pro Java-Dokumente und meine Dateien sieht es so aus, als sollte es auch für den Keystore auf cacerts fallen. – Jeff057

Antwort

0

nicht sicher, aber wahrscheinlich:

JKS-Format ein Passwort auf einem privatekey Eintrag unterscheidet sich von dem Passwort auf der enthaltenden Speicher (Datei), aber viele Anwendungen einschließlich aller mit javax.net.ssl.keyStore* Eigenschaften haben können, nicht Regle dies.

Entweder sicherstellen, dass das Pre-Import-Passwort auf dem p12 (das ist ein einziges Passwort für den Speicher und den Schlüssel) ist das gleiche wie das Speicher-Passwort auf dem Ziel jks (für cacerts wie installiert ist) oder zu spezifizieren beide -deststorepass -destkeypass mit dem gleichen Wert.

+0

Danke Dave. Ich habe es müde gemacht, den p12 mit dem Passwort "changeit" neu zu generieren, wieder in cacerts importiert (denselben Alias ​​überschrieben) und hatte das gleiche Ergebnis. Irgendwelche anderen Gedanken? – Jeff057

+0

@ Jeff057: das ist überraschend. Bitte versuchen Sie 'keytool -keystore cacerts -certreq -alias $ name' und sehen Sie, wofür Sie aufgefordert werden: nur das Schlüsselspeicher-Passwort oder auch das Schlüssel-Passwort. (Ich weiß, dass wir keine weitere CSR _wünschen_ wollen; verwerfen Sie jede Ausgabe. Dies ist nur ein Test.) Wenn 'keytool' in der Lage ist, nur über den Store-Pass -ward zuzugreifen, sollte JSSE auch. –

+0

Nochmals vielen Dank für die Antwort Dave! Ich führte den Befehl aus und es forderte nur das Keystore-Kennwort (changeit) und es druckte dann das Zertifikat. Also * sollte * funktionieren, aber nicht ... – Jeff057