cfhttp connection failed on SSL

[Hedge]

I'm running CF 9 Ent using JVM 1.6.0_14.

We had a credit card processor API that was working fine until this weekend when they updated their SSL certificate. Then we started getting the connection failed message. So I went in and got a copy of their .cer file and I imported it into the KeyStore using the keytool. I reboot the VM and the CFHTTP works for about 5 minutes then starts giving the Connection Failure message again. The URL comes up fine in a browser on the desktop of the VM. I'm at a loss as to what to do now. The places online where I see people having this issue they all claim an import of the keyfile fixes it. You would think it would work find all the time or not at all. Makes no sense why it works for a little bit after a reboot then doesn't work again all the sudden. Anybody got any suggestions?

[12Robots]

In my experience, these errors are usually caused by one of two things:

1. The admin failed to install the cert into the cacarts repo or they installed it into the wrong one

2. ColdFusion Enterprise and ColdFusion Developer edition (For CF8 and 9 both, I believe) have an issue with the built-in BSafe CryptoJ Library that is installed and certain types of certificates (I have not yet been able to determine a pattern) that causes this error. There are some work arounds if this is the case.

Now for it to work for 5 minutes and then stop is something I have *never* heard of, so I am not sure if my usual advice with help.

First, I would take the time to export the entire certificate chain into the cacerts keystore. Not just the site's cert, but also the CA cert and any intermediates.

Next, I would explore the possibility that you are importing into the wrong cert repo. It can be hard to tell which repo is being used. In your CF Admin under "Setting Summary" you should be able to find the location of the JRE that is being used. It is listed under "Java Home". Take that directory and add lib/security to the end of it and that should be the location of the cacaerts file that is being used. I say should because I have seen at least one weird situation where it was not.

If you are 100% positive that you are putting the cert into the correct cacert file (and that you are adding the entire cert chain) then you are probably running into the BSafe bug that I mentioned above. The work around for this is to remove the BSafe provider from the available JCA/JCE providers (Note, this negates ColdFusion's FIPS-140 compliance, so if you depend on that then you may need to look into another option).

<!--- Get the Security class --->

<cfset objSecurity = createObject("java", "java.security.Security") />

<!--- Store the Jsafe provider so you can put it back --->

<cfset storeProvider = objSecurity.getProvider("JsafeJCE") />

<!--- Remove the provider --->

<!---<cfset objSecurity.removeProvider("JsafeJCE") />--->

<!--- Make your call here --->

<!--- Put the provider back where you found it (in the first position) --->

<!---<cfset objSecurity.insertProviderAt(storeProvider, 1) />--->

I hope this helps

[Hedge]

Great information. On this particular VM they at one time attempted to update the JVM and then CF would not start so they had to reoll back to the backup JVM. So my Java Home directory looks liek this.

C:\ColdFusion9\runtime\jre_installerbackup

The certificate for this site I am trying to reach is provided by GoDaddy so I don't know if that falls under the BSafe bug or not?

How can I check to see if the certificates I have imported using the keytool are actually in the KeyStore?

[12Robots]

Sometimes it is very hard to determine which cacerts file is being used. I have had to, in the past, search the hard disk for cacerts files and then keep importing certs until I stopped getting the error.

The CryptoJ bug could happen with any CA. I have not yet nailed down the pattern. If you run that code before and after your call and it still fails then I think it is definitely a cacerts issue. If it succeeds, then it is a BSafe issue.

[Hedge]

I ended up going with the cfx_http5 custom tag. Works great. Wish I could have had more time to try to figure out why the other would not work but the project demanded a pretty immediate solution.