Exception d'E / S ColdFusion CFHTTP: homologue non authentifié, même après l'ajout de certificats à Keystore

Question

Je travaille actuellement avec un processeur de paiement. Je peux accéder à l'URL de paiement depuis notre serveur. Ce n'est donc pas un problème de pare-feu, mais lorsque j'essaie d'utiliser CFHTTP, j'obtiens une exception E / S: homologue non authentifié. J'ai téléchargé et installé leur dernier certificat de sécurité dans le magasin de clés cacerts, puis j'ai redémarré CF et j'obtiens toujours la même erreur. Non seulement j'ai installé le cert du fournisseur, mais également les 2 autres certificats de l'autorité de certification Verisign dans la chaîne de certificats. Le certificat est l’un des nouveaux certificats de validation étendue de classe 3.

Quelqu'un at-il déjà rencontré ce problème et trouvé une solution?

Answer 1

Un de mes collègues a découvert ce qui suit après avoir rencontré le même problème lors d’une connexion à une tierce partie.

http://www.coldfusionjedi.com/index.cfm/2011/1/12/Diagnosing-a-CFHTTP-issue--peer-not-authenticated

https: // www.raymondcamden.com/2011/01/12/Diagnosing-a-CFHTTP-issue-peer-not-authenticated/

Nous avons utilisé la solution fournie dans le commentaire de Pete Freitag plus loin dans la page. Cela fonctionne, mais je pense qu’il faut utiliser avec prudence, car cela implique de supprimer et d’ajouter de manière dynamique une propriété particulière du fournisseur JsafeJCE.

Par souci d'archivage, voici le contenu original du commentaire de Pete Freitag:

  

Je l'ai réduit un peu plus loin, et en retirant le   KeyAgreement.DiffieHellman du fournisseur RSA JsafeJCE (qui   utilise l’implémentation sun par défaut à la place)   fonctionne, et a probablement moins d’effet sur votre serveur que de le supprimer   l'ensemble du fournisseur le ferait. Voici comment vous le faites:

<cfset objSecurity = createObject("java", "java.security.Security") />
<cfset storeProvider = objSecurity.getProvider("JsafeJCE") />
<cfset dhKeyAgreement = storeProvider.getProperty("KeyAgreement.DiffieHellman")>
<!--- dhKeyAgreement=com.rsa.jsafe.provider.JSA_DHKeyAgree --->
<cfset storeProvider.remove("KeyAgreement.DiffieHellman")>

Do your http call, but pack the key agreement if you want:

<cfset storeProvider.put("KeyAgreement.DiffieHellman", dhKeyAgreement)>

     

J'ai compris cela en utilisant SSLSocketFactory pour créer un https   connexion, qui fournit un peu plus de détails dans la trace de la pile, que   lors de l'utilisation de cfhttp:

yadayadayada Caused by: java.security.InvalidKeyException: Cannot
build a secret key of algorithm TlsPremasterSecret at
com.rsa.jsafe.provider.JS_KeyAgree.engineGenerateSecret(Unknown
Source) at javax.crypto.KeyAgreement.generateSecret(DashoA13*..) at
com.sun.net.ssl.internal.ssl.DHCrypt.getAgreedSecret(DHCrypt.java:166)

     

Ce serait formidable si l'exception levée par ColdFusion était un peu moins   générique.

Answer 2

L'avez-vous ajouté au bon magasin de clés? N'oubliez pas que ColdFusion utilise sa propre instance Java. J'ai passé plusieurs heures à ce sujet une fois avant de m'en souvenir. Celui que vous voulez se trouve quelque part comme / ColdFusion8 / runtime / jre / lib / security /

Answer 3

spécifique à coldfusion 8 avec un serveur Web avec des algorithmes de chiffrement SSL modernes:

J'utilise coldfusion 8 sur JDK 1.6.45 et je ne pouvais pas me contenter de croix rouges au lieu d'images, et de cfhttp incapable de se connecter au serveur Web local avec SSL.

mon script de test à reproduire avec coldfusion 8 était

<CFHTTP URL="https://www.onlineumfragen.com" METHOD="get" ></CFHTTP>
<CFDUMP VAR="#CFHTTP#">

cela m’a donné l’erreur assez générique de " Exception d'E / S: homologue non authentifié. & Quot; J'ai ensuite essayé d'ajouter des certificats du serveur, y compris des certificats racine et intermédiaires, au magasin de clés Java et au magasin de clés coldfusion, mais rien n'y fait. puis j'ai débogué le problème avec

java SSLPoke www.onlineumfragen.com 443

et j'ai

javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair

et

Caused by: java.security.InvalidAlgorithmParameterException: Prime size must be
multiple of 64, and can only range from 512 to 1024 (inclusive)
    at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
    at java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
    at com.sun.net.ssl.internal.ssl.DHCrypt.<init>(DHCrypt.java:107)
    ... 10 more

J’ai alors eu l’idée que le serveur Web (Apache dans mon cas) avait des chiffrements très modernes pour ssl et qu’il était assez restrictif (qualys score a +) et utilisait de fortes clés Diffie Hellmann de plus de 1024 bits. évidemment, coldfusion et java jdk 1.6.45 ne peuvent pas gérer cela. La prochaine étape dans l'odysee était de penser à installer un fournisseur de sécurité alternatif pour Java, et j'ai opté pour un château gonflable. voir aussi http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for -java-jse-projects /

J'ai ensuite téléchargé le

bcprov-ext-jdk15on-156.jar

à partir de http://www.bouncycastle.org/latest_releases.html et l'a installé sous C: \ jdk6_45 \ jre \ lib \ ext ou où que soit votre jdk, lors de l'installation d'origine de coldfusion 8, il se trouverait sous C: \ JRun4 \ jre \ lib \ ext mais j'utilise un nouveau jdk (1.6.45) situé à l'extérieur le répertoire coldfusion. il est très important de mettre bcprov-ext-jdk15on-156.jar dans le répertoire \ ext (cela m’a coûté environ deux heures et quelques cheveux ;-) puis j'ai édité le fichier C: \ jdk6_45 \ jre \ lib \ security \ java.security (avec WordPad pas avec editor.exe!) et ai mis une ligne pour le nouveau fournisseur. ensuite, la liste ressemblait à

#
# List of providers and their preference orders (see above):
#
security.provider.1=org.bouncycastle.jce.provider.BouncyCastleProvider
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.mscapi.SunMSCAPI

(voir le nouveau en position 1)

puis redémarrez complètement le service coldfusion. vous pouvez alors

java SSLPoke www.onlineumfragen.com 443 (or of course your url!)

et profitez de la sensation ... et bien sur

quelle nuit et quelle journée. Espérons que cela aidera (partiellement ou totalement) quelqu'un. si vous avez des questions, écrivez-moi à info ... (domaine ci-dessus).

Answer 4

Essayez avec ceci dans CMD

C: \ ColdFusion9 \ runtime \ jre \ bin > keytool -import -keystore ../lib/security/cacerts  -alias nom-unique -fichier nom-certificat.cer

Remarque: nous devons choisir le fichier de clés correct présent dans le dossier de sécurité, car d'autres fichiers de fichiers de clés sont présents dans bin. Si nous importons le certificat dans ces magasins de clés, il ne fonctionnera pas.

Answer 5

Ce que je viens de découvrir est référencé dans cet article: http: //kb2.adobe .com / cps / 400 / kb400977.html et quelques autres endroits après de nombreuses fouilles.

Si vous consultez cet article, vous avez probablement inséré votre " server.crt " certificat dans les emplacements racine appropriés et vous l'avez probablement inséré dans le fichier cacerts dans / ColdFusion9 / runtime / jre / lib / security à l'aide de la commande

\ ColdFusion9 \ runtime \ jre \ bin \ keytool -import -v -alias someServer-cert -file someServerCertFile.crt -keystore cacerts -storepass changeit

(si vous ne l'avez pas encore fait, faites-le maintenant). Ce que je rencontrais, c’est que j’installe ssl sur mon hôte local, c’est pourquoi, après avoir suivi ces étapes, je reçois toujours la même erreur.

Comme il s'avère, vous devez également insérer votre "serveur.crt". dans le " trustStore " fichier généralement situé dans / ColdFusion9 / runtime / jre / lib à l’aide de la commande

\ColdFusion9\runtime\jre\bin\keytool -import -v -alias someServer-cert -file someServerCertFile.cer -keystore trustStore -storepass changeit

J'espère que cela fera gagner du temps à quelqu'un.

Answer 6

J'utilise JRun. Après avoir essayé beaucoup de choses différentes, je suis tombé sur un extrait d'information qui était applicable dans ma configuration. J'avais configuré un (1) service HTLS HTLS avec mon propre fichier de clés certifiées. Cela a rendu l’information contenue dans le lien suivant devenue importante.

http://helpx.adobe.com/ coldfusion / kb / import-certificats-certificate-stores-coldfusion.html

  

Remarque: Si vous utilisez JRun en tant que serveur J2EE sous-jacent (le   Configuration du serveur ou du multiserveur / J2EE avec configuration JRun)   et avez activé SSL pour le serveur Web interne JRun (JWS), vous allez   besoin d'importer le certificat dans le fichier de clés certifiées défini dans le   Fichier jrun.xml pour Secure JWS plutôt que le magasin de clés JRE. Par   Par défaut, le fichier est appelé "trustStore". et est généralement situé   sous racine_rrun / lib pour la configuration Multiserver / J2EE avec JRun   ou cf_root / runtime / lib pour la configuration de ColdFusion Server. Vous   utilisez le même outil de clé Java pour gérer le trustStore.

Voici l'extrait de mon fichier jrun.xml:

<service class="jrun.servlet.http.SSLService" name="SSLService">
  <attribute name="port">8301</attribute>
  <attribute name="keyStore">/app/jrun4/cert/cfusion.jks</attribute>
  <attribute name="trustStore">/app/jrun4/cert/truststore.jks</attribute>
  <attribute name="name">SSLService</attribute>
  <attribute name="bindAddress">*</attribute>
  <attribute name="socketFactoryName">jrun.servlet.http.JRunSSLServerSocketFactory</attribute>
  <attribute name="interface">*</attribute>
  <attribute name="keyStorePassword">cfadmin</attribute>
  <attribute name="deactivated">false</attribute>
</service>

Une fois le certificat importé dans ce fichier de clés certifiées (/app/jrun4/cert/truststore.jks), cela fonctionnait après le redémarrage de ColdFusion.

(1) http: //helpx.adobe .com / legacy / kb / ssl-jrun-web-server-connector.html

Answer 7

L'ajout du certificat au magasin de clés ne fonctionnait pas pour moi sur CF9 Enterprise.

Utilisation de la balise CFX CFX_HTTP5 .