web-dev-qa-db-fra.com

certificat non approuvé par Websphere

J'ai une application Web qui appelle un service Web SOAP sécurisé via SSL .(https://zzzzzzzzzzzz/xxxxx). 

Le serveur envoie deux certificats (racine et feuille), donc j'importe les deux certificats en utilisant la propriété: com.ibm.websphere.ssl.retrieveLeafCert.

Pour activer la validation ssl sur Websphere, il suffit d’ajouter les certificats dans Websphere: 

Certificat SSL et gestion des clés -> Magasins de clés et certificat -> NodeDefaultTrustStore -> Certificats de signataire -> Récupérer du port: 

  • Hôte: nom d'hôte 
  • port: 443
  • alias: alias

Le problème est que webshphere ne fait pas confiance au certificat et me donne cette pile, 

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

Le même code est testé dans mon environnement local en utilisant simplement Installcert.Java et en exécutant mes tests avec -Djavax.net.ssl.trustStore = jssecacerts (jssecacerts est le fichier généré par InstallCert.Java). 

javasecuritysslhttpswebsphere
7
Nabil

J'ai testé une configuration d'un million de websphere. 

La seule procédure qui fonctionne est la procédure décrite dans ce lien: 

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

En définissant l'intercalaire cxf: 

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

Pour plus de détails, veuillez consulter: 

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

Merci beaucoup pour votre aide les gars. 

3
Nabil

Merci pour toute la réponse ci-dessus. Capable de résoudre le problème Java.security.cert.CertPathValidatorException: erreur lors de l'enchaînement des certificats avec la configuration suivante.

  1. Constatation que les propriétés javax suivantes ont renvoyé une valeur null dans WebSphere .
    • javax.net.ssl.trustStore, 
    • javax.net.ssl.trustStorePassword 
    • javax.net.ssl.trustStoreType

Pour plus de détails, s'il vous plaît voir ce lien,

Java - le chemin d'accès à trustStore - la propriété set ne fonctionne pas?

  1. Configuré les propriétés comme ci-dessous dans WebSphere

    Sélectionnez Serveurs> Serveurs d'applications> nom_serveur> Définition de processus> Machine virtuelle Java> Propriétés personnalisées> Nouveau.

a) javax.net.ssl.trustStore = rép_install_jre\lib\security\cacerts

Exemple: C:\Programmes\WebSphere\AppServer\Java\jre\lib\security\cacerts

b) javax.net.ssl.trustStorePassword = changeit (par défaut)

c) javax.net.ssl.trustStoreType = jks

Pour plus de détails, s'il vous plaît voir ce lien,

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

Une fois que la configuration a pu voir dans les journaux que les certificats étaient ajoutés au magasin de données de confiance.

Merci, Uday Nilajkar

10
user3458628

Peut-être devriez-vous regarder le note technique .

Si vous êtes à un certain niveau de groupe de correctifs, vous pouvez définir la valeur com.ibm.websphere.ssl.retrieveLeafCert sur true et obtenir le certificat feuille lorsque (Récupération du port.

0
trikelef

Voici les étapes à suivre pour importer un certificat dans JVM pour un appel HTTPS WS:

A) Obtenir le certificat à importer

  1. Chaque navigateur affiche les certificats de différentes manières, mais ils sont généralement très similaires. Dans la barre d'URL du navigateur, il y a généralement une zone sur laquelle vous pouvez cliquer pour afficher les informations du certificat SSL. Par exemple, vous pouvez voir un cadenas dans la barre d'état et cliquer sur le cadenas ouvre les informations du certificat. Une fois les informations du certificat ouvertes, cliquez sur les informations "Chemin de certification". Il existe normalement un moyen d'exporter chacun des certificats de signature (racines approuvées). Exportez les certificateurs au format "Format X.509 (.CER)" codé en base 64. Le fichier exporté dans ce format sera un fichier texte ASCII comportant les lignes "BEGIN CERTIFICATE" et "END CERTIFICATE" en haut et en bas. Une fois que vous avez exporté les certificats qui ont signé le certificat SSL du serveur distant, vous pouvez les importer dans la JVM.

B) Importer le certificat

  1. Démarrez l'utilitaire ikeyman. L'utilitaire (ikeyman.bat ou ikeyman.sh) se trouve dans le répertoire WAS_HOME\bin.
  2. Dans le menu Key Database File, sélectionnez Open.
  3. Dans le type de base de données de clés, sélectionnez JKS.
  4. Dans le champ Nom du fichier, tapez cacerts.
  5. Dans le champ Emplacement, tapez WAS_HOME\Java\jre\lib\security.
  6. Dans la fenêtre Invite de mot de passe, tapez le mot de passe du magasin de clés dans les fenêtres Mot de passe et Confirmer le mot de passe. Le mot de passe par défaut est changeit ..__ Cliquez sur OK.
  7. Ajoutez le certificat que vous avez créé pour le serveur LDAP dans ce magasin de certificats.
  8. Dans la fenêtre principale, dans la zone de contenu Base de données de clés, sélectionnez Certificats de signataire dans la liste . Cliquez sur Ajouter.
  9. Dans le champ Nom du fichier de certificat, parcourez et localisez le fichier de certificat de serveur créé pour le serveur LDAP, qui se trouve dans les données Binary Der. Vérifiez que le répertoire approprié est affiché dans le champ Emplacement ..__ Cliquez sur OK.
  10. Dans l'invite, tapez une étiquette pour ce certificat. Par exemple, tapez LDAPCA . Cliquez sur OK.
0
edubriguenti

Vous devez ajouter toutes les chaînes de certificats dans votre configuration. Habituellement, le certificat a au moins le certificat racine du centre d'autorisation ou des certificats similaires en chaîne.

WAS nécessite un certificat signé par défaut. 

0
Anton Novopashin

Le problème ici est que le générateur de chemin de certificat (une partie de l'API de chemin de certificat Java) ne peut pas construire la chaîne de certificats lors de l'établissement de la liaison SSL. Au cours de la négociation, l'hôte homologue SSL envoie son certificat (identité) au client. Pour que le client puisse faire confiance à ce certificat particulier, une chaîne de confiance doit être créée côté client, ce qui se produit lorsque vous obtenez l'erreur. Le problème ici est que la chaîne de confiance ne peut pas être créée car il manque le certificat de signataire et/ou le certificat racine dans votre magasin de clés de confiance (ancre de confiance). 

Notez que le gestionnaire de confiance PKIX effectue une validation "d'étendue de confiance", ce qui signifie que vous n'avez pas besoin d'une chaîne de certificats complète côté client pour remplir la relation de confiance avec l'homologue SSL. Vous aurez seulement besoin des certificats de signataire/intermédiaire dans votre magasin de clés de confiance. . En fait, si vous placiez le certificat feuille dans le fichier de clés certifiées, cela devrait également faire fonctionner les choses, car cela indique que vous avez une confiance explicite pour ce certificat particulier et qu'une validation de la chaîne de certificats n'est pas nécessaire.

0
Robert Höglund