ColdFusion CFHTTP I / O Exception: одноранговый узел не аутентифицирован - даже после добавления сертификатов в Keystore - PullRequest
7 голосов
/ 23 октября 2009

В настоящее время я работаю с платежным процессором. Я могу перейти к URL-адресу платежа с нашего сервера, так что это не проблема брандмауэра, но когда я пытаюсь использовать CFHTTP, я получаю исключение ввода-вывода: узел не аутентифицирован. Я скачал и установил их последний сертификат безопасности в хранилище ключей cacerts и перезапустил CF, и все еще получаю ту же ошибку. Я установил не только сертификат поставщика, но и 2 других сертификата центра сертификации Verisign в цепочке сертификатов. Сертификат является одним из более новых сертификатов расширенной проверки класса 3.

Кто-нибудь сталкивался с этим раньше и нашел решение?

Ответы [ 7 ]

9 голосов
/ 02 декабря 2011

Мой коллега обнаружил следующее после того, как столкнулся с той же проблемой при подключении к третьей стороне.

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/

Мы использовали решение, предоставленное в комментарии Пита Фрейтага, далее по странице. Это работает, но я думаю, что следует использовать с осторожностью, поскольку оно включает в себя динамическое удаление и добавление обратно в определенное свойство поставщика JsafeJCE.

Для архивации, вот оригинальное содержание комментария Пита Фрейтага:

Я сузил это немного дальше, и удаляя KeyAgreement.DiffieHellman от провайдера RSA JsafeJCE (который вместо этого используется реализация по умолчанию Sun) швы работать, и, вероятно, оказывает меньшее влияние на ваш сервер, чем удаление весь провайдер будет. Вот как вы это делаете:

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

Я понял это с помощью SSLSocketFactory для создания https соединение, которое предоставило чуть больше деталей в трассировке стека, чем при использовании 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)

Было бы замечательно, если бы исключение из ColdFusion было немного меньше общий.

3 голосов
/ 05 января 2017

специфично для coldfusion 8 с веб-сервером с современными ssl-шифрами:

Я использую coldfusion 8 на JDK 1.6.45, и у меня были проблемы с предоставлением мне только красных крестиков вместо изображений, а также с cfhttp, не способным подключиться к локальному веб-серверу с помощью ssl.

мой тестовый сценарий для воспроизведения с Coldfusion 8 был

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

это дало мне довольно общую ошибку "I / O Exception: peer not authenticated". Затем я попытался добавить сертификаты сервера, включая корневые и промежуточные сертификаты, в хранилище ключей java, а также в хранилище ключей coldfusion, но ничего не помогло. тогда я отладил проблему с

java SSLPoke www.onlineumfragen.com 443

и получил

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

Тогда мне пришла в голову мысль, что веб-сервер (в моем случае apache) имеет очень современные шифры для ssl, он довольно ограниченный (qualys Score a +) и использует сильные ключи diffie hellmann с более чем 1024 битами. Очевидно, Coldfusion и Java JDK 1.6.45 не может справиться с этим. Следующим шагом в odysee было подумать об установке альтернативного провайдера безопасности для Java, и я выбрал надувной замок. см. также http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/

Я тогда скачал

bcprov-ext-jdk15on-156.jar

из http://www.bouncycastle.org/latest_releases.html и установил его под C: \ jdk6_45 \ jre \ lib \ ext или где бы ни находился ваш jdk, в оригинальной установке coldfusion 8 он будет находиться в C: \ JRun4 \ jre \ lib \ ext, но я использую более новый jdk (1.6.45), расположенный вне каталог Coldfusion. очень важно поместить bcprov-ext-jdk15on-156.jar в каталог \ ext (это стоило мне около двух часов и немного волос ;-) затем я отредактировал файл C: \ jdk6_45 \ jre \ lib \ security \ java.security (с wordpad, а не с editor.exe!) и вставил одну строку для нового провайдера. впоследствии список выглядел как

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

(см. Новый в позиции 1)

затем полностью перезапустите службу Coldfusion. тогда вы можете

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

и наслаждайся ощущением ... и конечно

какая ночь и какой день. Надеюсь, это поможет (частично или полностью) кому-то там. если у вас есть вопросы, просто напишите мне на info ... (домен выше).

3 голосов
/ 23 октября 2009

Вы добавили его в правильное хранилище ключей? Помните, что ColdFusion использует свой собственный экземпляр Java. Я потратил на это несколько часов, прежде чем вспомнить этот факт. Тот, который вы хотите, находится где-то вроде / ColdFusion8 / runtime / jre / lib / security /

2 голосов
/ 24 мая 2013

Попробуйте с этим в CMD

C: \ ColdFusion9 \ выполнения \ JRE \ Bin> keytool -import -keystore ../lib/security/cacerts -alias уникальное имя -file certificatename.cer

Примечание. Мы должны выбрать правильное хранилище ключей в папке безопасности, так как в bin есть другой файл хранилища ключей. Если мы импортируем сертификат в эти хранилища ключей, он не будет работать.

0 голосов
/ 20 февраля 2015

Добавление сертификата в хранилище ключей не работает для меня на CF9 Enterprise.

Завершается с использованием тега CFX, CFX_HTTP5.

0 голосов
/ 17 декабря 2013

Я использую JRun. Попробовав много разных вещей, я наткнулся на фрагмент информации, которая была применима в моей настройке. Я настроил (1) HTTPS SSLService со своим собственным файлом склада доверенных сертификатов. Это привело к тому, что часть информации в следующей ссылке стала важной.

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

Примечание. Если вы используете JRun в качестве базового сервера J2EE (либо Конфигурация сервера или Multiserver / J2EE с конфигурацией JRun) и включив SSL для внутреннего веб-сервера JRun (JWS), вы необходимо импортировать сертификат в склад доверенных сертификатов, определенный в Файл jrun.xml для Secure JWS, а не для хранилища ключей JRE. От по умолчанию файл называется «trustStore» и обычно находится в jrun_root / lib для Multiserver / J2EE с конфигурацией JRun или cf_root / runtime / lib для конфигурации сервера ColdFusion. Вы используйте тот же Java keytool для управления trustStore.

Вот выдержка из моего файла 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>

После того, как я импортировал сертификат в это доверенное хранилище (/app/jrun4/cert/truststore.jks), он работал после перезапуска ColdFusion.


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

0 голосов
/ 02 июня 2011

На то, что я только что узнал, ссылались в этой статье: http://kb2.adobe.com/cps/400/kb400977.html и в нескольких других местах после множества раскопок.

Если вы просматриваете эту статью, вы, скорее всего, вставили свой сертификат «server.crt» в соответствующие корневые каталоги и, вероятно, вставили его в файл cacerts в / ColdFusion9 / runtime / jre / lib / security, используя команда

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

(если вы этого не сделали, сделайте это сейчас). Я столкнулся с тем, что я настраивал ssl на своем локальном хосте, поэтому после выполнения этих шагов я все еще получал ту же ошибку.

Как выяснилось, вам также нужно вставить ваш "server.crt" в файл "trustStore", обычно расположенный в / ColdFusion9 / runtime / jre / lib, с помощью команды

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

Надеюсь, это сэкономит кому-то время.

...