CF911: Have you updated your ColdFusion JVM to _24 yet? Important security fix for CF 8/9
Note: This blog post is from 2011. 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.This isn't new info, but you may have missed it. If you're running CF 8 or 9, did you know you can and should update the JVM that came with it? And that you have Adobe's blessing to do this update? This is because of a serious bug in the JVM that is not fixed until 1.6.0_24.
Both CF 9.0 and 9.01 run on older JVMs (and therefore need this update). And are you on CF8? You're not left out: Adobe even has confirmed this update can be applied to CF 8 and 8.01, too!
Note: if you are finding this blog post because you're searching the web for help on updating the JVM that underlies ColdFusion, note that this is a very old post (2011) about one specific JVM version. Instead, for a more general discussion of updating the JVM, and especially about solving and preventing common problems when doing that, see my more "recent" (2014) and more elaborated post: CF911: 'Help! I've updated the JVM which ColdFusion uses, and now it won't start!'.Still more updates since this originally was posted:
Update 1: Since I wrote this blog entry in Oct 2011, Adobe has since come out with a new technote in Oct 2012 saying that you are now permitted to update to any version of Java 1.6 (for CF 8/9/10).
Update 2: Since posting this note, I've realized I should document an important fact to be aware of if you DO update the JVM: after doing so, it may seem that changes you made to allow CFHTTP calls to SSL pages (or other tags in CFML that talk via SSL or TLS) may "seem to have been lost". The issue is likely that you had modified your current CF setup to import specific certificates for such sites, but those changes are "lost" when you change the JVM that CF is now using (which has its own keystore). But these cert changes can be recovered. For more on that, see the next to last section below.
Update 3: In Feb 2013, Adobe did come out with an update that authorizes moving to Java 1.7 in either 9 or 10. You must apply the update first, though. More in this Adobe blog entry.
Old news, but not everyone knows
Someone mentioned today on a list that they'd seen news from Oracle of this important bug (and fix) for the JVM, which can cause someone to crash the JVM using a particular URL string. He also noted that while Oracle had released the fix some months ago, he lamented that "This issue doesn't seem to have gotten too much interest from Adobe."
I explained that in fact Adobe had addressed it, also some months ago.
Adobe's response
Adobe offered a technote on the issue in March 2011.
In fact, they not only confirmed support for (and recommended updating to) the fixed JVM version, 1.6.0_24, but they even (for the first time in years) approved updating to this JVM version for CF 8 and 8.01. Since those ran on very old JVM releases, which had problems not fixed until JVM update 10, this was really good news.
But as his note conveys, word just had not gotten out as much as it could. Beside his thread on that list, I hope now that this blog entry will help reach more people.
More about the bug
If you want to know more about the bug from a CF perspective, check out this blog entry (from several months ago by David Stockton, of cfconsultant.com). He explains the problem/risk as well as shows how to cause the problem (to confirm when it's fixed), as well as some useful extra info on using FusionReactor to help diagnose it.
How to update the JVM for CF
So if you're now persuaded, you may wonder how you go about updating the JVM. You may fear it's like doing open-heart surgery. It's more like getting a mole removed. :-) It could go wrong, but will barely be noticeable if done right.
There are many blog entries that walk through the few simple steps. Find out more from Ryan Stille, Mark Kruger, and Adobe, to name just a few.
While it's not too hard to do, there are just a couple of potential gotchas: be sure to get the JDK not the JRE, and pay attention to the special path format that's needed when pointing to the JVM on Windows.
So if you're on CF and have not yet updated the JVM, seriously consider it.
Any potential compatibility problems with updating the JVM?
Since Adobe has given this update its blessing, we can assume that there should be no code compatibility issues.
Of course, whenever you change the JVM you are changing the heart of the CFML engine, and there may well be changes between the version you're running and the version you upgrade to. Besides reading any technotes from Oracle/Sun, you should also keep an ear out in the community for any issues that people spot.
Dealing with certificate issues when changing the JVM CF uses
Indeed, since originally posting this entry, I realized that one potential issue is not so much due to any "change in behavior between JVM versions" but rather due simply to the fact that by changing what JVM CF is using, you're also inherently changing where it looks for certain information--which you may have updated yourself.
In brief, if you previously updated the java keystore (within CF) to enable you to do CFHTTP or similar tags to call an SSL page (whose certificate CF/the JVM did not recognize), you will find after changing the JVM that these calls now "break" again, as if your certification changes were "lost".
What it is is that you (or someone at your site) had previously done steps to import such needed new certificate into CF's keystore, but now on changing the JVM that CF uses, that will cause CF to instead use that new JVM's keystore. There are a couple of different solutions to this (import them again, export them from the old store and import again, point the new jvm at the old keystore, etc.), which I'll elaborate in the other blog entry (I did this in the 2014 entry I referred to in my "note" at the top here, especially its section, "Another gotcha: SSL certificates".)
What about updates beyond u24?
This is an update since I posted the entry above. As you'll see in the comments below, some folks were kind enough to write in and point out that there have been JVM updates since u24.I did realize that, and do appreciate their wanting to share the info. I'd not mentioned updates beyond 24 simply because I would not propose (myself) that anyone now update beyond the release for which Adobe has certified CF. (At least not until compelling reasons arise and substantial community testing suggests it may be safe, as happened with CF8 and the u10 update. Even then, you are risking being out of bounds for support by Adobe, so should make such a change with caution.)
The whole point of this entry was that u24 HAD in fact received Adobe's blessing, for CF 8 and 9, which was pretty compelling and seemed to have been missed by some when it happened earlier in the year.
Finally, since I wrote this note, again Adobe has now given their blessing to any update of JVM 1.6 for CF 8/9/10. More at this technote.
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
One other thing I'll mention (shameless plug) is that the paid version of http://HackMyCF.com can notify you if your server JVM needs to be updated, among other things.
So while one can certainly take their chances on a later update, you're doing just that: taking a chance. As you've discussed, some may find that it works, others that something does not. Adobe is only saying (at least for now) that u24 is supported: nothing more.
I won't speculate myself on whether later ones can work. Others can, but I appreciate that there can be many variables that influence what may or may not work. So those wanting to play it safe should stick to u24 until told otherwise by Adobe, or perhaps as persuaded by substantial evidence from community experience. :-)
You do go on to mention Java 7, and sure, as I commented to others above, sure, I do realize there are later updates to 6, and yes, I realize 7 is out now.
As I said to them, I would not propose (myself) that anyone now update to Java 7. I see no compelling need to (and many who consider it seem often to be doing so to solve problems, which from my experience may be solved in other ways.) More than that, Adobe has not yet certified CF for any update beyond u24, and that was the real point of my entry here.
Anyway, in case anyone may find it hard to locate the older updates on the Oracle site, here is a link (which works, at least, for now):
http://www.oracle.co...
And just to save others the time from wanting to write in (though I appreciate the suggestions) I will update the entry to make clear my stance on later JVM updates beyond 24.
Other than this testing, I haven't upgraded any other servers up to 1.6.0_26... but I also haven't had any issues with it (even if it's unapproved/untested.)
I was just curious as to what your personal experience was with upgrading CF8/9 beyond what Adobe has tested. Do you know of anyone else who has done this? I'm not looking for an official Adobe-answer as much as real-world experience.
Do you have any idea what version Zeus will be using? (Or is that a FAQTCYBA?)
As for the image issue, if you ever find where you saw that documented, feel free to leave a link here for any who may be interested. Thanks.
http://www.oracle.co...
There, it indicates that the fixes are different between them, and it even offers a table at the bottom to help clarify which things apply to which JVM.
And the broader "Oracle Critical Patch Update Advisory - October 2011" (http://www.oracle.co..., applying to all products, not just JVMs) says specifically:
"Starting with the October 2011 Critical Patch Update, security vulnerability fixes for Oracle JRockit will be announced with the Oracle Java SE Critical Patch Updates. Java SE Critical Patch Updates are released on a different schedule but coincides with October's Oracle Critical Patch Update."
So good timing on your question. Seems we have that answer now.
First, to be clear, you could easily revert back to the old JVM if you wanted to. All the resources that showed how to change it made it clear that it was just a single line change in the jvm.config, where you pointed to the new jvm location in the java.home. If you saved the previous value as a comment, you can revert it. If not, the resources can help you sort out what the default should be for your deployment.
Second, and perhaps better, you can easily change this prompting behavior. More on that in a moment.
So yes when you install a JVM manually, you will indeed now get the prompts from the Java installation that's by default always checking to see if you've updated to the latest and greatest. They figure you'd always want that. But you're right that in our case, with a tool relying on it (but not yet certified for later updates), we may not want to.
So here's the simple fix (on Windows, any edition): go into the Control Panel, select Java. In the window that opens, choose the "update" tab, and deselect "check for updates automatically".
You could also choose the "advanced" button next to it, and change from the "weekly" to "monthly" prompts.
Of course, it's an interesting challenge that this leaves: if we don't get updated of new JVM updates, might we miss something critical? Yes, but if this is a machine which is used primarily for CF, then you're at least better off for having updated to u24, and stopped there, than to have done none of this and still be at the original jvm version that CF came with.
You could then keep your ear out (from Adobe, via their security update announcements) for if and when CF is certified for any later (truly critical) update. We can't expect Adobe to certify CF for every JVM update. It's just too much work to test, when you consider the exponential number of combinations of OSs and their versions, DB drivers and their versions, web servers and their versions, and so on.
Does that help? I certainly wasn't trying to "steer you wrong", in promoting here the JVM update that Adobe recommended. It was critical and needed.
But you raised a good question about how to deal with the update nags, and I hope this explanation helps you and others. Let me know what you think.
Your right, it is a CF server exclusively, so I'll trust that my RSS feeds to your blog and Pete Freitag's blog (and Ray and Ben and Ben and all the others) will keep me up to date on any critical issues from Adobe.
I was offering it respond to your last sentence: "I liked it better when it just ran in the background with CF." I wanted to make sure you (or other readers) understood that you could always go back. I was reading it like you felt like you'd now gone down a road where you couldn't go back.
But yes, as for keeping an ear out for updates, besides our feeds, there's an even better service that focuses solely on notifying you of such critical updates. John Mason maintains several "CF Updates and Patches RSS feeds" (http://www.codfusion...).
I list it among various tools to help with hotfix management in CF, as a relatively new category on my CF411 site: http://www.cf411.com...
Hope that helps. (And thanks for asking about the above, I think it's a useful addition to the blog entry.)
http://www.coldfusio...
which suggests that a new JVM arg is needed to get past a problem fixed by Java update 1.6.0.19:
-Dsun.security.ssl.allowUnsafeRenegotiation=true
This opens back up a hole that u19 was fixing, but until there's some better resolution to the problem, I wanted to pass it along. If I learn any more, I'll add a new comment here.
https://blogs.oracle...
Know that you can't really do anything regarding it, but just documenting it if anyone wants to get to the information.
One of our clients called today to say that parts of their web site had stopped working. We re-added the certificate to the keystore which got them up and running again, but we were confused as to why it ceased to work in the first place.
Not sure how long the web site wasn't working for, but at least we now know why.
I have tried using the 1.6 import but still getting an error:
keytool -import -storepass changeit -noprompt -alias newcertificate -keystore C:\Coldfusion9\runtime\jre\lib\security\cacerts -trustcacerts -file c:\temp\TestCert.cer
Thanks
Mike
For instance, you may be getting an error simply because you are running the keytool command from somewhere other than the jre\bin dir within yur 1.7 jdk install (or have not set that location into the system path).
But I'll assume that's not what you mean.
Then a problem could be that the testcer file is not in the location you name, but again I'll assume you'd not mean you've made that mistake.
So what is the exact error? I can confirm that if I point to a valid cert and run that command on my own system running 1.7, it works.
Thank you for the quick response.
Te error I get when trying to cfhttp to the site is:
I/O Exception: peer not authenticated
I verified that the certificate has been added to the keystore.
I'm on CF 9.02 with the latest patches applied.
I just wanted to make sure that he command didn't change from 1.6 to 1.7, the same way as did when moving from 1.4 to 1.6, but i guess if it did then I would have gotten an error when running the command, but I got Certificate was added to keystore.
so I guess something else is at play ...
This is an internal site to test some new functionality
Thanks
Mike
I used to connect to the server before
You can also look at a couple of resources that offer still other possibilities:
http://www.raymondca...
http://stackoverflow...
Hope that's helpful. I also offer consulting services to help with such problems (www.carehart.org/consulting), but as you can see I do also happily answer questions here, as well as on lists, forums, other blogs.
You were very helpful like usual.
Good to know about the consulting option.
I will let you know how things evolve.
Thank you
Mike
I have re-imported it and now it works fine.
Thank you, thank you...
Mike
Thanks also for the kind regards in the earlier comment.
http://www.oracle.co...
It has up to 45 already. It is better to use this or 1.7?
As to whether you should be getting 1.6 (Java 6) or 1.7 (JAva 7), that depends on whether you have applied cumulative hotfix 4 for CF9. If so, you can and should go to Java 7. If not, Java 7 would not be supported for you.
BTW, Adobe created a nice blog entry just yesterday which explains what versions of CF support what updated versions of Java. See http://blogs.coldfus...
You can find more on the CHF3 (for 9.0) at http://helpx.adobe.c... THAT's what added Java 7 support for CF 9.0. (FWIW, the URL for the technote on the security hotfix containing hf900-00003.jar is http://helpx.adobe.c...)
Finally, if you are looking at the CF Admin to see what hotfixes are applied, that may mislead you. For more, see http://www.carehart....
HTH
http://adiabata.com/...
Even though you can configure Java 1.8 to specifically use TLS, the java-specific options aren't available to CF and there's no work-around.
In fact, John got back to me directly and had me help in a consulting engagement (I definitely didn't hold out replying to get that!)
The great news is that we did solve things for him, and while one aspect worked with Java 1.7 (he had been on 1.6), another turned out to only work with Java 1.8. And no, CF9 doesn't formally support that, but then Adobe no longer supports CF9 anyway, so it's rather moot. :-)
FWIW, once we updated his CF9 to use 1.7, one cfhttp hiccup (calling to SSL) did work, and we thought we were good to go, but then there was still more fiddling needed to get to a subsequent important step in his Salesforce integration to work.
Once we got to that going, then a subsequent CFHTTP ssl call failed. That was odd, as both were to the same server. But we punted at that point and just tried 1.8. To stretch the analogy, it was returned for a touchdown! :-) Now all his integration worked, and he was free to proceed to the last fine-tuning he needed, and all has been well since.
BTW, for what it's worth, he had been using cfx_http5 before the call, but it was not working and as part of our work to get things going, we just changed it to plain ol' cfhttp, which again ultimately worked with the move to 1.8. Perhaps the cfx would have worked also better with Java 8, but I don't think he went back to it.
CFX_HTTP5 is 100% C/C++ (0% Java; 0% COM; 0% MFC). (DISCLAIMER: TLS 1.1 & TLS 1.2 are not supported by Win Server 2003, so it's also not available.) It's built on WinHttp 5.1 API and supports all security and authentication protocols, regardless of whether ColdFusion and/or Java supports them or not.
Here are some recent connectivity scenarios that we've solved using it.
We've to add the CFX_HTTP5 parameter SSLERRORS="OK" to connect with misconfigured or expired SSL certificates. (Seriously... an API provider accidentally let their SSL certificate expire.)
PayPal has a TLS1.2 domain https://tlstest.payp... and it requires TLS-only connections. We used SSL="5" to explicitly use the TLS1.2 protocol. (I don't think that ColdFusion 2016 can do this.)
NOTE: 0 - SSL3 and TLS1; 1 - SSL2; 2 - SSL3; 3 - TLS1; 4 - TLS1.1; 5 - TLS1.2;
The OpenWeatherMap API uses AWS and would occasionally switch IP addresses. ColdFusion permanently caches the DNS and then stops working whenever the IP changes. CFX_HTTP5 honors DNS TTL and we haven't encountered any downtime since switching.
So first, you refer to your having "reset up our ColdFusion websites on another server". Are you saying that you did or did not (on that new server) change the JVM that CF uses, by pointing it to a new jvm, which is the subject of this post? If you did not, then your question is not related to this post. We just both need to be clear on this point first.
Second, you say "after updates the SSL certificate is not working on the ColdFusion pages". Can you clarify what you mean first by "after updates"? What "updates" did you do? Or do you just mean "after the move to the new server"? This is important to clarify.
And as important, when you say "the SSL certificate is not working on the ColdFusion pages", what do you mean exactly? Do you mean that a cfhttp calling an https page is not working? Or some other CFML code calling an https page (like any of the tags or functions that can call out to other sites, like some xml and image functions/tags)?
Because if you might mean that calls INTO your server to SHOW CF pages are failing, not with CF errors but with errors from your web server, then you may be referring to SSL certificate management in your web server (IIS or Apache), and this post is not at all about that.
Now, assuming this IS about calls to https urls from within CF code, and you DID change the JVM that CF is pointing to on the new machine, then let's clarify still other things.
Are you saying that things worked (on the new machine) BEFORE changing CF to point to a new JVM? If you can't say, then we can't know that changing the JVM was the factor in your new problem.
Finally, if things WERE working before and now are not after the change, and this IS about calls to https urls from within CFML, did you see the discussion in my post above about how you need to be sure that you added any needed certificates to the keystore of the NEW jvm location? Do a find on "keystore" to find the references in the blog post here.
Perhaps some of my questions here will help you to see answers on your own, but if you have more, let me hear them. :-)