ColdFusion CFHTTP I / O Exceção: pares não autenticado - mesmo depois de adicionar certificados ao armazenamento de chaves

Question

Atualmente estou trabalhando com um processador de pagamento. I pode navegar para o URL de pagamento do nosso servidor, por isso não é um problema de firewall, mas quando eu tento usar CFHTTP eu recebo uma exceção de I / O: pares não autenticado. Eu fiz o download e instalado o seu mais recente cert segurança em cacerts armazenamento de chaves e reiniciado CF e ainda estou recebendo o mesmo erro. Não só eu instalei a prestadores de cert, mas também os outros 2 certs autoridade de certificação Verisign da cadeia de certificados. O cert é um dos mais novos Classe 3 certificados Extended Validation.

Alguém se deparar com isso antes e encontrou uma solução?

Answer 1

Um colega meu encontrou o seguinte depois de experimentar o mesmo problema ao se conectar a um terceiro partido.

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/

Nós usamos a solução fornecida no comentário por Pete Freitag parte inferior da página. Ele funciona, mas acho que deve ser usado com cautela, uma vez que envolve dinamicamente remover e adicionar de volta em uma propriedade particular do provedor JsafeJCE.

Por uma questão de arquivamento, aqui está o conteúdo original do comentário de Pete Freitag:

Eu reduzi-lo um pouco mais, e remover o KeyAgreement.DiffieHellman do provedor RSA JsafeJCE (que faz com que a implementação sol padrão a ser usado em seu lugar) costuras para trabalhar, e provavelmente tem menos de um efeito no seu servidor de remover Todo o provedor faria. Veja como fazer isso:

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

Eu descobri isso usando a SSLSocketFactory para criar uma https conexão, o que proporcionou um pouco mais detalhes no rastreamento de pilha, que ao usar 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)

Seria ótimo se a exceção lançada do ColdFusion foi um pouco menos genérico.

Answer 2

Você adicioná-lo ao armazenamento de chaves correto? Lembre-se que o ColdFusion usa seu próprio exemplo Java. Passei várias horas sobre isso uma vez antes de se lembrar desse fato. O que você quer está em algum lugar como / ColdFusion8 / runtime / jre / lib / security /

Answer 3

específica para o ColdFusion 8 com um servidor web com cifras SSL modernos:

Eu uso o ColdFusion 8 no JDK 1.6.45 e teve problemas com me dando cruzes apenas vermelhos em vez de imagens, e também com CFHTTP não é capaz de se conectar ao servidor local com SSL.

meu script de teste para reproduzir com o ColdFusion 8 foi

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

isso me deu o erro bastante genérico de "I Exceção / O: pares não autenticado." Então eu tentei adicionar certificados do servidor, incluindo raiz e certificados intermediários para o keystore java e também o armazenamento de chaves ColdFusion, mas nada ajudou. então eu depurado o problema com

java SSLPoke www.onlineumfragen.com 443

e tem

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

Então eu tive a idéia de que o servidor web (Apache no meu caso) tinha cifras muito moderno para SSL e é bastante restritiva (Qualys marcar um +) e utiliza fortes chaves Diffie Hellmann com mais de 1024 bits. obviamente, ColdFusion e Java JDK 1.6.45 não pode gerir este. Próximo passo no Odysee foi pensar em instalar um provedor de segurança alternativo para java, e eu decidi para castelo insuflável. ver também http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for -java-JSE-projectos /

Eu, então, baixou o

bcprov-ext-jdk15on-156.jar

http://www.bouncycastle.org/latest_releases.html e instalado debaixo C: \ jdk6_45 \ jre \ lib \ ext ou onde nunca seu jdk é, na instalação original do ColdFusion 8 seria em C: \ jrun4 \ jre \ lib \ ext mas eu uso um JDK mais recente (1.6.45) fora localizada o diretório do ColdFusion. é muito importante para colocar o bcprov-ext-jdk15on-156.jar no diretório \ ext (este custo me cerca de duas horas e alguns cabelos ;-) então eu editei o arquivo C: \ jdk6_45 \ jre \ lib \ security \ java.security (com o WordPad não com editor.exe!) e colocar em uma linha para o novo provedor. depois a lista parecia

#
# 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 o novo na posição 1)

, em seguida, reiniciar o serviço do ColdFusion completamente. você pode então

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

e desfrutar da sensação ... e claro

o que uma noite e que um dia. Esperemos que isto irá ajudar (parcial ou totalmente) a alguém lá fora. Se você tiver dúvidas, apenas enviam-me em info ... (domínio acima).

Answer 4

Tente com isso em CMD

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

Nota:. Devemos escolher o armazenamento de chave correta presente dentro da pasta de segurança, pois há outro arquivo de armazenamento de chave presente no interior bin.If vamos importar o certificado para essas lojas chave não vai funcionar

Answer 5

O que eu acabei de descobrir que foi referenciado neste artigo: http: //kb2.adobe .com / cps / 400 / kb400977.html e alguns outros lugares depois de um monte de escavação.

Se você está olhando para este artigo você provavelmente inserido o seu certificado "server.crt" nos locais de raiz adequados e você provavelmente já inseriu o arquivo cacerts in / ColdFusion9 / runtime / jre / lib / security usando o comando

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

(se você não tiver feito isso, faça isso agora). A coisa que eu estava correndo em é que estou a criação de SSL no meu localhost para depois de fazer estes passos eu ainda estava recebendo o mesmo erro.

Como se vê, é preciso também inserir o seu "server.crt" no arquivo "trustStore" normalmente localizado em / ColdFusion9 / runtime / jre / lib usando o comando

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

Esperemos que isto irá economizar tempo alguém.

Answer 6

Eu estou usando JRun. Depois de tentar um monte de coisas diferentes me deparei com um trecho de informação que era aplicável na minha configuração. Eu tinha configurado um (1) HTTPS SSLService com o meu próprio arquivo de truststore. Isso fez com que o pedaço de informação no link a seguir para se tornar importante.

http://helpx.adobe.com/ coldfusion / kb / importação-certificados do certificado de lojas-coldfusion.html

Nota: Se você estiver usando JRun como o servidor J2EE subjacente (ou o Configuração do servidor ou o Multiserver / J2EE com configuração de JRun) e permitiram SSL para o servidor JRun Web interno (JWS), você vai precisa importar o certificado para o truststore definido no arquivo jrun.xml para os JWS seguros em vez do armazenamento de chaves JRE. De padrão, o arquivo é chamado de "trustStore" e normalmente está localizado sob jrun_root / lib para o Multiserver / J2EE com configuração JRun ou cf_root / runtime / lib para a configuração ColdFusion Server. Vocês usar a mesma keytool Java para gerenciar a trustStore.

Aqui está o trecho do meu arquivo 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>

Uma vez que eu importado o certificado para este truststore (/app/jrun4/cert/truststore.jks) funcionou depois de reiniciar ColdFusion.

---

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

Answer 7

Como adicionar o certificado ao armazenamento de chaves não funcionou para mim no CF9 Empresa.

acabou usando a tag CFX, CFX_HTTP5.