ColdFusion SFTP and FTPS Secure Connection Failure

I have seen a lot more people asking questions about making SFTP or FTPS secure connections from ColdFusion using the <CFFTP> tag. They are trying to figure out why they cannot make a connection. Often the error is "Algorithm negotiation fail" or "Connection Error". People are posting their questions on many support forums including Adobes forums and their new ColdFusion Community Portal. This is a problem people are experiencing in ColdFusion 10 and ColdFusion 11.

In the last few years we've seen a huge shift in SSL/TLS security including the removal of older less secure protocols and forcing secure connections to use the newer stronger protocols with stronger TLS certificates and stronger encryption cyphers. As such older systems need to be upgraded to handle the newer security protocols. More recently plain old unsecure FTP portals have been the focus of change to SFTP or FTPS.

At CF Webtools we've run into this same problem several times with multiple clients. It was so much of a problem that I needed to spend some dedicated time to see how we could resolve this issue.

The first thing I discovered is that this issue is a known "bug" that has been reported to Adobe. It's been a long known issue and somehow the fix which is in ColdFusion 2016 has not been included in an update for earlier ColdFusion versions. However, Adobe has affirmed to me that this fix is scheduled for an upcoming update.

Because it was fixed in ColdFusion 2016 I was able to inspect the included jar files to see if the one that handles CFFTP or secure communications was newer than the one(s) in ColdFusion 11. What I found is that jsch-0.1.44m.jar had been replaced by jsch-0.1.52m.jar. The JSCH jar library is the library that handles Java Secure Channel communications. "JSch allows you to connect to an sshd server and use port forwarding, X11 forwarding, file transfer, etc., and you can integrate its functionality into your own Java programs."

After seeing this was upgraded I had an ah-ha moment and figured it was worth a try to copy this newer version into my ColdFusion 11 test server and see what happened. The new version is in ./ColdFusion2016/cfusion/lib folder. You can download the free ColdFusion 2016 Developer Edition and install it anywhere so you can get access to the updated jar file. Once you have the new jar file copy it into ColdFusion 11. The proper way to do this is to remove or rename the old jar file version in your ColdFusion11/cfusion (or instance name)/lib folder then copy the new jar file version into the same folder. Then start or restart ColdFusion 11. That's it. You're done. The bug is fixed and you're good to go with SFTP or FTPS using <CFFTP> in ColdFusion 11.

This is not an approved fix from Adobe. I do not know if there is some unknown issue that could be created by doing this. However, I do know that everyone I've talked to that has tried this has had their secure FTP issues resolved. Additionally I have not tried this 'fix' in ColdFusion 10. However, if you are running into this issue with ColdFusion 10 it's worth the minimal effort to give it a try.

If you need someone to make this change on your ColdFusion server then contact us, we can help. CF Webtools is here to fill your needs and solve your problems. If you have a perplexing issue with ColdFusion servers, code, connections, or if you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations @

TLS1.2 for ColdFusion 9 and Older

The upcoming Authorize.NET switch to using TLS 1.2 only has a lot of people scrambling to get their servers updated. This has been a long planned transition at Authorize.NET and at many/most/all other payment processing companies. The inevitable facts are that TLS 1.0 and TLS 1.1 are outdated and they are going away. At CF Webtools we have been preparing for this inevitable day for the past few years.

ColdFusion 9.0.n is not tested to work on Java 1.8 and I have had cases were certain features of ColdFusion 9 did not work with Java 1.8. I have not tried any older versions of ColdFusion on Java 1.8 and I'm not going to. Adobe has not certified any versions of ColdFusion older than version 10 Update 14 (or ColdFusion 11 Update 2 and older). All of that being said, there is a workaround that uses a 3rd party commercial solution to make TLS 1.2 connections from ColdFusion 9. It works well, but I do not recommend that as a long term solution. The preferred long term solution is upgrading the server(s) and ColdFusion version to currently supported versions. This way there will be security updates to help protect against new threats. The commercial third-party CFX tag will require recoding the CFHTTP calls for the new CFX tag. The tag is CFX_HTTP5 and it is available here.

Follow the installation instructions that comes with the download and then you will have to recode your CFHTTP calls similar to the examples below. The code examples are for the older Authorize.NET Advanced Integration Method (AIM) API calls that you are most likely using in your older ColdFusion CFHTTP calls.

view plain print about
1<cfset authURL = "" />
2 <cfif AuthNetMode eq "live">
3 <cfset authURL = "" />
4 </cfif>
6<!--- CFHTTP Call - Your code might look something like this --->
7<cfhttp url="#authURL#" method="post" result="cfhttp">
8 <cfhttpparam type="FORMFIELD" name="x_Login" value="#AuthLogin#">
9 <cfhttpparam type="FORMFIELD" name="x_Password" value="#AuthPassword#">
10 <cfhttpparam type="FORMFIELD" name="x_merchant_email" value="#AuthEmail#">
11 <cfhttpparam type="FORMFIELD" name="x_delim_data" value="true">
12 <cfhttpparam type="FORMFIELD" name="x_test_request" value="#x_test_request#">
14 <!--- we're using AUTH_ONLY so the card isn't charged until the order is processed --->
15 <cfhttpparam type="FORMFIELD" name="x_type" value="AUTH_ONLY">
16 <cfhttpparam type="FORMFIELD" name="x_method" value="cc">
18 <cfhttpparam type="FORMFIELD" name="x_amount" value="#orderTotal#">
19 <cfhttpparam type="FORMFIELD" name="x_card_num" value="#cardNumber#">
20 <cfhttpparam type="FORMFIELD" name="x_exp_date" value="#cardExpiration#">
21 <cfif isDefined("cardSecurityCode") and cardSecurityCode eq "">
22 <cfhttpparam type="FORMFIELD" name="x_card_code" value="#cardSecurityCode#">
23 </cfif>
25 <!--- If you want an email to go to the customer via
26change this to true. Make sure is configured properly. --->

27 <cfhttpparam type="FORMFIELD" name="x_email_customer" value="#x_email_customer#">
29 <cfhttpparam type="FORMFIELD" name="x_first_name" value="#billingFirstName#">
30 <cfhttpparam type="FORMFIELD" name="x_last_name" value="#billingLastName#">
31 <cfhttpparam type="FORMFIELD" name="x_company" value="#billingCompany#">
32 <cfhttpparam type="FORMFIELD" name="x_address" value="#billingAddress#">
33 <cfhttpparam type="FORMFIELD" name="x_city" value="#billingCity#">
34 <cfhttpparam type="FORMFIELD" name="x_state" value="#billingState#">
35 <cfhttpparam type="FORMFIELD" name="x_zip" value="#billingZip#">
36 <cfhttpparam type="FORMFIELD" name="x_country" value="#billingCountry#">
38 <cfhttpparam type="FORMFIELD" name="x_customer_ip" value="#cgi.remote_address#">
39 <cfhttpparam type="FORMFIELD" name="x_Email" value="#billingEmail#">
40 <cfhttpparam type="FORMFIELD" name="x_Phone" value="#billingPhone#">
42 <cfhttpparam type="FORMFIELD" name="x_ship_to_first_name" value="#shippingFirstName#">
43 <cfhttpparam type="FORMFIELD" name="x_ship_to_last_name" value="#shippingLastName#">
44 <cfhttpparam type="FORMFIELD" name="x_ship_to_company" value="#shippingCompany#">
45 <cfhttpparam type="FORMFIELD" name="x_ship_to_address" value="#shippingAddress#">
46 <cfhttpparam type="FORMFIELD" name="x_ship_to_city" value="#shippingCity#">
47 <cfhttpparam type="FORMFIELD" name="x_ship_to_state" value="#shippingState#">
48 <cfhttpparam type="FORMFIELD" name="x_ship_to_zip" value="#shippingZip#">
49 <cfhttpparam type="FORMFIELD" name="x_ship_to_country" value="#shippingCountry#">
50 <cfhttpparam type="FORMFIELD" name="x_Description" value="#description#">
51 <cfhttpparam type="FORMFIELD" name="x_invoice_num" value="#invoicenum#">
52 </cfhttp>
54 <cfset response = cfhttp.fileContent>

To refactor your code you will want to do something like this.

view plain print about
1<cfset authURL = "" />
2 <cfif AuthNetMode eq "live">
3 <cfset authURL = "" />
4 </cfif>
5<!--- CFX_HTTP5 Call - You'll want to refactor your code in this fashion --->
7<cfset httpBody = "x_Login=#AuthLogin#&
8 x_Password=#AuthPassword#&
9 x_merchant_email=#AuthEmail#&
10 x_delim_data=true&
11 x_test_request=#x_test_request#&
12 x_type=AUTH_ONLY&
13 x_method=cc&
14 x_amount=#orderTotal#&
15 x_card_num=#cardNumber#&
16 x_exp_date=#cardExpiration#&
17 x_first_name=#billingFirstName#&
18 x_last_name=#billingLastName#&
19 x_company=#billingCompany#&
20 x_address=#billingAddress#&
21 x_city=#billingCity#&
22 x_state=#billingState#&
23 x_zip=#billingZip#&
24 x_country=#billingCountry#&
25 x_customer_ip=#cgi.remote_address#&
26 x_Email=#billingEmail#&
27 x_Phone=#billingPhone#&
28 x_ship_to_first_name=#shippingFirstName#&
29 x_ship_to_last_name=#shippingLastName#&
30 x_ship_to_company=#shippingCompany#&
31 x_ship_to_address=#shippingAddress#&
32 x_ship_to_city=#shippingCity#&
33 x_ship_to_state=#shippingState#&
34 x_ship_to_zip=#shippingZip#&
35 x_ship_to_country=#shippingCountry#&
36 x_Description=#description#&
37 x_invoice_num=#invoicenum#"

39 <!--- If you want an email to go to the customer via
40change this to true. Make sure is configured properly. --->

41 <cfset httpBody = httpBody & "&x_email_customer=#x_email_customer#">
43 <cfif isDefined("cardSecurityCode") and cardSecurityCode neq "">
44 <cfset httpBody = httpBody & "&x_card_code=#cardSecurityCode#">
45 </cfif>
47 <cfset cfxhttp = {}>
48 <cfset headers = "Content-Type: application/x-www-form-urlencoded">
49 <cfx_http5 url="#authURL#" method="post" out="cfxhttp.body" outqhead="cfxhttp.QHEAD" outhead="cfxhttp.RHEAD" ssl="5" body="#httpBody#" header="#headers#">
50 </cfx_http5>
52 <cfset response = cfxhttp.body>

The code is a minor change and relatively easy to do. I've tested this method in a production environment and it works fine. I do not recommend this as a long term solution. The preferred long term solution is upgrading the server(s) and ColdFusion version to currently supported versions. This way there will be security updates to help protect against new threats. If you are on ColdFusion 10 or 11 then the best option is to install the ColdFusion patches and upgrade the Java version to 1.8 then you will be good to go. If you need an experience ColdFusion developer to make these changes then please do contact us, we will be happy to assist.

This is one more friendly reminder to make sure your ColdFusion servers are patched! Either patch them yourself, have your hosting provider patch them. If you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at

UPDATE: This fix will not work for Windows 2003 Server as there is no support from Microsoft for TLS 1.1 or 1.2 in this server version.

Authorize.NET Temporarily Ending TLS 1.1 and TLS 1.0 Support, is your ColdFusion Server Ready?

At CF Webtools we have been preparing for this inevitable day for the past few years. We've been upgrading our clients servers and services to handle TLS 1.2 calls to Authorize.Net and other third party processors for a while now. Recently Authorize.Net announced a "Temporary Disablement of TLS 1.0/1.1" for "a few hours on January 30, 2018 and then again on February 8, 2018." This is in preparation for the final disablement of TLS1.0/1.1 on February 28, 2018.

As you may be aware, new PCI DSS requirements state that all payment systems must disable earlier versions of TLS protocols. These older protocols, TLS 1.0 and TLS 1.1, are highly vulnerable to security breaches and will be disabled by Authorize.Net on February 28, 2018.

To help you identify if you're using one of the older TLS protocols, Authorize.Net will temporarily disable those connections for a few hours on January 30, 2018 and then again on February 8, 2018.

Based on the API connection you are using, on either one of these two days you will not be able to process transactions for a short period of time. If you don't know which API you're using, your solution provider or development partner might be a good resource to help identify it. This disablement will occur on one of the following dates and time:

  • Akamai-enabled API connections will occur on January 30, 2018 between 9:00 AM and 1:00 PM Pacific time.
  • All other API connections will occur on February 8, 2018 between 11:00 AM and 1:00 PM Pacific time.
Merchants using TLS 1.2 by these dates will not be affected by the temporary disablement. We strongly recommend that connections still using TLS 1.0 or TLS 1.1 be updated as soon as possible to the stronger TLS 1.2 protocol.

This means that if you are using older methods to make calls to Authorize.Net that are not capable of making TLS 1.2 connections then you will NOT be able to process credit card transactions.

This affects ALL ColdFusion versions 9.0.2 and older! This also affects ColdFusion 10 Update 17 and older. If your server is running any of these older versions of ColdFusion and your server is processing credit cards with Authorize.Net then this advisory applies to your server.

CF Webtools has been successfully mitigating this issue for clients servers for the past couple years and we are very experienced in resolving these security related issues. In a previous blog post I tested which TLS levels were supported by various ColdFusion versions on various Java versions and produced an easy to read chart.

If your ColdFusion server is affected by this or if you do not know if your ColdFusion server is affected by this then please contact us (much) sooner than later. Our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at

On my Way to CFSummit 2017

For the first time ever I'm headed to CF Summit. This should be fun and exciting! I'm waiting on Uber to show up and then I'm gone. I just have to get through TSA without a full cavity search. I'll be landing in Vegas around 4pm Vegas time. Let the party begin!

So far I'm thinking these sessions. All subject to change.

9:00 AM - 10:15 AM Day 1 General Session
10:30 AM - 11:30 AM send.Better() - Giving Email a REST
11:45 AM - 12:45 PM Solving problems in ways never before possible, with FusionReactor 7 and FR CLOUD
1:45 PM - 2:45 PM Dockerizing a ColdFusion Enterprise Application, a Case Study
3:00 PM - 4:00 PM Level Up Your Web Apps with Amazon Web Services
4:15 PM - 5:15 PM Power of Simplicity in FW/1 Framework

9:00 AM - 10:00 AM Day 2 General Session: How APIs Accelerate Digital Transformation
10:15 AM - 11:15 AM Application Performance Monitoring Suite in ColdFusion Aether.
11:30 AM - 12:30 PM Securing Mature CFML Codebases
2:45 PM - 3:45 PM Language improvements in ColdFusion Aether
4:00 PM - 5:00 PM CFConfig - A New Way to Manage Your ColdFusion Engine Config
5:15 PM - 5:30 PM Closing Session and Raffle Drawing

Cryptojacking: Hacking for Bitcoins

This is a brief follow up to my previous article on Hacking for Bitcoins in which I detailed how servers were being hijacked with cryptocurrency miners and using your servers CPU power to mine for Bitcoins or other blockchain cryptocurrencies. This is an updated twist on that hack. I saw this Ars Technica article today and it points out that the newer twist is to inject code into your websites code and then process cryptocurrency mining on your website user's computers. This distributes the CPU processing by thousands instead of just taking over a few of your servers.

To do this, hackers are using which offers an easy-to-use programming interface that lets you setup your own website to process cryptocurrency on your visitors computers. There isn't a requirement to give notice to users that you are going to do this. What hackers are doing is using vulnerabilities in your server(s) and/or website(s) to inject this code in your website. It is estimated that there are about 2,500 websites that are currently compromised and using their users to process cryptocurrency. The fine article at Ars Technica indicates that it appears most are connected to two accounts. This might mean that the hackers can easily be traced and stopped. But others will surely follow in their path.

How do I know?

When Cryptojacking occurs, a direct side effect is that the website user CPU's are maxed out and system heat starts to increase. This is a tell tale sign that the website you are using is either using your computer for their gain or has been compromised and a hacker is using your computer for their gain. (It could also be one of those annoying Flash based ads that we all hate.) But check the site source code to see if there is anything linking to Coinhive or similar. Ars Technica also reported "Most of the affected sites concealed the connection to Coinhive by adding a link to the domain or one masquerading as a Sucuri firewall."

This is a growing problem and recently Malwarebytes reported that on average it performs about 8 million blocks per day to unauthorized mining pages. People who want to avoid these Cryptojacking scams can use Malwarebytes or another antivirus program that blocks abusive pages

From our point of view at CF Webtools, this is a good reminder to make sure your ColdFusion servers are secure, updated and patched. It's also a good reason as to why your website code (all code really) should be in a secured version control system. That way if something like this did happen to your website code you can replace it from a known clean copy instead of digging through the code looking for the injected code. Additionally, CF Webtools offers PenTesting to check your website code for vulnerabilities. If you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at

Hacking for Bitcoins

Are your free CPU cycles making others rich? There's a chance they are and it's at your expense. A recent article at states that "At Least 1.65 Million Computers Are Mining Cryptocurrency for Hackers So Far This Year". If this is to be believed then it's possible a server you are running has been compromised and is actually mining cyrptocurrency for the hackers. This type of breach is called Cryptojacking and it's costing you and/or your company money.

Cyrptocurrency is an anonymous, digital currency that is supposed to be untraceable. It's used on the internet to purchase more and more products and services. One of the most common forms of cryptocurrency is Bitcoin. This is from the Wikipedia entry on Bitcoin.

Bitcoin is a worldwide cryptocurrency and digital payment system called the first decentralized digital currency, since the system works without a central repository or single administrator. It was invented by an unknown programmer, or a group of programmers, under the name Satoshi Nakamoto and released as open-source software in 2009. The system is peer-to-peer, and transactions take place between users directly, without an intermediary. These transactions are verified by network nodes and recorded in a public distributed ledger called a blockchain.

Besides being created as a reward for mining, bitcoin can be exchanged for other currencies, products, and services. As of February 2015, over 100,000 merchants and vendors accepted bitcoin as payment. Bitcoin can also be held as an investment. According to research produced by Cambridge University in 2017, there are 2.9 to 5.8 million unique users using a cryptocurrency wallet, most of them using bitcoin. ...

Bitcoin Mining is a record-keeping service that runs on peoples computers, servers, or specialized Mining Devices, that are setup by individuals to help process Bitcoin transactions. As a reward for doing this you are given newly created bitcoins and transaction fees. ie. You can make money by mining for Bitcoin.

This reward is enough that hackers have taken it to the next level and started hacking servers around the world so they can install mining software and use YOUR computers and servers to make money for themselves.

Case Study

CF Webtools has seen this type of hack in the real world. We recently had a company come to us seeking our services for both Server Administration and ColdFusion programming. Part of taking this new company on as a client we performed a security review on all of their servers. They also had existing issues that we needed to look at in particular. Their web server was rebooting multiple times per day at what seemed like random intervals.

Upon review we found the web server was always running at 100% CPU usage with no services claiming to be using that much CPU power. Certainly not ColdFusion or IIS. We decided to install Malware Bytes and scanned for malware. It didn't take long to find that indeed there was malware running on the server. What we found surprised us only because we had not seen this in action before. It was a cryptocurrency miner and it was so intensive that it would crash the server. All attempts to remove the malware failed. It would end up back on the server in a short period of time. The fact is this server was compromised. To resolve the issue we sent one of our decommissioned, but powerful servers, preinstalled with a clean OS to their data center. Then our Operations Manager went on the road to install the new server as well as a physical firewall. We essentially rearchitected their entire server setup. Meanwhile, Malware bytes did it's best to keep the malware at bay while I recreated their web server on the new server. It was a busy week (or more), but we were able to clean the code on the clients server and put that on the new server. We also had to research and rebuild all the web application dependancies from scratch. When it was all said and done we replaced the compromised server with the new one and put all their servers behind a Cisco ASA.

This case of Hacking for Bitcoins proved costly in the end to the company who's systems were compromised all while providing a free profit to the hacker(s).

This is one more friendly reminder to make sure your ColdFusion servers are patched! Either patch them yourself, have your hosting provider patch them. If you need help upgrading your VM or patching your server (or anything else) our operations group is standing by 24/7 - give us a call at 402-408-3733, or send a note to operations at

UPDATE: I saw this Ars Technica article today and it is directly related to this. Cryptojacking is bigger than most people think.

ColdFusion 11 Update 13 and ColdFusion 2016 Update 5

Adobe just released security updates for ColdFusion 11 and ColdFusion 2016. This is a critical security update and you should be updating your ColdFusion servers.

With ColdFusion 11 Update 13 and ColdFusion 2016 Update 5 there are additional manual updates that are required to complete the security patch. The additional requirements are the same for both ColdFusion 11 and ColdFusion 2016 and the remaining information pertains to both versions. Both updates require that ColdFusion be running on Java version 1.8.0_121 or higher. For reference, ColdFusion 11 comes with Java version 1.8.0_25 (* originally it came with Java 1.7.0_nn) and ColdFusion 2016 comes with Java version 1.8.0_72. The Java that needs to be installed is different from the "Windows User" Java client that may already be installed. The installer is available from Oracle. Once the new Java version is installed, the jvm.config file for each ColdFusion instance needs to be updated to point to the new Java version installation path. If you're running the Enterprise version of ColdFusion, there's a likely chance there is more than one ColdFusion instance running.

Part of the instructions from Adobe says that if your ColdFusion server is installed as a J2EE server then there is an additional manual configuration that you ned to do. However, every installation of ColdFusion since the release of ColdFusion 10 is a J2EE or JEE installation. If you do not remember when you installed ColdFusion or you were not the one that did the installation, there are two ways to do the installation; "Server Configuration" and JEE Configuration". What Adobe really means is that if you are using a third party JEE server, "JEE Configuration", and not the built-in Tomcat JEE server, "Server Configuration", then there is an additional step.

If your ColdFusion server is running on a third party JEE server such as WebLogic, WildFly/EAP, custom Apache Tomcat, etc (Not the built in Tomcat that comes with ColdFusion), then the following step needs to be completed.

Set the following JVM flag, "-Djdk.serialFilter=!org.mozilla.** ", in the respective startup file depending on the type of Application Server being used.

For example,

  • On Apache Tomcat Application Server, edit JAVA_OPTS in the 'Catalina.bat/sh' file
  • On WebLogic Application Server, edit JAVA_OPTIONS in the 'startWeblogic.cmd' file
  • On a WildFly/EAP Application Server, edit JAVA_OPTS in the 'standalone.conf' file

This is one more friendly reminder to make sure your ColdFusion servers are patched! Either patch them yourself, have your hosting provider patch them or if they are not familiar or knowledgeable with ColdFusion contact us at CF Webtools to patch your servers.

*Note: ColdFusion11 when it was first released came with a version of Java 1.7.0_nn. Adobe later re-released ColdFusion 11 with Java 1.8.0_25. If you have ColdFusion 11 still running on Java 1.7 I highly recommend that Java be upgraded to Java 1.8. Oracle is no longer supporting Java 1.7 and 1.7 is long past it's end of life. Even though the Adobe instructions for this current security update states that you can run Java 1.7.0_131, I highly recommend upgrading to Java 1.8. Personally I will not install Java 1.7 on a clients servers and sign off on it being 'secure'.

What's In Your CFIDE Folder?

Over the years of working on ColdFusion servers for CF Webtools I have encountered many servers that have been breached (hacked). In most cases the cause was for lack of better description "human error". I say human error because no one properly secured the server when it was installed, no one maintained the server over the years of use and no one was checking to see if anyone had tried hacking the server.

Then something BAD happened that caused EVERYONE to notice the server was breached. Maybe it was your credit card processor informing you that customer cards are being stolen when they purchased from your online store? Maybe it was your servers IP being black listed because it was spewing tens of thousands of spam emails? Maybe you were notified that your medical website had been breached? Maybe it was a notice from the FBI that your server was part of a list of servers that were known to have been breached. Those are NOT good days!

Many times these companies contact CF Webtools for our expertise in resolving breached servers. When they do Mark Kruger, aka. ColdFusion Muse sends me in to investigate, record any data/forensics that I can and mitigate the situation while we simultaneously build a new server for the client. Usually this is what it takes to recover from a breach.

Over time I have collected a large number of 'hack files' that contain the code to breach a website and steal credit cards, entire databases, or even load malware onto an unsuspecting users computer. These files are typically found in an unsecured CFIDE folder. Here are a couple examples.

If you happen to see anything that looks like those files then the server has been breached. If your team is properly securing and maintaining your ColdFusion servers you should never see anything like this. However, if you are seeing files like this in your CFIDE folder or files in your website that are unaccounted for, then it's very likely the server has been breached.

Now what? That is a very open ended question. The first thing to do is accept the fact that it happened and understand that it's happened to companies that are far bigger and with much bigger IT budgets than yours. Remember Target? Now you have to figure out how the breach occurred, determine how much was breached, mitigate the breach as best as you can and then in most cases start building and securing new server(s). It's my belief that once a server has been breached we can never be 100% certain that we've found everything that was put on the server by that breach. Once you have a clean server then you clean and migrate your code and other resources to the new server. This can be a huge and daunting task especially if you have a minimal IT department or none at all.

If no one on your IT team is responsible for maintaining the servers and/or your hosting company isn't maintaining the servers then, who will? Who will make sure they are secure? We will.

Who you Gonna Call? CF Webtools!

Wildcard and SAN SSL with CFHTTP in ColdFusion

Here at CF Webtools are getting a lot of companies coming to us with various CFHTTP issues. Lately this has been happening even more as SSL has been in the news more and certain SSL protocols and encryption levels have gone away or are on the way out. Most recently Wildcard and Subject Alternative Name certificates have been a concern for those running older ColdFusion servers with older versions of Java.

What is a Wildcard SSL certificates versus a Subject Alternative Name (SAN) certificates?

A wildcard SSL certificate allows for unlimited subdomains to be protected with a single certificate. For example if you owned "" a wildcard would allow you to secure,, or Such a certificate would be issued to * and it could secure any subdomain of for the device on which it was installed.

A SAN cert allows for multiple domain names to be protected with a single certificate. For example the SSL certificate issued to multiple fully qualified domains such as,, This allows for the SAN SSL to be used for multiple sites on the same server all bound to the same IP Address. This does relate back to Server Name Indication (SNI) for web serves that I talked about a while back. In addition, this article by Thawte is a good primer. Let's take them each in turn.


ColdFusion 8 & 9 CFHTTP still works with as of May 26th, 2015 upgraded their SSL to SHA-2 (256bit) encryption. See this post. At CF Webtools some of our clients have received this or similar notice.

Important: Security Certificate Upgrades on May 26th

Authorize.Net is upgrading our infrastructure to enhance system performance and security. On May 26, 2015, we are upgrading to new security certificates, which are signed using Security Hash Algorithm 2 (SHA-2) and 2048-bit signatures. Most modern operating systems and web servers support certificates that use SHA-2, however, there is a concern that older software--especially software based on outdated versions of Java--may not.

If any updates are necessary, please refer your web developer to this blog post in our Developer Community, which has all of the certificate information they will need for this update. Our sandbox environment has already been updated so that your developer can validate that your solution will continue to work using SHA-2 signed certificates, prior to May 26th.

After the update is complete on May 26th, any website or payment solution that cannot validate SHA-2 signed certificates will fail to connect to Authorize.Net's servers.

Some have been saying that your ColdFusion 8 CFHTTP using Java 1.6.0_nn will no longer work with We've found this to not be the case. We have a crack team of ColdFusion Guru's here at CF Webtools and we've been testing for the potential fall out of these and other SSL upgrades for a few months. Personally, I have a testbed system here with ColdFusion versions 8, 9, 10 and 11 and that is setup for testing CFHTTP and SSL issues and I can easily test the same CFHTTP code on each ColdFusion version with each version of Java from 1.6 to 1.8. Another member of our team has been working with support at to ensure the upgrade to their SSL will work with existing ColdFusion 8 on Java 1.6 installations.


More Entries