[Looking for Charlie's main web site?]

New updates released for Java 8 and 11, April 20 2021

Note: This blog post is from 2021. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.
For those using the Long-term Support (LTS) versions of Oracle Java, 8 and 11, please note `there were new updates released last week (Apr 20), specifically Java 11.0.11 and 8.0_291. For some, that's all they need to hear. They will take that ball and run with it.

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:

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \

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.

For those, see blog posts I have done in regarding past Java updates where I did address those various issues, most recently here on my blog in 2020 and also in the Adobe CF portal, in 2019.

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?
  • 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
Effective Mid-July, 2021, we (Adobe) recommend that our users shift to distributions of the Azul Zulu builds of OpenJDK (https://www.azul.com...) for developing and deploying CFML applications.

The Azul OpenJDK builds are compliant with Oracle Java SE (Standard Edition).

All ColdFusion customers are entitled to use Oracle Java till December 2022.

The usage rights for Oracle Java technology as distributed by Adobe will expire in December 2022.

Pre-release builds are available at https://www.adobepre... for CF2018 and CF2021.
Peter, thanks for sharing. (And I believe you are quoting Adobe, rather than indicating that you now work for them, right?) As for that news, thanks for sharing it.

Adobe had also blogged it on the 15th (https://coldfusion.a...), and I've been commenting there (and learning from comments of others) since. I've been planning a blog post of my own and will post it soon, I hope.

I'd not considered mentioning the Azul change in this post on the Apr Java update, but now you have and so all this stands for interested folks to pursue.
I'm just now seeing this post. We were bitten by the TLS restrictions of Java 11 just this weekend! Our host updated our JVM, unbeknownst to us, and all of a sudden our CF server could not send email. Everything got dumped into CF's Undeliverable folder.

We hadn't been aware of this change and have no control over the remote mail hosts so our email was dead in the water until our host was able to fix.
# Posted By Paul Mascari | 12/22/21 8:49 AM
If you're saying the fix I note here helped, that's great. If instead you mean that you found this only after you solved things, and perhaps are lamenting if it's the only news on this you could find, well, I do what I can but I can't solve quite ALL the cf world's problems. :-)
Yep, I'm just lamenting that I found this after having pulled most of my hair out. I've passed this along to my hosting company for reference as I'm sure they're completely unaware of this as well.

As always, I am very grateful for the efforts and time you put into the ColdFusion community, Charlie.
# Posted By Paul Mascari | 12/22/21 9:12 AM
And thank you, for the kind regards. Positive feedback helps motivate continued performance, to twist the old financial advice adage.
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting