当前位置：文江博客话题详情

ColdFusion CFHTTP I/O 异常：对等方未经过身份验证 - 即使将证书添加到密钥库后也是如此

发布于 2024-08-08 12:36:00 字数 236 浏览 13 评论 0 原文

我目前正在与支付处理商合作。我可以从我们的服务器浏览到支付 URL，因此这不是防火墙问题，但当我尝试使用 CFHTTP 时，我收到 I/O 异常：对等方未经过身份验证。我已下载最新的安全证书并将其安装到 cacerts 密钥库中并重新启动 CF，但仍然遇到相同的错误。我不仅安装了提供商证书，还安装了证书链中的其他 2 个 Verisign 证书颁发机构证书。该证书是较新的 3 类扩展验证证书之一。

以前有人遇到过这个问题并找到解决方案吗？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

温柔嚣张 2024-08-15 12:36:00

我的一位同事在连接到第三方时遇到同样的问题后发现了以下内容。

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

我们使用了页面下方 Pete Freitag 的评论中提供的解决方案。它有效，但我认为应该谨慎使用，因为它涉及动态删除和添加回 JsafeJCE 提供程序的特定属性。

为了存档方便，以下是Pete Freitag评论的原文：

我进一步缩小了范围，并删除了
来自 RSA JsafeJCE 提供商的 KeyAgreement.DiffieHellman（
导致使用默认的 sun 实现）接缝到
工作，并且可能对您的服务器的影响小于删除
整个提供商都会。操作方法如下：
 />
 >
;

;

进行 http 调用，但如果需要，请打包密钥协议：

;
我通过使用 SSLSocketFactory 创建 https 来解决这个问题
连接，它在堆栈跟踪中提供了更多详细信息，而不是
使用cfhttp时：
yadayadayada 导致：java.security.InvalidKeyException：无法
建立算法 TlsPremasterSecret 的密钥
com.rsa.jsafe.provider.JS_KeyAgree.engineGenerateSecret（未知
来源）位于 javax.crypto.KeyAgreement.generateSecret(DashoA13*..)
com.sun.net.ssl.internal.ssl.DHCrypt.getAgreedSecret(DHCrypt.java:166)
如果 ColdFusion 抛出的异常少一点那就太好了
通用。

A colleague of mine found the following after experiencing the same issue when connecting to a 3rd party.

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

We used the solution provided in the comment by Pete Freitag further down the page. It works, but I think should be used with caution, as it involves dynamically removing and adding back in a particular property of the JsafeJCE provider.

For the sake of archiving, here is the original content of Pete Freitag's comment:

I've narrowed this down a bit further, and removing the
KeyAgreement.DiffieHellman from the RSA JsafeJCE provider (which
causes the default sun implementation to be used instead) seams to
work, and probably has less of an effect on your server than removing
the entire provider would. Here's how you do it:
<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)>
I figured this out by using the SSLSocketFactory to create a https
connection, which provided a bit more details in the stack trace, than
when using 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)
Would be great if the exception thrown from ColdFusion was a bit less
generic.

回复收藏 0 原文

半夏半凉 2024-08-15 12:36:00

特定于带有现代 ssl 密码的 Web 服务器的 Coldfusion 8：

我在 JDK 1.6.45 上使用 Coldfusion 8，并且遇到了问题；只给我红色十字而不是图像，并且 cfhttp 无法使用 ssl 连接到本地网络服务器。

我用 Coldfusion 8 重现的测试脚本

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

给了我一个非常普遍的错误“I/O 异常：对等点未经过身份验证”。
然后，我尝试将服务器的证书（包括根证书和中间证书）添加到 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位的强大的Diffie-Hellman组。显然，coldfusion和java jdk 1.6.45无法管理这个。
旅程的下一步是考虑安装一个替代的 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 （使用写字板而不是 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 ...（上面的域名）。

specific to coldfusion 8 with an webserver with modern ssl ciphers:

I use coldfusion 8 on JDK 1.6.45 and had problems with <cfdocument ...> giving me just red crosses instead of images, and also with cfhttp not able to connect to the local webserver with ssl.

my test script to reproduce with coldfusion 8 was

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

this gave me the quite generic error of " I/O Exception: peer not authenticated."
I then tried to add certificates of the server including root and intermediate certificates to the java keystore and also the coldfusion keystore, but nothing helped.
then I debugged the problem with

java SSLPoke www.onlineumfragen.com 443

and got

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

and

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

I then had the idea that the webserver (apache in my case) had very modern ciphers for ssl and is quite restrictive (qualys score a+) and uses strong Diffie-Hellman groups with more than 1024 bits. obviously, coldfusion and java jdk 1.6.45 can not manage this.
Next step in the odyssee was to think of installing an alternative security provider for java, and I decided for bouncy castle.
see also http://www.itcsolutions.eu/2011/08/22/how-to-use-bouncy-castle-cryptographic-api-in-netbeans-or-eclipse-for-java-jse-projects/

I then downloaded the

bcprov-ext-jdk15on-156.jar

from http://www.bouncycastle.org/latest_releases.html and installed it under
C:\jdk6_45\jre\lib\ext or where ever your jdk is, in original install of coldfusion 8 it would be under C:\JRun4\jre\lib\ext but I use a newer jdk (1.6.45) located outside the coldfusion directory. it is very important to put the bcprov-ext-jdk15on-156.jar in the \ext directory (this cost me about two hours and some hair ;-)
then I edited the file C:\jdk6_45\jre\lib\security\java.security (with wordpad not with editor.exe!) and put in one line for the new provider. afterwards the list looked like

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

(see the new one in position 1)

then restart coldfusion service completely.
you can then

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

and enjoy the feeling...
and of course
<cfhttp and <cfdocument worked like a charm and like before we "hardened" our ssl ciphers in apache!

what a night and what a day. Hopefully this will help (partially or fully) to someone out there. if you have questions, just mail me at info ... (domain above).

回复收藏 0 原文

若无相欠,怎会相见 2024-08-15 12:36:00

您是否将其添加到正确的密钥库中？请记住，ColdFusion 使用它自己的 Java 实例。我曾经花了好几个小时才想起这个事实。你想要的那个位于 /ColdFusion8/runtime/jre/lib/security/ 之类的地方

回复收藏 0 原文

握住我的手 2024-08-15 12:36:00

中尝试使用此命令

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

注意：我们必须选择安全文件夹中存在的正确密钥库，因为 bin 中存在其他密钥库文件。如果我们将证书导入到这些密钥库中，它将不起作用。

回复收藏 0 原文

墨落成白 2024-08-15 12:36:00

我刚刚发现的内容在这篇文章中被引用： http://kb2.adobe.com/经过大量挖掘后，cps/400/kb400977.html 和其他一些地方。

如果您正在查看本文，您很可能已将“server.crt”证书插入到正确的根位置，并且您可能已使用命令

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

（如果您尚未执行此操作，请立即执行此操作）。
我遇到的问题是我正在本地主机上设置 ssl，因此在执行这些步骤后我仍然遇到相同的错误。

事实证明，您还需要使用以下命令将“server.crt”插入通常位于 /ColdFusion9/runtime/jre/lib 中的“trustStore”文件中，

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

希望这会节省一些时间。

What I just found out was referenced at this article: http://kb2.adobe.com/cps/400/kb400977.html and a few other places after a lot of digging.

If you are looking at this article you have most likely inserted your "server.crt" certificate in the proper root locations and you have probably inserted it into the cacerts file in /ColdFusion9/runtime/jre/lib/security using the command

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

(if you haven't done this, do it now).
The thing I was running into was that I am setting up ssl on my localhost so after doing these steps I was still getting the same error.

As it turns out, you need to also insert your "server.crt" into the "trustStore" file commonly located in /ColdFusion9/runtime/jre/lib using the command

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

Hopefully this will save someone time.

回复收藏 0 原文

你是年少的欢喜 2024-08-15 12:36:00

我正在使用JRun。在尝试了很多不同的事情之后，我发现了一些适用于我的设置的信息片段。我已经使用自己的信任库文件配置了 (1)HTTPS SSLService。这导致以下链接中的信息变得重要。

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

注意：如果您使用 JRun 作为底层 J2EE 服务器（无论是
服务器配置或带有 JRun 配置的多服务器/J2EE）
并已为内部 JRun Web 服务器 (JWS) 启用 SSL，您将
需要将证书导入到定义的信任库中
用于安全 JWS 而不是 JRE 密钥存储的 jrun.xml 文件。经过
默认情况下，该文件名为“trustStore”，通常位于
在 jrun_root/lib 下，用于具有 JRun 配置的 Multiserver/J2EE
或 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/遗留/kb/ssl-jrun-web-server-connector.html

I am using JRun. After trying a lot of different things I came across a snippet of information that was applicable in my setup. I had configured an (1)HTTPS SSLService with my own truststore file. This caused the piece of information in the following link to become important.

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

Note: If you are using JRun as the underlying J2EE server (either the
Server Configuration or the Multiserver/J2EE with JRun Configuration)
and have enabled SSL for the internal JRun Web server (JWS), you will
need to import the certificate to the truststore defined in the
jrun.xml file for the Secure JWS rather than the JRE key store. By
default, the file is called "trustStore" and is typically located
under jrun_root/lib for the Multiserver/J2EE with JRun configuration
or cf_root/runtime/lib for the ColdFusion Server configuration. You
use the same Java keytool to manage the trustStore.

Here is the excerpt from my jrun.xml file:

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

Once I imported the certificate into this truststore (/app/jrun4/cert/truststore.jks) it worked after restarting ColdFusion.

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

回复收藏 0 原文