Исключение ввода-вывода ColdFusion CFHTTP:одноранговый узел не аутентифицирован - даже после добавления сертификатов в хранилище ключей

Question

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

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

Answer 1

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

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 было немного меньше   родовым.

Answer 2

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

Answer 3

специфичный для 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#">

это выдало мне довольно общую ошибку "Исключение ввода-вывода:одноранговый узел не аутентифицирован ". Затем я попытался добавить сертификаты сервера, включая корневые и промежуточные сертификаты, в хранилище ключей 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 a +) и использует надежные ключи Диффи-Хеллмана с более чем 1024 битами.очевидно, что coldfusion и java jdk 1.6.45 не могут справиться с этим.Следующим шагом в odysee было подумать об установке альтернативного поставщика безопасности для java, и я остановил свой выбор на bouncy castle.смотрите также 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...(домен выше).

Answer 4

Попробуйте использовать это в CMD

C:\ColdFusion9 untime\jre\bin > keytool -импорт -хранилище ключей ../библиотека/безопасность/cacerts -уникальное имя псевдонима -файл certificatename.cer

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

Answer 5

На то, что я только что узнал, ссылались в этой статье: 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

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

Answer 6

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

http://helpx.adobe.com/ ColdFusion / кб / импорт-сертификаты-сертификат-магазины-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 / наследие / кб / SSL-JRun-веб-сервер connector.html

Answer 7

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

Завершается с помощью тега CFX, CFX_HTTP5 .