web-dev-qa-db-de.com

zertifikat, dem Websphere nicht vertraut

Ich habe eine Webanwendung, die einen SOAP - Webdienst aufruft, der durch SSL gesichert ist .(https://zzzzzzzzzzzz/xxxxx). 

Der Server sendet zwei Zertifikate (Root und Leaf), also importiere ich das zwei Zertifikat mit der Eigenschaft: com.ibm.websphere.ssl.retrieveLeafCert.

Um die SSL-Validierung in Websphere zu aktivieren, füge ich die Zertifikate einfach in Websphere hinzu: 

Verwaltung von SSL-Zertifikaten und Schlüsseln -> Schlüsselspeicher und Zertifikat -> NodeDefaultTrustStore -> Signer-Zertifikate -> Von Port abrufen: 

  • Host: Hostname 
  • hafen: 443
  • alias: Alias

Das Problem ist, dass webshphere dem Zertifikat nicht vertraut und mir diesen Stacktrace gibt. 

used by: javax.net.ssl.SSLHandshakeException: SSLHandshakeException invoking `https://------------------------------` : com.ibm.jsse2.util.j: PKIX path building failed: Java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: 
    Java.security.cert.CertPathValidatorException: T`he certificate issued by CN=-------------------------------------------------------------------- is not trusted`; internal cause is: 
    Java.security.cert.CertPathValidatorException: Certificate chaining error
    at Sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.6.0]
    at Sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.Java:56) ~[na:1.6.0]
    at Sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.Java:39) ~[na:1.6.0]
    at Java.lang.reflect.Constructor.newInstance(Constructor.Java:527) ~[na:1.6.0]
    at org.Apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.mapException(HTTPConduit.Java:1338) ~[cxf-rt-transports-http-2.7.4.jar:2.7.4]
    at org.Apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.Java:1322) ~[cxf-rt-transports-http-2.7.4.jar:2.7.4]
    at org.Apache.cxf.transport.AbstractConduit.close(AbstractConduit.Java:56) ~[cxf-api-2.7.4.jar:2.7.4]
    at org.Apache.cxf.transport.http.HTTPConduit.close(HTTPConduit.Java:622) ~[cxf-rt-transports-http-2.7.4.jar:2.7.4]
    at org.Apache.cxf.interceptor.MessageSenderInterceptor$MessageSenderEndingInterceptor.handleMessage(MessageSenderInterceptor.Java:62) ~[cxf-api-2.7.4.jar:2.7.4]
    at org.Apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.Java:271) ~[cxf-api-2.7.4.jar:2.7.4]
    at org.Apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.Java:530) ~[cxf-api-2.7.4.jar:2.7.4]
    at org.Apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.Java:463) ~[cxf-api-2.7.4.jar:2.7.4]
    at org.Apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.Java:366) ~[cxf-api-2.7.4.jar:2.7.4]
    at org.Apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.Java:319) ~[cxf-api-2.7.4.jar:2.7.4]
    at org.Apache.cxf.endpoint.ClientImpl.invokeWrapped(ClientImpl.Java:354) ~[cxf-api-2.7.4.jar:2.7.4]
    at org.Apache.cxf.jaxws.DispatchImpl.invoke(DispatchImpl.Java:385) ~[cxf-rt-frontend-jaxws-2.7.4.jar:2.7.4]
    ... 100 common frames omitted
`Caused by: javax.net.ssl.SSLHandshakeException`: com.ibm.jsse2.util.j: PKIX path building failed: Java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: 
    Java.security.cert.CertPathValidatorException: `The certificate issued by CN=--------------------------------------------------------- is not trusted`; internal cause is: 
    Java.security.cert.CertPathValidatorException: Certificate chaining error
    at com.ibm.jsse2.o.a(o.Java:8) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.Java:549) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.kb.a(kb.Java:355) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.kb.a(kb.Java:130) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.lb.a(lb.Java:135) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.lb.a(lb.Java:368) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.kb.s(kb.Java:442) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.kb.a(kb.Java:136) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.Java:495) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.SSLSocketImpl.h(SSLSocketImpl.Java:223) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.SSLSocketImpl.a(SSLSocketImpl.Java:724) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.SSLSocketImpl.startHandshake(SSLSocketImpl.Java:81) ~[na:6.0 build_20130515]
    at com.ibm.net.ssl.www2.protocol.https.c.afterConnect(c.Java:8) ~[na:6.0 build_20130515]
    at com.ibm.net.ssl.www2.protocol.https.d.connect(d.Java:20) ~[na:6.0 build_20130515]
    at Sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.Java:1043) ~[na:1.6.0]
    at com.ibm.net.ssl.www2.protocol.https.b.getOutputStream(b.Java:85) ~[na:6.0 build_20130515]
    at org.Apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.setupWrappedStream(URLConnectionHTTPConduit.Java:168) ~[cxf-rt-transports-http-2.7.4.jar:2.7.4]
    at org.Apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.handleHeadersTrustCaching(HTTPConduit.Java:1282) ~[cxf-rt-transports-http-2.7.4.jar:2.7.4]
    at org.Apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.onFirstWrite(HTTPConduit.Java:1233) ~[cxf-rt-transports-http-2.7.4.jar:2.7.4]
    at org.Apache.cxf.transport.http.URLConnectionHTTPConduit$URLConnectionWrappedOutputStream.onFirstWrite(URLConnectionHTTPConduit.Java:195) ~[cxf-rt-transports-http-2.7.4.jar:2.7.4]
    at org.Apache.cxf.io.AbstractWrappedOutputStream.write(AbstractWrappedOutputStream.Java:47) ~[cxf-api-2.7.4.jar:2.7.4]
    at org.Apache.cxf.io.AbstractThresholdOutputStream.write(AbstractThresholdOutputStream.Java:69) ~[cxf-api-2.7.4.jar:2.7.4]
    at org.Apache.cxf.transport.http.HTTPConduit$WrappedOutputStream.close(HTTPConduit.Java:1295) ~[cxf-rt-transports-http-2.7.4.jar:2.7.4]
    ... 110 common frames omitted
`Caused by: com.ibm.jsse2.util.j: PKIX path building failed:` Java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.; internal cause is: 
    Java.security.cert.CertPathValidatorException: T`he certificate issued by CN=--------------------------------------------  is not trusted`; internal cause is: 
    Java.security.cert.CertPathValidatorException: Certificate chaining error
    at com.ibm.jsse2.util.h.b(h.Java:39) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.util.h.b(h.Java:21) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.util.g.a(g.Java:1) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.pc.a(pc.Java:36) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.pc.checkServerTrusted(pc.Java:19) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.pc.b(pc.Java:51) ~[na:6.0 build_20130515]
    at com.ibm.jsse2.lb.a(lb.Java:65) ~[na:6.0 build_20130515]
    ... 128 common frames omitted
Caused by: Java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl could not build a valid CertPath.
    at com.ibm.security.cert.PKIXCertPathBuilderImpl.engineBuild(PKIXCertPathBuilderImpl.Java:411) ~[na:na]
    at Java.security.cert.CertPathBuilder.build(CertPathBuilder.Java:258) ~[na:na]
    at com.ibm.jsse2.util.h.b(h.Java:107) ~[na:6.0 build_20130515]
    ... 134 common frames omitted
Caused by: Java.security.cert.CertPathValidatorException: The certificate issued by CN=-------------------------------------------------------
    at com.ibm.security.cert.BasicChecker.<init>(BasicChecker.Java:111) ~[na:na]
    at com.ibm.security.cert.PKIXCertPathValidatorImpl.engineValidate(PKIXCertPathValidatorImpl.Java:178) ~[na:na]
    at com.ibm.security.cert.PKIXCertPathBuilderImpl.myValidator(PKIXCertPathBuilderImpl.Java:737) ~[na:na]
    at com.ibm.security.cert.PKIXCertPathBuilderImpl.buildCertPath(PKIXCertPathBuilderImpl.Java:649) ~[na:na]
    at com.ibm.security.cert.PKIXCertPathBuilderImpl.buildCertPath(PKIXCertPathBuilderImpl.Java:595) ~[na:na]
    at com.ibm.security.cert.PKIXCertPathBuilderImpl.engineBuild(PKIXCertPathBuilderImpl.Java:357) ~[na:na]
    ... 136 common frames omitted
Caused by: Java.security.cert.CertPathValidatorException: Certificate chaining error
    at com.ibm.security.cert.CertPathUtil.findIssuer(CertPathUtil.Java:298) ~[na:na]
    at com.ibm.security.cert.BasicChecker.<init>(BasicChecker.Java:108) ~[na:na]
    ... 141 common frames omitted

Derselbe Code wird in meiner lokalen Umgebung mit der einfachen Verwendung von Installcert.Java getestet und meine Tests werden mit -Djavax.net.ssl.trustStore = jssecacerts ausgeführt (jssecacerts ist die von InstallCert.Java erzeugte Datei). 

javasecuritysslhttpswebsphere
7
Nabil

Ich teste eine Million Websphere-Konfiguration. 

Das einzige Verfahren, das funktioniert, ist das in diesem Link beschriebene Verfahren: 

http://blog.xebia.com/2012/10/01/mutual-ssl-authentication-using-websphere-application-server-and-cxf/

Durch die Definition des Cxf-Intercpter: 

<cxf:bus>
 <cxf:outInterceptors>
   <bean class="---------------------.WebsphereSslOutInterceptor" />
</cxf:outInterceptors>
</cxf:bus>

Weitere Einzelheiten finden Sie unter: 

https://github.com/vlussenburg/websphere-cxf-extensions#websphere-cxf-extensions

Vielen Dank für Ihre Hilfe, Jungs. 

3
Nabil

Vielen Dank für all die oben genannte Antwort. Kann das Problem Java.security.cert.CertPathValidatorException: Fehler bei der Zertifikatsverkettung mit der folgenden Konfiguration beheben.

  1. Es wurde festgestellt, dass die folgenden javax-Eigenschaften in WebSphere ..__ einen Nullwert zurückgegeben haben.
    • javax.net.ssl.trustStore, 
    • javax.net.ssl.trustStorePassword 
    • javax.net.ssl.trustStoreType

Weitere Informationen finden Sie unter diesem Link.

Java - Pfad zu trustStore - Set - Eigenschaft funktioniert nicht?

  1. Konfigurieren Sie die Eigenschaften wie unten in WebSphere angegeben

    Wählen Sie Server> Anwendungsserver> Servername> Prozessdefinition> Java Virtual Machine> Benutzerdefinierte Eigenschaften> Neu.

a) javax.net.ssl.trustStore = jre_install_dir\lib\security\cacerts

Beispiel: C:\Programme\WebSphere\AppServer\Java\jre\lib\security\cacerts

b) javax.net.ssl.trustStorePassword = changeit (Standardeinstellung)

c) javax.net.ssl.trustStoreType = jks

Weitere Informationen finden Sie unter diesem Link.

http://publib.boulder.ibm.com/infocenter/tivihelp/v2r1/index.jsp?topic=%2Fcom.ibm.isim.doc_6.0%2Finstalling%2Ftsk%2Ftsk_ic_ins_first_security_truststore.htm

Nachdem die Konfiguration in den Protokollen sehen konnte, dass Zertifikate zum Vertrauensspeicher hinzugefügt werden.

Danke, __. Uday Nilajkar

10
user3458628

Vielleicht solltest du dir folgende technote anschauen.

Wenn Sie sich auf einem bestimmten Fixpack-Level befinden, können Sie den Wert com.ibm.websphere.ssl.retrieveLeafCert auf true setzen und das Blattzertifikat erhalten, wenn Abrufen von Port.

0
trikelef

Führen Sie die folgenden Schritte aus, um ein Zertifikat in denJVMfür einen HTTPS WS-Aufruf zu importieren:

A) Erhalten Sie das zu importierende Zertifikat

  1. Jeder Browser zeigt Zertifikate auf unterschiedliche Weise an, aber sie sind sich normalerweise sehr ähnlich. In der URL-Leiste des Browsers befindet sich normalerweise eine Zone, auf die Sie klicken können, um Informationen zum SSL-Zertifikat anzuzeigen. Beispielsweise wird in der Statusleiste möglicherweise ein Vorhängeschloss angezeigt. Wenn Sie auf das Vorhängeschloss klicken, werden die Zertifikatsinformationen geöffnet. Wenn die Zertifikatsinformationen geöffnet sind, klicken Sie auf "Zertifizierungspfad". Normalerweise gibt es eine Möglichkeit, jedes Signaturzertifikat (vertrauenswürdige Wurzeln) zu exportieren. Exportieren Sie die Zertifizierer im Format "Base-64-codiertes X.509 (.CER)" . Die exportierte Datei in diesem Format ist eine Textdatei ASCII mit den Zeilen "BEGIN CERTIFICATE" und "END CERTIFICATE" oben und unten. Nachdem Sie die Zertifikate exportiert haben, die das SSL-Zertifikat des Remote-Servers signiert haben, können Sie sie in die JVM importieren.

B) Importiere das Zertifikat

  1. Starten Sie das Dienstprogramm ikeyman. Das Dienstprogramm (ikeyman.bat oder ikeyman.sh) befindet sich im WAS_HOME\bin.
  2. Wählen Sie im Menü Schlüsseldatenbankdatei die Option Öffnen aus.
  3. Wählen Sie im Schlüsseldatenbanktyp JKS aus.
  4. Geben Sie im Feld Dateiname cacerts ein.
  5. Geben Sie im Feld Location den Namen WAS_HOME\Java\jre\lib\security ein.
  6. Geben Sie im Fenster Kennworteingabe das Kennwort für den Schlüsselspeicher in das Fenster Kennwort und Kennwort bestätigen ein. Das Standardkennwort lautet changeeit ..__ Klicken Sie auf OK.
  7. Fügen Sie das Zertifikat, das Sie für den LDAP-Server erstellt haben, diesem Zertifikatspeicher hinzu.
  8. Wählen Sie im Hauptfenster im Bereich Schlüsseldatenbankinhalt Signerzertifikate aus der Liste aus. Klicken Sie auf Hinzufügen.
  9. Durchsuchen Sie im Feld Zertifikatdateiname die Serverzertifikatdatei, die für den LDAP-Server erstellt wurde, die sich in Binary Der-Daten befindet. Stellen Sie sicher, dass das entsprechende Verzeichnis im Feld Standort angezeigt wird. Klicken Sie auf OK.
  10. Geben Sie in der Eingabeaufforderung eine Bezeichnung für dieses Zertifikat ein. Geben Sie beispielsweise LDAPCA ..__ ein. Klicken Sie auf OK.
0
edubriguenti

Sie sollten alle Zertifikatsketten in Ihrer Konfiguration hinzufügen. Normalerweise hat das Zertifikat mindestens das Stammzertifikat des Authorization Centers oder kettenähnliche Zertifikate.

WAS erfordert standardmäßig ein signiertes Zertifikat. 

0
Anton Novopashin

Das Problem hierbei ist, dass der Zertifikatspfad-Generator (Ein Teil der Java Cert-Pfad-API) die Zertifikatskette während des SSL-Handshakes nicht erstellen kann. Während des Handshakes sendet der SSL-Peer-Host sein Zertifikat (Identität) an den Client. Damit der Client diesem bestimmten Zertifikat vertrauen kann, muss auf der Clientseite eine Vertrauenskette aufgebaut werden, die beim Auftreten des Fehlers geschieht. Das Problem hierbei ist, dass die Vertrauenskette nicht erstellt werden kann, da entweder das Unterzeichnerzertifikat und/oder das Stammzertifikat in Ihrem Truststore (Vertrauensanker) fehlt. 

Beachten Sie, dass der PKIX-Trustmanager eine Gültigkeitsüberprüfung durchführt, was bedeutet, dass Sie keine vollständige Zertifikatskette auf der Clientseite benötigen, um die Vertrauensbeziehung mit dem SSL-Peer zu erfüllen. Sie benötigen nur die Unterzeichner/Zwischenzertifikate in Ihrem Truststore . Wenn Sie das Blattzertifikat im Truststore ablegen sollten, sollte dies auch funktionieren, da dies besagt, dass Sie explizit auf dieses bestimmte Zertifikat vertrauen und eine Zertifikatskettenvalidierung nicht erforderlich ist.

0
Robert Höglund