tracker issue : CF-3566218

select a category, or use search below
(searches all categories and all time range)

CFHTTP/CFInvoke Fails with SSL Certificates using Subject Alternative Names (SAN)

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): James Moberg / James Moberg (James Moberg)

Created: 05/23/2013

Components: ColdFusion Services

Versions: 9.0.1

Failure Type:

Found In Build/Fixed In Build: 9.0.1 /

Priority/Frequency: Major / All users will encounter

Locale/System: English / Win 2008 Server R2 64 bit

Vote Count: 4

Problem Description:  Using CFInvoke to connect to any web service that uses a SSL Certificate with Subject Alternative Names (SAN) will result in an SSLException error. " Name in certificate '' does not match host name ''."

Here's more info on SAN:

Steps to Reproduce: Find a server using an SSL Certificate w/SAN and try to connect using CFHTTP or CFInvoke.

Actual Result: Connection Failure 

Expected Result: 200 OK, API Response... anything but a connection failure.

Any Workarounds:  None.  Upgrading to Java 1.7.0__15 or updating SSL Certs didn't change anything.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3566218

Deployment Phase:	Release Candidate

External Customer Info:
External Company:  
External Customer Name: Jamo
External Customer Email:  
External Test Config: My Hardware and Environment details:

Windows Server 2008 R2

ColdFusion 9,0,1,274733 (Update level hf901-00009)

Java Version: 1.7.0_15



I was troubleshooting an issues with "one of the world's largest providers of merchant processing" (their description of their company, not mine). They upgraded their SSL Certificate recently and ColdFusion 9 could no longer connect to their server. Their API previously worked with ColdFusion since January 2011. Instead of addressing the incompatible SSL certificate issue, they've elected to remove all references of ColdFusion from their online documentation and removed sample code. So this issue is not just impacting me... this is now impacting the future of ColdFusion. On a whim, I entered the same CFHTTP code into (Railo) and it works. Find out what they are doing right and fix this.
Comment by External U.
15296 | May 23, 2013 10:27:09 AM GMT
This is a response from the firm hosting the API: "I’ve performed some more research into the issue, and found some useful information. The issue is definitely caused by the Subject Alternative Name use in our production certificate. At this point, the issue seems to be isolated to ColdFusion 9, but my research indicates that CF9 should support the use of SAN in certificates. I enabled the debugging in the JVM and can clearly see that Java is not rejecting the certificates. It is returning a warning to CF9, but the rejection of the name matching is definitely happening within the CF9 environment. At this point, we would need to direct you to Adobe for ColdFusion support to address the issue of CF9 rejecting the certificate due to the name mismatch and inability to utilize the SAN record in the certificate." So can we consider this bug "verified" and fix it for the next patch?
Comment by External U.
15297 | May 24, 2013 09:50:38 AM GMT
Anyone trying to connect to FirstData's Global Gateway API in CF 9 and below will not be able to connect due to their use of Alternative Names and CFHTTP/CFINVOKE not recognizing them.
Vote by External U.
15308 | June 13, 2013 01:18:22 PM GMT
It is working fine in CF10 in case that is an option for you
Comment by External U.
15298 | June 13, 2013 01:19:44 PM GMT
This needs fixed. This needs fixed. This needs fixed. This needs fixed. Seriously, why do I need to type at least "25 characters" to vote on this bug. All you need to know is I agree it should be fixed.
Vote by External U.
15309 | June 18, 2013 08:26:02 AM GMT
The problem is because the name used in the SAN for is spelled with a capital E. The cfhttp tag uses the HTTPClient.HTTPConnection class to handle all connections. There is a method called checkCert that does not convert the SAN to lowercase before comparing it with the hostname. You might be able to work around this by setting the hostname to unless coldfusion converts the hostname to lowercase before passing it to HTTPConnection.
Comment by External U.
15299 | July 26, 2013 03:37:18 PM GMT
[stevejaeger949] "Working in CF10" isn't a valid fix to this bug. (Especially since there are currently too many outstanding CF10 issues that we are still reviewing.) [aaronf91] I'm not sure the case matters. I changed it and the error message is the same and is regarding the domain names not matching at all (api versus non-api sub-domain): "Connection Failure I/O Exception: Name in certificate `' does not match host name `'" If you test the above CFHTTP request using, you'll notice that Railo works correctly and ColdFusion experiences a connection failure. I've provide copy-and-paste sample code here: This should be enough information for Adobe Engineers to verify that this is a bug and update the status from "unverified". (NOTE: It's been 67 days since I initially reported this bug. It has crippled my client from accepting real-time payments & has resulted in the merchant removing all mention of ColdFusion from their support site.)
Comment by External U.
15300 | July 29, 2013 11:38:21 AM GMT
@jamo I hadn't had a change to test my proposed workaround, which it looks like does not work. The problem is that ColdFusion downcases the host URL before calling HTTPConection(). Here is a gist of the method that is causing the issue and an example of how it could be fixed.
Comment by External U.
15301 | July 30, 2013 10:37:31 AM GMT
I was able to recompile the library with my example fix and it seems to work. If you don't want to wait for adobe you can download the jar here just rename the original httpclient.jar file in the lib directory and reset ColdFusion. The jar was compiled with java 1.6
Comment by External U.
15302 | July 30, 2013 10:58:18 AM GMT
Correction to my previous post since I can't edit it. ColdFusion does NOT convert the url to lowercase, the HTTPConnection class does in the setup method that is called by the constructor.
Comment by External U.
15303 | July 30, 2013 11:48:12 AM GMT
Been working on integrating FirstData API into our environment and am not running into these same connection failures. We just updated our JVM and have 9.0.1 with latest HFs installed. This is a pretty major problem to have and updating to CF10 is not a viable option to fix this issue.
Vote by External U.
15310 | September 04, 2013 10:19:03 AM GMT
Really? Closed, Withdrawn and CannotReproduce? How was this internally tested? (I still get the error using ColdFusion 9,0,1,274733.) Which CF version & OS was this tested against? (Maybe you inadvertently tested against ColdFusion 10 instead of 9?) To test outside of my installation & configuration, I visited, posted the above CFML into it and got the same exact ColdFusion error. If I try the same code at, it works... but that website uses ColdFusion 10.
Comment by External U.
15304 | December 23, 2013 12:14:55 PM GMT
This has been fixed in 10. There is no update planned for 9.X right now.
Comment by Vamseekrishna N.
15305 | January 06, 2014 12:15:43 AM GMT
I would like to note how ridiculous it is that a "supported" CF9 product is not updated when obviously important issues like this are found and solved. Vamseekrishna Nanneboina, why not just say that there are no plans to ever update any of your products, that your team is severely underfunded, and lacking in any basic ability to meet an acceptable level of product support?
Vote by External U.
15311 | September 25, 2014 02:07:12 PM GMT
Another SAN cert to test is (GET) is switching to a SAN cert on 5/26/2015 and anyone still using ColdFusion 8 is going to be negatively impacted. WORKAROUND: ColdFusion 8 & 9 cannot perform a CFHTTP GET on the URL: but CFX_HTTP5 is able to access the SAN cert without throwing an error.
Comment by External U.
15306 | May 13, 2015 11:42:35 AM GMT
Why is this marked as fixed? I'm using ColdFusion 11 and am pointing to and getting the same error making an http request. The cert is for with the subject alternative name set to The http request works fine when I point to the production environment
Comment by External U.
15307 | November 10, 2015 09:47:34 AM GMT