[Looking for Charlie's main web site?]

CF911: Have you updated your ColdFusion JVM to _24 yet? Important security fix for CF 8/9

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.

Hey Charlie, thanks for posting this - I also find that alot of people don't know about this, though I try to mention it as much as I can. I also posted a blog entry on the issue in Feb: http://www.petefreit...

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.
# Posted By Pete Freitag | 10/28/11 12:17 PM
Great stuff .Thanks for adding it, Pete! :-)
# Posted By Charlie Arehart | 10/28/11 12:24 PM
JVM 1.6.0_26 has been out for a while too, but apparently hasn't received Adobe's blessing. Any idea if there are any issues regarding us it with CF8 or CF9? (I've been running it with CF9 for a couple of months and haven't encountered any noticeable issues.)
# Posted By James Moberg | 10/28/11 4:30 PM
I've been running on _27 for many months without any issues. I think _26 would be safe as well.
# Posted By Dave Cordes | 10/29/11 12:35 AM
Hi guys. I should have mentioned that indeed there are still later updates beyond he one referred to here. But to be clear, Adobe has only certified CF for update 24.

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. :-)
# Posted By charlie arehart | 10/29/11 5:59 AM
I suspect there might be another gotcha - see JDK versa JRE. The Oracle link to JDK (http://www.oracle.co...) offers Java 7 and 6 versions. People could download 7 and install that where as they might be better served to stick with 6 since the official Adobe support for Java 6 namely 1.6.0_24 and Java 7 "newness".
# Posted By Carl | 10/30/11 8:19 PM
Not quite sure what you mean, Carl. You refer to a gotcha being "JDK versa (sic) JRE", but I had already warned of that as a gotcha: "be sure to get the JDK not the JRE".

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):


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.
# Posted By Charlie Arehart | 10/31/11 10:53 AM
CF9 was has severe performance issues when processing large JPG photos using CFImage. Regardless of settings, the CPU would spike up to 100% and impact other processes/users/threads. I forget who's blog I read it on, but the recommendations was to upgrade to JVM 1.6.0_26. This improved the situation, but not by much. I finally gave up on CFImage and switched to CFX_OpenImage (32bit, C++). I found it to be 75-90% faster & created images that are about 64-72% smaller than CFImage. Getting the image dimensions was also about 96% faster. (No more time-outs!)

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?)
# Posted By James Moberg | 10/31/11 11:28 AM
James, I'm afraid the answers are simply no and no. :-) Perhaps others will share in time, but for now I cannot.

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.
# Posted By Charlie Arehart | 10/31/11 11:35 AM
I've looked and haven't been able to find it. I don't know if it's been impacted by recent Google algorithm changes or if the resource is simply no longer available. I'm getting into the practice of copying articles and pasting them into Evernote so that I don't have to go looking for them again, but I may not have done that with this article.
# Posted By James Moberg | 10/31/11 5:14 PM
Does anyone know... When a security issue is raised in the SUN jdk does this problem also exist in the Jrocket release of the same revision?
# Posted By Alex | 11/8/11 10:49 AM
Alex, that's indeed an interesting question, now that Oracle owns both. I did some digging and found this clarification in the latest "Oracle Java SE Critical Patch Update Advisory - October 2011":


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.
# Posted By Charlie Arehart | 11/8/11 11:14 AM
Since I updated I've been getting constant reminders from the Java updater that I should update again. Annoying since there is no guarantee that the latest version will even work with CF9. I liked it better when it just ran in the background with CF. :-p
# Posted By doug | 11/9/11 9:29 AM
Things aren't quite as desperate as they may seem, Doug. :-)

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.
# Posted By Charlie Arehart | 11/9/11 10:09 AM
Yep, that does help. I hadn't thought about just commenting it out, though admittedly even if I update in that way, I'm still risking my production server crashing and burning due to some incompatibility when I'm not around to revert the change (did I mention I'm a one-man shop? lol).

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.
# Posted By Doug | 11/9/11 10:50 AM
Oh, to be clear, my suggestion about reverting to the original was not so much under the guise of "so it's ok to let the JVM updates happen". No, I think it's unwise to update it again until Adobe ok's it (or many affirm it), a point I stressed in the entry above.

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.)
# Posted By Charlie Arehart | 11/9/11 3:29 PM
Just a note for any who may do this JVM update. While it is supported and even recommended by Adobe, I've had one client who reported a problem with CFHTTP calls to SSL pages. I did some digging and found this from the inimitable Mark Kruger:


which suggests that a new JVM arg is needed to get past a problem fixed by Java update


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.
# Posted By Charlie Arehart | 1/25/12 4:38 PM
The Oracle link in Adobe's technote goes to a 404 page. It really should be updated to the permanent link to the entry


Know that you can't really do anything regarding it, but just documenting it if anyone wants to get to the information.
# Posted By David Epler | 4/17/12 9:21 AM
Thanks for sharing that, David. Yes, bummer, and all the more that there's no way for us to add comments to those Adobe technotes. I have at least used the "was this helpful" option there to say "no" and point out the correct link. Don't know who watches that. I will drop a note to some other Adobeans who may be able to help. Thanks for the heads-up.
# Posted By Charlie Arehart | 4/17/12 12:56 PM
I did the exact same thing.. Hit "No" and put in the correct link. Just felt like it was going into a black hole. Thanks for passing it up, hopefully it will be updated with the correct link.
# Posted By David Epler | 4/17/12 1:17 PM
Does anyone know if CF8 works with JRE 1.6.0_35 ? What is the latest version supported today for CF8?
# Posted By Jim Ruzicka | 9/14/12 2:00 PM
@Jim - Core Support for CF8 ended on 7/31/2012 so unless you have an extended support contract wether or not it is supported becomes moot. The latest version "certified" for CF8/9 was 1.6.0_24 - in general running a later version does not cause issue and may even fix some. There have been some cases where it did cause issue but even then typically minor and restricted to a specific use case.
# Posted By Pete Freitag | 9/14/12 2:35 PM
Thanks for the tip regarding the JVM and keystore Charlie.
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.
# Posted By Glenn Seymon | 7/7/13 9:54 PM
@Glenn, great to hear. Yep, it's one of those easily missed things when one updates the JVM. I don't think I've seen anyone else mention why we must pay attention to that on changing CF to use a new JVM. Glad you were able to find this, and thanks for the feedback.
# Posted By Charlie Arehart | 7/8/13 9:56 AM
Is there an example of how to import when using java 1.7.0_25

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

# Posted By Mike | 8/21/13 10:44 AM
@Mike, what is the error? Help a brother help another brother. :-)

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.
# Posted By Charlie Arehart | 8/21/13 12:01 PM
Hi Charlie,

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


I used to connect to the server before
# Posted By Mike | 8/21/13 2:59 PM
@Mike, Oh, ok. Well, in that case, first be sure to consider the issues I mentioned above, about making sure you were updating the "right" cacerts in the location of the JVM, not CF's location.

You can also look at a couple of resources that offer still other possibilities:



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.
# Posted By Charlie Arehart | 8/21/13 3:51 PM

You were very helpful like usual.

Good to know about the consulting option.

I will let you know how things evolve.

Thank you
# Posted By Mike | 8/22/13 8:50 AM
Charlie your comment about:...about making sure you were updating the "right" cacerts in the location of the JVM, not CF's location was the solution.

I have re-imported it and now it works fine.

Thank you, thank you...

# Posted By Mike | 8/22/13 10:24 AM
@Mike, very good to hear that that solved things. Sometimes things are just not what they seem on the surface, so I love helping people look beyond the obvious or what Google might tell them. ;-)

Thanks also for the kind regards in the earlier comment.
# Posted By Charlie Arehart | 8/22/13 8:55 PM
Is this the right place to download the Java 1.6.0_x for CF9?


It has up to 45 already. It is better to use this or 1.7?
# Posted By Jack | 11/20/14 11:38 AM
@Jack, that would be the right place to get the latest JVM 1.6 (update 45), though again be sure to get a JDK not a JRE.

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...
# Posted By charlie arehart | 11/20/14 1:51 PM
My CF Admin shows version 9,0,0,251028 I am assuming I am CF9.0? I have applied Hotfix 3 so should be safe to use 1.7?
# Posted By Jack | 11/20/14 2:23 PM
@Jack, you can--but only if you really mean *Cumulative Hotfix 3*. If you see a hf900-00003.jar, that is a security hotfix 3, not the needed CHF, which would be chf9000003.jar.

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....

# Posted By charlie arehart | 11/20/14 6:52 PM
Hello Charlie, I'm coming at this from a TLS requirement perspective, and I'm hoping you can provided a little guidance. I've been getting this TLS error when attempting to connect to Salesforce: "TLS 1.0 has been disabled in this organization. Please use TLS 1.1 or higher when connecting to Salesforce using https". I'm running CF server 9.0 (no hotfix applied -- yet), so I know I definitely need to upgrade, but my question is, which upgrade? From what I've seen online, I could possibly upgrade 9 which would enable Java 1.7. But I don't believe Java 1.7 will give give me TLS 1.1 or higher, which means (I think, anyway) that I would need to download Java 1.8 to enable those protocols to work. And I'm not sure if Java 1.8 will really work on CF 9! So here's my real ask: Is it worth my time patching CF 9 and installing Java 1.8 in the hopes that it "could" work; or am I better off biting the bullet and upgrading from CF 9 to CF 10 or 11 (or whatever you'd recommend, if this is the scenario you would push). Thanks Charlie! Appreciate your insight.
# Posted By John K | 9/1/16 11:31 AM
Are you using IIS? If so, you could use CFX_HTTP5. We've been using it and it has enabled us to override & perform TLS-specific requests (AND ignore non-Java SSL wildcard certificate errors caused by CF9+.)

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.
# Posted By James Moberg | 9/1/16 12:09 PM
James and John, so sorry for the delay in responding to you guys since 8 days ago. Just really busy.

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.
# Posted By Charlie Arehart | 9/9/16 4:40 PM
That's good to know. We encountered some SSL SAN Wildcard issues w/CF10 JVM1.8 around the time that CF2016 was being released. There wasn't any feedback regarding when (or if) either would be fixed. I wasn't willing to upgrade and hope that it may be fixed.

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.
# Posted By James Moberg | 9/9/16 6:20 PM
Fair enough, James. I wasn't disparaging the cfx. I was just saying it wasn't the needed solution for John, and indeed had not worked initially. Great to hear of all the ways it's helped you.
# Posted By Charlie Arehart | 9/9/16 11:23 PM
We recently had to reset up our ColdFusion websites on another server. Everything went fine, however, after updates the SSL certificate is not working on the ColdFusion pages. Any advise?
# Posted By Julianne McCoy | 3/14/17 10:16 AM
Julianne, before I can help, I need to get some clarifications from you. :-)

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. :-)
# Posted By Charlie Arehart | 3/14/17 11:29 AM
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