Orange is my favorite color

If you use any of ColdFusion’s network connectivity tags like CFHTTP or CFLDAP which can access SSL-protected resources, you may eventually come across a dreaded security error. This is caused by SSL certificates which are, in some way, not valid causing the JRE to throw an exception.

This link round-up is the result of getting my multi-instance ColdFusion MX install to access the dev server of my payment gateway. Their SSL cert ( does not match the domain that it’s hosted at ( and ColdFusion really doesn’t like it.

The following resources should get you through any mix of SSL problems with ColdFusion:

  • Import the “bad” SSL certificate into the keystore – well-documented by Steven Erat and others, this is a required first step in most cases. Steven’s batch files are handy but if you just want the quick and dirty, I found Lynch Consulting’s blog to be quicker to skim.
  • Shorten the TTL for DNS caching will show you how to reconfigure your development environment to use a shorter DNS caching period. This is not usually advised for production environments. A server restart will clear the cache but on a development machine, this is a helpful swap. I set mine to a ttl of 10 seconds.
  • Spoof the IP address of your target host using a windows “hosts” file or linux “/etc/hosts” to fool ColdFusion into believing the IP for your target actually matches the SSL cert. In my case, I inserted a record for that really points to Now when CFHTTP loads, it gets the “wrong” IP address, the SSL cert matches and everyone is happy.
  • Lookup the IP address ColdFusion is connecting to when you are debugging. Use this to verify CF is connecting to the right IP address. You can also run a reverse lookup too. You’ll need Java enabled in both cases.

Now if the gateway was actually working properly, I could get some work done. The upside is that with the errors that CFHTTP is throwing, I’ve been building some solid error handling for CFPAYMENT

Comments are closed.