ColdFusion CFHTTP I/O Exception: peer not authenticated - even after adding certs to Keystore - authentication

Question

I'm currently working with a payment processor. I can browse to the payment URL from our server, so it's not a firewall issue, but when I try to use CFHTTP I get a I/O Exception: peer not authenticated. I've downloaded and installed their latest security cert into cacerts keystore and restarted CF and am still getting the same error. Not only have I installed the providers cert, but also the 2 other Verisign certificate authority certs in the certificate chain. The cert is one of the newer Class 3 Extended Validation certs.
Has anybody come across this before and found a solution?

Answer 1

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")>
<!--- 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)>
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.

Answer 2

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

Answer 3

Did you add it to the correct keystore? Remember that ColdFusion uses it's own Java instance. I spent several hours on this once before remembering that fact. The one you want is at somewhere like /ColdFusion8/runtime/jre/lib/security/

Answer 4

Try with this in CMD
C:\ColdFusion9\runtime\jre\bin>
keytool -import -keystore ../lib/security/cacerts
-alias uniquename -file certificatename.cer
Note: We must choose the correct keystore present inside the security folder,as there are other keystore file present inside bin.If we will import the certificate to those key stores it will not work.

Answer 5

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.

Answer 6

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

Answer 7

Adding the cert to the keystore did not work for me on CF9 Enterprise.
Ended up using the CFX tag, CFX_HTTP5.

Answer 8

I realize this is a very old discussion, but since it still comes up near the top of a search for the "peer not authenticated" error in CF, I wanted to share that for most people, the simple solution is to update the JVM that CF uses. (More in a moment on how to do that.)
The cause of the problem is generally that the service BEING CALLED has made a change that requires a later version of TLS or SSL (and perhaps a change to supported algorithms). Later JVMs offer that, while earlier ones did not. Since CF runs atop the JVM, it's the calls out of CF (va cfhttp, cfldap, cfmail, etc) that "suddenly" start to fail.
And sure, sometimes a cert update is the answer (and even then, you have to do it carefully), but it's not always needed. And updating the JVM also gives other benefits, in terms of bug fixes, etc.
The only challenge is knowing what JVM your version of CF will support. (But even people still running on an old CF version have found that updating the JVM CF uses has solved this problem and not caused any others.)
I discuss all this in a 2019 post:
https://coldfusion.adobe.com/2019/06/error-calling-cf-via-https-solved-updating-jvm/
Hope that may help someone.