For most, you should read on, especially about an important change regarding TLS support (and calling out to servers not yet running TLS 1.2 or above). I cover that and other important topics:
- What's in the JVM update, do you need to update to it?
- A key change in this Java update: calls out to TLS 1.1 or 1.0 no longer allowed, by default
- Re-enabling support for calling out to old TLS versions
- Groundhog day: you'll need do make this java.security file change on any later JVM updates
- Should you update to the new JVM version?
- The importance of testing such updates/changes
- More questions you may surely have, and finding answers to them
- Obtaining the updated Java installers
What's in the JVM update, do you need to update to it?
First note that you can read about the new JVM updates in their respective release notes:
As is usually the case, the release notes mention bug fixes, and security fixes. Regarding the latter, one seems limited to those using the Java security sandbox. (For my readers running ColdFusion, I can't tell if that means there is an exposure only if the CF Security Sandbox feature is enabled or not.)
But another security change may be important to many and could cause compatibility issues.
A key change in this Java update: calls out to TLS 1.1 or 1.0 no longer allowed, by default
This April JVM update is the first to imposes an important new change, that fellow CF community contributor Pete Freitag wrote about back on Apr 15, TLSv1 and TLSv1.1 Disabled by Default in Java after April 2021. See that and the JVM update technotes above which clarify that change.
For CF developers and administrators, this is about any cfhttp calls, any web service calls (cfinvoke/cfobject/createobject), any datasource or mail configuration, etc where CF is talking to some other server via https. If that server supports only TLS 1.1 or earlier, you will find that calls from java/CF to such a TLS 1.1/1.0 server will now fail, by default.
This is done by Oracle in the interest of protecting your server from calling other servers that have not been updated for the more secure TLS 1.2 version or above. (TLS 1.2 was released in 2008, but many servers you call out to may still not yet have been updated to support it, such as those running Windows Server 2003 or even 2008. Over the years, different Windows versions added support for increasing TLS versions, first as options via configuration or later by default.)
While it's understandable that Oracle would add this protection, so many years after TLS 1.2 should be more prominent, the only problem is that your server may NEED to call out to some OTHER server that IS still running only TLS 1.1 (perhaps because their OS has not been updated), and you may have no control over how THAT server is configured. (I think Oracle's goal here is to help light a fire under more and more server administrators to GET their servers updated.)
But back to this changed JVM behavior, what if you don't want (or find your server or app can't work well with) this "protection"? Can we remove this "condom"? :-) Yes, yes you can. (Whether you SHOULD is of course a very different question.)
Re-enabling support for calling out to old TLS versions
The jvm update technotes also discuss how one can "revert" this new behavior:
"If you encounter issues, you can, at your own risk, re-enable the versions by removing "TLSv1" and/or "TLSv1.1" from the jdk.tls.disabledAlgorithms security property in the java.security configuration file." (emphasis added)
It may sound scary or challenging, but it's really not. First, where would you find this java.security file?
In Java 11, it's found in the JVM's /conf/security/ folder (such as C:\Program Files\Java\jdk-11.0.11\conf\security).
In Java 8, where it's found depends on whether you're running a JDK or a JRE. For a JDK, it's in the JVM's /jre/lib/security folder (such as C:\Program Files\Java\jdk1.8.0_291\jre\lib\security). For a JRE, it's in the JVM's /lib/security folder.
Next, make a copy of the file (for you to revert to if needed).
Then in the file, find the line (about 700 lines down) starting with:
You could remove the TLSv1, TLSv1.1, values (don't leave a spurious comma), then save the file, and then restart CF.
With that, you will re-enable calls out to such "dirty old servers". But note that you will need to keep doing this, with each JVM update...
Groundhog day: you'll need do make this java.security file change on any later JVM updates
Beware also that if you later implement a new JVM update, that later JVM will ALSO include this "protection" by default--in its own version of this file--and you will need to remove these TLS values from that NEW version of this file each time you update the JVM, for as long as you "need" to talk to servers that don't support at least TLS 1.2 or above.
Perhaps in time, you can instead persuade the servers you call out to to support TLS 1.2 and above. Again, I think that's part of Oracle's aim here.
Should you update to the new JVM version?
Moving back to this new JVM version itself, should you move to it?
Well, given the security vulnerability indicated to be fixed, as well as the improvement to protect your server from calling out to servers with older, less secure TLS versions, it seems that most would want to update the JVM, just like it's always important to update the JVM.
And consider also that Oracle updates the JVM about quarterly, so there will be another and another, each of which will again include all the above.
Speaking again now to my CF readers: to be clear Adobe always supports CF being run on the latest JVM update level that exists, for whatever JVM version is supported by the CF version you are running.
CF2021 and CF2018 support running on Java 11. CF2016 supported running on Java 8 or 11 (once a CF update was performed). So yes, those using CF2021, 2018 and 2016 should at a minimum update to the latest update of whatever JVM version they are using (8 or 11), and those on CF11 or 10 should update to the latest Java 8, if they are running that.
If you wonder "what version of CF supports what version of Java", I have another post I have done with a table which maps CF versions to supported Oracle Java versions.
The importance of testing such updates/changes
Of course, you should also always implement any such significant update or other change in some testing environment, rather than just updating your production serve only. At least then you can have some insight into the prospect of the update/change having a perhaps unexpected impact on your application.
Sadly, not everyone is setup to have a test environment, though of course everyone SHOULD> And note that insofar as testing of CF is concerned, you can implement ColdFusion for free on any supported OS (Windows, MacOS, Linux), with its free Developer or Trial editions.
More questions you may surely have, and finding answers to them
And there are certainly other questions which folks will have about JVM updates in general (and especially my CF readers in particular), including more on getting those binaries/installers (from Oracle or Adobe), on the difference between those offered by Adobe and those offered by Oracle, and on the implications of changing CF2016 from Java 8 to Java 11 (supported, but with caveats). They may also have questions on those "currently LTS" versions versus "more recent" Java versions, or on using non-Oracle JVMs, on Oracle licensing matters and still more. Others need help to know how to update the JVM, and some may easily make mistakes that I can help them avoid.
At some point I plan split out those more generic points out into their own post, so I can just point to it whenever I have news of these Java updates, as much of that info doesn't change from update to update.
As my posts above point out, I can also help you directly to apply the JVM updates, rather than leave you having to wade through lots of blog details, via my remote screeshare consulting.
Obtaining the updated Java installers
As I discuss in the other posts I link to above, Adobe offers has been offering a downloads page with Java installers since 2019.
The updated JVM is finally in place there, as of May 12, 2021.
Sadly, as of this writing, that page has NOT yet been updated to offer this new update. I had raised this concern to Adobe days after the update. IF ever they are delays, see my post above for discussions I have offered in the past about how the binaries offered at Oracle are identical in my testing. I will update this to strike this paragraph when I see the new downloads are in place.
Keeping the JVM (and CF) updated is like flossing. It may be annoying, but you have to do it or you may eventually suffer consequences. As always, I just want to help.
For more content like this from Charlie Arehart:
Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed