Eccezione I / O di ColdFusion CFHTTP: peer non autenticato, anche dopo aver aggiunto certificati al Keystore

Question

Attualmente sto lavorando con un processore di pagamento. Posso accedere all'URL di pagamento dal nostro server, quindi non è un problema di firewall, ma quando provo a utilizzare CFHTTP ottengo un'eccezione I / O: peer non autenticato. Ho scaricato e installato il loro ultimo certificato di sicurezza nel keystore cacerts e ho riavviato CF e sto ancora ottenendo lo stesso errore. Non solo ho installato i provider cert, ma anche le altre 2 autorità di certificazione Verisign nella catena di certificati. Il certificato è uno dei più recenti certificati di convalida estesa di classe 3.

Qualcuno l'ha mai trovato prima e ha trovato una soluzione?

Answer 1

Un mio collega ha riscontrato quanto segue dopo aver riscontrato lo stesso problema durante la connessione a una terza parte.

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/

Abbiamo usato la soluzione fornita nel commento di Pete Freitag più in basso nella pagina. Funziona, ma penso che dovrebbe essere usato con cautela, poiché comporta la rimozione e l'aggiunta dinamica di una particolare proprietà del provider JsafeJCE.

Per motivi di archiviazione, ecco il contenuto originale del commento di Pete Freitag:

  

Ho ridotto ulteriormente questo aspetto e rimuovendo il file   KeyAgreement.DiffieHellman del provider RSA JsafeJCE (che   fa sì che venga utilizzata l'implementazione Sun predefinita)   funziona e probabilmente ha un effetto minore sul server rispetto alla rimozione   l'intero fornitore lo farebbe. Ecco come lo fai:

<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)>

     

L'ho capito usando SSLSocketFactory per creare un https   connessione, che ha fornito un po 'più di dettagli nella traccia dello stack, rispetto a   quando si utilizza 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)

     

Sarebbe fantastico se l'eccezione generata da ColdFusion fosse un po 'meno   generico.

Answer 2

L'hai aggiunto al keystore corretto? Ricorda che ColdFusion utilizza la propria istanza Java. Ho trascorso diverse ore su questo una volta prima di ricordare quel fatto. Quello che vuoi è da qualche parte come / ColdFusion8 / runtime / jre / lib / security /

Answer 3

specifico per coldfusion 8 con un server web con cifrature SSL moderne:

Uso coldfusion 8 su JDK 1.6.45 e ho avuto problemi a darmi solo croci rosse anziché immagini, e anche con cfhttp non sono riuscito a connettermi al server web locale con ssl.

il mio script di test da riprodurre con coldfusion 8 era

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

questo mi ha dato l'errore abbastanza generico di " Eccezione I / O: peer non autenticato. & Quot; Ho quindi provato ad aggiungere certificati del server inclusi i certificati root e intermedi al keystore java e anche al keystore coldfusion, ma nulla mi ha aiutato. quindi ho eseguito il debug del problema con

java SSLPoke www.onlineumfragen.com 443

e ottenuto

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

e

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

Ho quindi avuto l'idea che il server web (apache nel mio caso) avesse cifre molto moderne per ssl ed è piuttosto restrittivo (il punteggio di qualys a +) e usa chiavi hellmann diffie forti con più di 1024 bit. ovviamente, coldfusion e java jdk 1.6.45 non possono gestirlo. Il passo successivo nell'odissea è stato pensare all'installazione di un fornitore di sicurezza alternativo per Java, e ho deciso per il castello gonfiabile. vedi anche http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for -java-JSE progetti /

Ho quindi scaricato

bcprov-ext-jdk15on-156.jar

da http://www.bouncycastle.org/latest_releases.html e installato sotto C: \ jdk6_45 \ jre \ lib \ ext o dovunque sia il tuo jdk, nell'installazione originale di coldfusion 8 sarebbe sotto C: \ JRun4 \ jre \ lib \ ext ma uso un jdk più recente (1.6.45) situato all'esterno la directory coldfusion. è molto importante mettere bcprov-ext-jdk15on-156.jar nella directory \ ext (questo mi è costato circa due ore e dei capelli ;-) poi ho modificato il file C: \ jdk6_45 \ jre \ lib \ security \ java.security (con wordpad non con editor.exe!) e ho inserito una riga per il nuovo provider. successivamente la lista sembrava

#
# 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

(vedi il nuovo in posizione 1)

quindi riavviare completamente il servizio coldfusion. puoi quindi

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

e goditi la sensazione ... e naturalmente

che notte e che giorno. Spero che questo possa aiutare (parzialmente o completamente) a qualcuno là fuori. se hai domande, mandami una mail a info ... (dominio sopra).

Answer 4

Prova con questo in CMD

C: \ ColdFusion9 \ runtime \ jre \ bin > keytool -import -keystore ../lib/security/cacerts  -alias uniquename -file certificatename.cer

Nota: dobbiamo scegliere il keystore corretto presente all'interno della cartella di sicurezza, poiché ci sono altri file keystore presenti all'interno del bin. Se importeremo il certificato in quei keystore non funzionerà.

Answer 5

Ciò che ho appena scoperto è stato citato in questo articolo: http: //kb2.adobe .com / cps / 400 / kb400977.html e alcuni altri posti dopo molte ricerche.

Se stai guardando questo articolo, molto probabilmente hai inserito il tuo " server.crt " certificato nelle posizioni root appropriate e probabilmente lo hai inserito nel file cacerts in / ColdFusion9 / runtime / jre / lib / security usando il comando

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

(se non l'hai ancora fatto, fallo ora). La cosa in cui mi imbattevo era che stavo configurando ssl sul mio localhost, quindi dopo aver fatto questi passaggi continuavo a ricevere lo stesso errore.

A quanto pare, devi anche inserire il tuo " server.crt " nella sezione "trustStore" file che si trova comunemente in / ColdFusion9 / runtime / jre / lib usando il comando

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

Speriamo che questo salverà qualcuno.

Answer 6

Sto usando JRun. Dopo aver provato molte cose diverse mi sono imbattuto in un frammento di informazioni che era applicabile nella mia configurazione. Avevo configurato un (1) HTTPS SSLService con il mio file truststore. Ciò ha reso importante l'informazione nel seguente link.

http://helpx.adobe.com/ coldfusion / kb / Import-certificati-Certificate-negozi-coldfusion.html

  

Nota: se si utilizza JRun come server J2EE sottostante (o   Configurazione server o Multiserver / J2EE con configurazione JRun)   e hai abilitato SSL per il server Web JRun interno (JWS), lo farai   è necessario importare il certificato nel truststore definito in   File jrun.xml per Secure JWS anziché per l'archivio chiavi JRE. Di   per impostazione predefinita, il file si chiama " trustStore " e si trova in genere   sotto jrun_root / lib per Multiserver / J2EE con configurazione JRun   oppure cf_root / runtime / lib per la configurazione di ColdFusion Server. tu   usa lo stesso keytool Java per gestire il trustStore.

Ecco l'estratto del mio file 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>

Una volta importato il certificato in questo truststore (/app/jrun4/cert/truststore.jks) ha funzionato dopo aver riavviato ColdFusion.

---

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

Answer 7

L'aggiunta del certificato al keystore non ha funzionato per me su CF9 Enterprise.

Finito con il tag CFX, CFX_HTTP5 .