ColdFusion CFHTTP I / O Exception: peer no autenticado, incluso después de agregar certificados a Keystore

https://stackoverflow.com/questions/1613038

06-07-2019
|

Pregunta

Actualmente estoy trabajando con un procesador de pagos. Puedo navegar a la URL de pago desde nuestro servidor, por lo que no es un problema de firewall, pero cuando intento usar CFHTTP obtengo una excepción de E / S: peer no autenticado. Descargué e instalé su último certificado de seguridad en el almacén de claves de cacerts y reinicié CF, y sigo recibiendo el mismo error. No solo he instalado el certificado de proveedores, sino también los otros 2 certificados de autoridad de certificación de Verisign en la cadena de certificados. El certificado es uno de los certificados de Validación Extendida Clase 3 más nuevos.

¿Alguien ha encontrado esto antes y ha encontrado una solución?

Solución

Un colega mío encontró lo siguiente después de experimentar el mismo problema al conectarse a un tercero.

~~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/

Usamos la solución provista en el comentario de Pete Freitag más abajo en la página. Funciona, pero creo que se debe usar con precaución, ya que implica eliminar y agregar dinámicamente una propiedad particular del proveedor JsafeJCE.

Por el bien del archivo, aquí está el contenido original del comentario de Pete Freitag:

He reducido esto un poco más, y eliminando el KeyAgreement.DiffieHellman del proveedor RSA JsafeJCE (que hace que se use la implementación predeterminada del sol en su lugar) funciona, y probablemente tenga menos efecto en su servidor que eliminar todo el proveedor lo haría. Así es como lo haces:
<cfset objSecurity = createObject("java", "java.security.Security") />
<cfset storeProvider = objSecurity.getProvider("JsafeJCE") />
<cfset dhKeyAgreement = storeProvider.getProperty("KeyAgreement.DiffieHellman")>

<cfset storeProvider.remove("KeyAgreement.DiffieHellman")>

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

<cfset storeProvider.put("KeyAgreement.DiffieHellman", dhKeyAgreement)>
Descubrí esto utilizando el SSLSocketFactory para crear un https conexión, que proporcionó un poco más detalles en el seguimiento de la pila, que cuando se utiliza 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)
Sería genial si la excepción lanzada desde ColdFusion fuera un poco menos genérico.

Otros consejos

¿Lo agregaste al almacén de claves correcto? Recuerda que ColdFusion usa su propia instancia de Java. Pasé varias horas en esto una vez antes de recordar ese hecho. El que desea está en algún lugar como / ColdFusion8 / runtime / jre / lib / security /

específico de coldfusion 8 con un servidor web con cifrados ssl modernos:

Uso coldfusion 8 en JDK 1.6.45 y tuve problemas al darme solo cruces rojas en lugar de imágenes, y también con cfhttp que no puede conectarse al servidor web local con ssl.

mi script de prueba para reproducir con coldfusion 8 era

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

esto me dio el error bastante genérico de " Excepción de E / S: peer no autenticado. & Quot; Luego intenté agregar certificados del servidor, incluidos los certificados raíz e intermedios, al almacén de claves de Java y también al almacén de claves de ColdFusion, pero nada ayudó. Luego depuré el problema con

java SSLPoke www.onlineumfragen.com 443

y obtuve

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

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

Luego tuve la idea de que el servidor web (apache en mi caso) tenía sistemas de cifrado muy modernos para ssl y es bastante restrictivo (calificación de calibre ays +) y utiliza claves de Hellmann con una fuerte diferencia de más de 1024 bits. Obviamente, coldfusion y java jdk 1.6.45 no pueden manejar esto. El siguiente paso en el odysee fue pensar en instalar un proveedor de seguridad alternativo para Java, y me decidí por el castillo hinchable. vea también http://www.itcsolutions.eu/2011/08/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for -java-jse-projects /

Luego descargué el

bcprov-ext-jdk15on-156.jar

de http://www.bouncycastle.org/latest_releases.html y lo instalé debajo C: \ jdk6_45 \ jre \ lib \ ext o donde quiera que esté su jdk, en la instalación original de coldfusion 8 estaría en C: \ JRun4 \ jre \ lib \ ext pero uso un jdk más nuevo (1.6.45) ubicado afuera El directorio de coldfusion. es muy importante colocar bcprov-ext-jdk15on-156.jar en el directorio \ ext (esto me costó aproximadamente dos horas y algo de pelo ;-) Luego edité el archivo C: \ jdk6_45 \ jre \ lib \ security \ java.security (con wordpad no con editor.exe!) y coloqué una línea para el nuevo proveedor. después la lista parecía

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

(ver el nuevo en la posición 1)

luego reinicie el servicio de ColdFusion completamente. entonces puedes

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

y disfruta de la sensación ... y por supuesto

qué noche y qué día. Esperemos que esto ayude (parcial o totalmente) a alguien por ahí. Si tiene alguna pregunta, envíeme un correo electrónico a info ... (dominio arriba).

Intenta con esto en CMD

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

Nota: debemos elegir el almacén de claves correcto presente dentro de la carpeta de seguridad, ya que hay otros archivos de almacén de claves presentes en el contenedor. Si importamos el certificado a esos almacenes de claves, no funcionará.

Lo que acabo de descubrir fue referenciado en este artículo: http: //kb2.adobe .com / cps / 400 / kb400977.html y algunos otros lugares después de mucho excavar.

Si está viendo este artículo, lo más probable es que haya insertado su " server.crt " certificado en las ubicaciones raíz correctas y probablemente lo haya insertado en el archivo cacerts en / ColdFusion9 / runtime / jre / lib / security usando el comando

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

(si no lo has hecho, hazlo ahora). Lo que estaba encontrando era que estaba configurando ssl en mi host local, así que después de seguir estos pasos seguía recibiendo el mismo error.

Resulta que también debe insertar su " server.crt " en el " trustStore " archivo comúnmente ubicado en / ColdFusion9 / runtime / jre / lib usando el comando

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

Espero que esto ahorre tiempo a alguien.

Estoy usando JRun. Después de probar muchas cosas diferentes, encontré un fragmento de información que era aplicable en mi configuración. Había configurado un (1) servicio SSLS HTTPS con mi propio archivo de almacén de confianza. Esto hizo que la información en el siguiente enlace se volviera importante.

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

Nota: Si está utilizando JRun como el servidor J2EE subyacente (ya sea el Configuración del servidor o el multiservidor / J2EE con configuración JRun) y tiene habilitado SSL para el servidor web JRun interno (JWS), lo hará necesidad de importar el certificado al almacén de confianza definido en el Archivo jrun.xml para el JWS seguro en lugar del almacén de claves JRE. Por por defecto, el archivo se llama " trustStore " y es típicamente ubicado bajo jrun_root / lib para Multiserver / J2EE con configuración JRun o cf_root / runtime / lib para la configuración de ColdFusion Server. Tú use la misma herramienta de Java para administrar el almacén de confianza.

Aquí está el extracto de mi archivo 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 vez que importé el certificado en este almacén de confianza (/app/jrun4/cert/truststore.jks) funcionó después de reiniciar ColdFusion.

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

Agregar el certificado al almacén de claves no me funcionó en CF9 Enterprise.

Terminé usando la etiqueta CFX, CFX_HTTP5 .

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow