TLS 1.2 Connection Failure Using CommandBox, Adobe ColdFusion, And CFHTTP

This morning, I was using my local CommandBox Docker container, running Adobe ColdFusion 2025, to connect to a remote API using CFHttp. The API request was immediately failing with the error response:

Connection Failure. Status code unavailable.

Historically, this error has meant that my JVM was missing the SSL certificate used by the remote host; and I could usually work around the issue by downloading and installing the SSL certificate in the JVM's trusted cert store.

In this case, however, my problem was different. I was connecting to a host that only supported TLS 1.2. And, it seems that when inbound SSL is enabled in CommandBox, the elliptic-curve algorithms that many TLS 1.2 hosts require are disabled due to a really old Adobe ColdFusion issue.

At this point, I was stumped. So I pointed Claude Code at the problem and within a matter of minutes, Claude identified the issue (which I outlined above) and provided me with a viable workaround. This problem space is pretty far over my head, so I'm just going to provide Claude's explanation below.

Claude Code Explains the TLS 1.2 Issue

Caution: the following section has been generated by Claude Code Opus 5.5 (and edited by me). I have verified that the fix works on my end; but since this topic is beyond my understanding, I cannot vouch for the low-level details outlined below.

Why ECC was disabled. Around the ColdFusion 10/11 and Java 7/8 era, Adobe ColdFusion when paired with the JVM's elliptic-curve (ECC) TLS suites had handshake problems. Adobe's own knowledge base (KB) for SSL on ColdFusion's built-in web server port told admins to add -Dcom.sun.net.ssl.enableECC=false to jvm.config. When it's false, Java drops every elliptic-curve cipher suite (TLS_ECDHE_*, TLS_ECDH_*) from its defaults.

The CommandBox server launcher, RunWar, built that advice into its code. When RunWar starts an Adobe engine with an HTTPS listener enabled, it calls:

System.setProperty( "com.sun.net.ssl.enableECC", "false"  )

This is controlled by an sslEccDisable option, which defaults to true. I haven't confirmed the exact underlying Adobe problem; the Adobe KB and the CommandBox community threads show it as a known fix for SSL on Adobe engines. The catch is that the property applies to the whole JVM. It covers outbound CFHttp calls too, not just the HTTPS listener it was meant to fix.

Why it broke your API call. A modern JVM negotiates TLS 1.3 when it can. TLS 1.3 cipher suites don't name a key exchange method, so the ECC property didn't affect them, and calls to TLS 1.3 servers kept working. The remote API host offers only TLS 1.2, with two kinds of key exchange: ECDHE and plain RSA. ECDHE was off because of RunWar. And JDK 21 disables plain RSA key exchange by default (TLS_RSA_* is in jdk.tls.disabledAlgorithms).

The two sides had no cipher suite in common, so the API closed the connection mid-handshake, and ColdFusion reported "Received close_notify during handshake." A plain Java program run in the same container with the same JDK connected fine; it failed the same way only when started with -Dcom.sun.net.ssl.enableECC=false, which isolated the cause.

How the setting was changed. CommandBox copies runwar.options from server.json directly into RunWar's config, where the SSLECCDisable key maps to that sslEccDisable option. Setting it to false means RunWar never sets the property, so Java keeps its default ECDHE suites.

Passing -Dcom.sun.net.ssl.enableECC=true as a JVM argument most likely wouldn't have worked (my inference, not tested): RunWar sets the property itself after the JVM has started, so it would overwrite the flag. Local HTTPS kept working, which suggests the original Adobe problem is gone on JDK 21 and ColdFusion 2025.

Updating My server.json Settings

Once Claude Code outlined the problem, I went into my server.json settings and added the runwar.options section. I'm showing you my whole server.json here for context; but only the net-new setting added today is SSLECCDisable:

{
	"name": "bennadel-dev",
	"app": {
		"cfengine": "adobe@2025.0.14"
	},
	"profile": "development",
	"web": {
		"host": "127.0.0.1",
		"bindings": {
			"HTTP": {
				"enable": true,
				"listen": 8080
			},
			"SSL": {
				"enable": true,
				"listen": 8443
			}
		},
		"rules": [
			"not is-file and not is-directory -> rewrite('/index.cfm%U')"
		],
		"blockCFAdmin": false,
		"blockSensitivePaths": true,
		"blockFlashRemoting": true
	},
	"runwar": {
		"options": {
			"SSLECCDisable": false
		}
	}
}

I bake the server.json file into my CommandBox Docker image via the Dockerfile so that CommandBox can pre-install the CFML engine. So after I made this change, I had to rebuild my image and spin up a new ColdFusion container. But once I did, my CFHttp requests to the remote API host start working!

Aside: I don't have this TLS 1.2 issue in production because this blog runs on a Windows VPS behind IIS. Which means that IIS terminates the SSL connection and ColdFusion has no need to have SSL enabled; which, in turn, means it has no need to disable the elliptic-curve algorithms.

It's kind of wild that Claude Code can figure this stuff out. I still like to code my personal projects by hand as a mental exercise; but being able to lean on AI for this deep-in-the-weeds debugging is a true unlock.