Working on a Windows server with Apache 2.4 -
Installed 2018 with update 10 about three weeks ago on our test server. After working through getting all the new security to work, it has now stopped after about a week and a half running smooth. Get the 403 error.
The only error I see is
[Wed Sep 30 19:42:57 2020] [1568:1836] [warn] ajp_process_callback::jk_ajp_common.c (2218): (cfusion) AJP13 protocol: Reuse is set to false
in the mod_jk log.
It was running without the secret in the workers.properties file (it was in server.xml while working), but I tried adding it, no difference. I added the suggested line allowedRequestAttributesPattern=".*" to server.xml, which I did not have before. No difference. If anyone has any other ideas, I would welcome them. I am no sys admin 🙂
I would advise you to first look for a solution not involving allowedRequestAttributesPattern. Use this attribute only as a last resort. It carries a risk, as it could allow illegal attributes in the Tomcat request.
You could really begin by just setting the secret. For example:
in server.xml of the instance
<Connector port="8018" redirectPort="8451" protocol="AJP/1.3" connectionTimeout="60000" address="127.0.0.1" tomcatAuthentication="false" secret="ED4412AC-B055-41C6-8247-CBCAE6230964" packetSize="65535" maxThreads="500"/>
I have the secret set both places. I should have said that. Sadly, still getting a 403 😞
Did you upgrade the connector?
See https://helpx.adobe.com/coldfusion/kb/coldfusion-2018-update-8.html (scroll down to "Troubleshooting" section).
2 alternative ways to upgrade the connector:
1) Launch the tool C:\ColdFusion2018\cfusion\runtime\bin\wsconfig.exe, select the connector and press on the Upgrade button.
2) Using cd in MS DOS, navigate to C:\ColdFusion2018\cfusion\runtime\bin. Then run the DOS command
Doing so will upgrade all the connectors.
I think I have - I get this
Sorry I am so slow to respond I am at a tiny place with all hats!
I don't recognize that warning, but I gather you mean you get it when you run the wsconfig upgrade? And is that from the command line or gui? (I'm thinking the latter, given the screenshot shared.) Did you run that "as admin", since you indicate being on Windows?
Also, I have seen things get a little out of whack with Apache setups, especially when people may have in the past manually configured things in the apache conf files (when something previously didn't work, and they did some googling to try to "solve that").
Do make sure that whatever files ARE updated by the wsconfig tool are indeed the one that your Apache conf files are pointing to...and of course make sure you are looking at the Apache conf files that Apache really is using. Since there may be includes of includes, and folder from which Apache may be pulling in conf files, you may start to feel lost in ensuring you have things right.
I have seen situations where the files modified by the wsconfig were in a folder related to CF, while the apache conf files were pointing to and expecting those to live in an Apache folder. And if the wsconfig updates only those IT knows about, but not those that Apache is loading, that's when you get these ongoing errors despite "fixing" things.
When you're in a real bind, it may even help to introduce errors intentionally (to make sure things are doing what you think), like renaming the conf file you think Apache is using, to see if it complains (to confirm that) on an Apache restart. Same with the .so file and .properties files that are used for the CF web server config.
Let us know how things go. Or you can reach out to folks for direct consulting help, like I offer a list of such folks (including myself) at cf411.com/cftrouble.
The warning is probably ColdFusion's way of giving you a hint. The assumption is that you wish to configure Apache manually. You can get the Apache connector file as follows:
Unpack the JAR file C:\ColdFusion2018\cfusion\runtime\lib\wsconfig.jar. Let's say the result is the directory wsconfig. Then the Apache 2.4 connector file is:
Choose the one that corresponds to your Apache's bitness. Copy the file to
Then follow the remaining steps on how to manually configure the Apache connector in ColdFusion.
I can't tell, BKBK, if you are saying that in response to my previous comment. To be clear, I would not presume that was necessarily the solution, though it may be. As I said in my comment, one may find that their Apache configuration doesn't match what that Adobe technote proposes (and so they need to be careful following that, just like using the wsconfig tool itself).
Let's see what cassadinechik may have to add or confirm either way.
Thanks for the help. I was able to unpack it and move in the new .so file and restart Apache. Still get a 403.
I did at least use some of the tips, like renaming to see if everything was pointing the right way, which would bring down Apache entirely, so at least I know all the directions seem to be correct.
Is it possible to just roll back the security update and get it working again? I am leaning towards giving that a go as we need the environment back for some projects.
Thanks for the update. As for things still not working, that is just so very strange. I have one more suggestion before you uninstall the update.
But since you have asked that, first, yes can you uninstall a CF update. Just go into the CF Admin, to the updates page, to "installed updates", and click the uninstall button, and it will revert to whatever you had before. (There is also an uninstall.jar you could run from the command line if the UI somehow did not work, or the update uninstall failed.)
But note that that will NOT uninstall the update of the connector as you have implemented it. CF doesn't provide for that (there's not even an uninstall feature for the wsconfig tool). Instead, you would need to re-run the wsconfig tool (after the CF update), which would then put the old connector .so file back in place. I don't think it would remove the "secret" lines from either the workers.properties or server.xml, so this is a dicey proposition to do everything carefully. Just an unfortunate aspect of this "ghostcat" fix that Adobe has implemented.
Before you do, let's get back to that, and what I would propose instead first. I know you said originally that you had tried the allowedRequestAttributesPattern attribute, and it "didn't work". And BKBK warned why he'd prefer you avoid it. But as Adobe (and even the Tomcat folks) indicate, that IS needed if somehow your web server DOES send headers that the AJP connector is NOT expecting. And that attribute simply tells the AJP connector to allow in any header.
Is that worth worrying about? I would argue no: nearly anyone would have a firewall in place such that any non-standard port is NOT open to the world, and the AJP port (such as 8018) is such a non-standard port. So really, the whole ghostcat tomcat vuln hysteria was overblown in my opinion.
Anyway, I know you said you tried that attribute, and it didn't work, but that's seemingly the last thing that would be causing the 403. Can you try it again? And to be clear, you did RESTART CF after making that change, right? It's not clear from your first comment, so worth checking.
And then there's always the chance that you have more than one server.xml (for having more than one CF instance). If you want to try another "sanity check", when you make the change first backup the file, then try removing the ajp connector line entirely, and then restart CF and Apache. Do you still get a 403, or some new error? You could even try renaming the server.xml file and restarting CF. If it comes up, then that CF instance is NOT using that server.xml. 🙂
Just some things to try. Because really, even if the ghostcat issue was overblown, you do NOT want to be in a place where you are opting to NOT install CF and connector updates. That will leave you in a bad place, for a number of reasons. But I realize you're desperate to get rid of the 403 errors.
I will just say again that someone facing your problems doesn't have to do it alone, or rely solely on back-and-forth over days on the forum here. You can get direct remote assistance from someone like myself, or others at cf411.com/cftrouble. As always, just trying to help.