On 30 September 2025 we will:
- Disable TLS 1.0 and TLS 1.1 on all public endpoints – license activation and FusionReactor Cloud ingestion.
- Replace our Sectigo certificate with a Let’s Encrypt chain (ISRG Root X1/X2).
If your JVM already speaks TLS 1.2 and trusts Let’s Encrypt, you won’t even notice. If it doesn’t, or you don’t know for sure then read on.
Why we need to do this
Transport Layer Security (TLS) is a cryptographic protocol that secures communications over computer networks. It plays a critical role in protecting sensitive data exchanged between clients (such as browsers or APIs) and servers by encrypting the traffic to prevent eavesdropping, tampering, and message forgery.
TLS is especially important for web applications, APIs, and monitoring tools like FusionReactor, which may transmit sensitive data such as credentials or telemetry. Without proper encryption, this data can be exposed to attackers.
Modern TLS versions (1.2 and above) are built to withstand known vulnerabilities and provide robust security. The move to TLS 1.2+ and Let’s Encrypt keeps FusionReactor aligned with the rest of the industry. Legacy protocols have well-known flaws such as POODLE and BEAST, and major vendors are pulling the plug:
- Microsoft has started disabling TLS 1.0/1.1 by default in Windows 11 and upcoming Windows Server releases.
- Apple deprecated both protocols across iOS 15, macOS 12 and later developer.apple.com.
On the certificate side, browser makers and the CA/Browser Forum are reducing certificate lifetimes – from 398 days today to 47 days by 2029 (digicert.comsecurityboulevard.com) – which makes short-lived, automatically renewed Let’s Encrypt chains the modern best practice. Let’s Encrypt’s 90-day model was designed exactly for this reason, letsencrypt.org.
Adopting these standards now means fewer urgent security patch days later and ensures continued compliance with frameworks like PCI DSS, which already forbids “early TLS”.
Who is affected?
- Java 6 / Java 7
- Early Java 8 (builds before u101)
- Containers or appliances using an old certificate (cacerts) store
- ColdFusion and other application servers that use these Java versions
- ColdFusion 8 and 9 commonly run on Java 6.
- ColdFusion 10 often runs on Java 7
- ColdFusion 11 often runs on Java 8 and shipped with Java 7 early on.
(Your FusionReactor agent version is irrelevant – TLS support lives entirely in the JVM.)
Default JVM bundled with Lucee and ColdFusion
| Platform/Installer | Bundled Java Version* | Likely Status |
|---|---|---|
| Lucee 4.x installers | Java 6 / 7 | At risk – TLS 1.2 usually off |
| Lucee 5.x | Java 8 (u92–u121) | May need TLS 1.2 switch on |
| Lucee 6.x | Java 11 | Ready out-of-the-box |
| Adobe ColdFusion 8–9 | Java 6 | At risk |
| ColdFusion 10 | Java 7 | At risk |
| ColdFusion 11 | Java 7 (early) → Java 8 (later) | Check your build |
| ColdFusion 2016 / 2018 | Java 8 | Flip TLS 1.2 on if build < u101 |
| ColdFusion 2021+ | Java 11 | Ready |
*Installers ship these JDKs by default. Admins sometimes swap in a newer JDK, so always run our quick probe to be sure.
How to test if you are affected
Locate the exact JVM your server uses
- Adobe ColdFusion
– Open cfusion/bin/jvm.config
– Copy the full path after java.home=
- Lucee Server
– Open lucee/bin/setenv.sh (Linux) or setenv.bat (Windows)
– Look for LUCEE_JAVA_HOME= or JAVA_HOME=
- Standalone Tomcat
– Open bin/setenv.sh (or setenv.bat)
– Copy the path assigned to JAVA_HOME or JRE_HOME
- Any other Java stack
– On Linux/Unix: `ps -ef | grep java | head -1` → note the …/bin/java path
– On Windows: `where java` (Command Prompt) or `Get-Command java` (PowerShell)
2. Download the 6 kB probe
3. Run the probe with that JVM
<path-from-step 1>/bin/java -jar tls-probe.jar
# The probe connects to https://valid-isrgrootx1.letsencrypt.org/
# and prints the protocol it negotiated.
4. Interpret the result
✓ TLSv1.2 or TLSv1.3 → Your JVM is ready. No action needed.
✗ handshake_failure / TLSv1 / TLSv1.1 → Enable TLS 1.2
✗ PKIX path building failed → Import ISRG Root X1/X2 into cacerts
Three Mitigation Paths
| Path | Pros | Cons | Typical Time |
|---|---|---|---|
| Upgrade the JVM preferred | Future-proof, faster, fewer CVEs | Requires app re-test | ~30 min |
| Add TLS 1.2 + Let's Encrypt roots to current JVM | No code changes | Repeat per host; still legacy | ~10 min |
| Manual / offline licence activation | Works even on Java 5 | No auto-renew; manual once per server | ~5 min |
Path 1 – Upgrade the JVM
- Install Java 8 u121+, 11, 17 or 21.
- Point your service to it.
- Restart your Application Server – done.
Path 2 – Retrofit your current JVM
- Download ISRG Root X1 and X2 from letsencrypt.org/certificates. Learn more
bash
keytool -import -alias isrgrootx1 -keystore $JAVA_HOME/jre/lib/security/cacerts \
-file isrgrootx1.pem -storepass changeit -noprompt
keytool -import -alias isrgrootx2 -keystore $JAVA_HOME/jre/lib/security/cacerts \
-file isrgrootx2.pem -storepass changeit -noprompt
2. Force TLS 1.2 on Java 7 / early 8: add
jdk.tls.client.protocols=TLSv1.2
to
$JAVA_HOME/jre/lib/security/java.security.
Java 6 only: drop in BouncyCastle JSSE (copy bcprov and bctls jars to $JAVA_HOME/lib/ext and add security.provider.1=org.bouncycastle.jsse.provider.BouncyCastleJsse in java.security).
For more information, see this post
Path 3 – Manual / Offline activation
When you absolutely cannot enable TLS 1.2 or trust Let’s Encrypt.
- In the FusionReactor UI, choose Manual Activation on the about page and copy the activation code.
- On any internet-connected machine, open https://fusion-reactor.com/manual, paste the activation code, click activate, then copy the activation key.
- Paste the activation key into the FusionReactor UI and click activate. Learn more.
FAQ’s
Is TLS 1.3 required?
No – TLS 1.2 minimum, TLS 1.3 optional.
Will this affect both on-premise and cloud users?
Yes, all agents will be affected.
What happens if I don’t do this?
If your FusionReactor agent no longer has sufficient security measures, it will no longer be able to license automatically or ship data to the cloud.
