March 24, 2020
Three reasons your sites may break, and how to fix them, after applying March 2020 update to CF2018 or 2016
Comments
(5)
March 24, 2020
Three reasons your sites may break, and how to fix them, after applying March 2020 update to CF2018 or 2016
ColdFusion troubleshooter
Guide 146 posts
Followers: 119 people
(5)

If your site/s are served to ColdFusion via IIS or Apache, note that those sites will fail immediately after applying the March 2020 CF updates, update 8 for CF2018 and update 14 for CF2016. But there’s an easy fix.

It’s not a bug, and CF is not broken. Instead, it’s that Adobe has implemented a Tomcat-related security improvement, and as a result you need to take at least a second step right after the update, and you may need to take another step or two depending on your configuration.

The least you need to know

I’ve detailed things with much more explanation in a blog post on my own site, but I want to present the info here in the most brief form I can.

  1. After the update, you must run the CF web server configuration tool (wsconfig), to upgrade the connector(s) for your IIS/Apache site(s). Doing this will cause CF to implement a new “secret” in the workers.properties config file of your web server connector(s), to match the one the CF update will have created and placed into the AJP connector of CF’s server.xml file.Note that you don’t need to remove and re-add the connector: you need only use the “upgrade” feature available in the wsconfig tool, either as a button in the UI or as a -upgrade option at the command line, as you may prefer.  For more on upgrading your web connector, see another post I’d done in the recent past.
  2. Also, there are a few scenarios where you may need to implement a required IP “address” attribute, also to be set for the AJP connector in CF’s server.xml file. This need is caused by the updated Tomcat AJP connector, which now defaults to accepting requests only from the localhost/loopback addresses, 127.0.0.1 (as a security measure). If somehow connections into CF from your web server make the connection with some other address, you will need to tell the connector that IP address.So first, if your IIS or Apache web server is literally on a different machine than CF (an uncommon configuration), you will need to put in the address which those other machines/web servers will use to talk to CF.Second, even if you have CF and the web server on the same machine, there are situations where you will need to set this “Address” attribute. One is if for some reason you have modified your hosts file so that localhost resolves to an IP address other than the traditional loopback address you will  need to indicate that ip address with this “address” field.Another is that I have seen many situations where this has hit folks using Apache (on the same machine as CF), who found that they too needed to implement the “address” field with a value of “::1” (the ipv6 address), even though a ping of localhost on their machine did not return that (and even though that’s the host name listed in the workers.properties file of their CF connector). Just try it, if things are failing despite all other attempts.

    See my blog post for more detail on this “address” field, and where to find it and how to change it.

  3. Finally, some may STILL get errors after making the changes above, and may need to add yet another new Tomcat AJP connector attribute, allowedRequestAttributesPattern, set on the server.xml file’s AJP connector line. And they may want to set it to “.*” (that’s a dot and an asterisk).  [Update after initial post: I had mistakenly put just *, originally. Sorry.]This is because the updated Tomcat AJP connector now only accepts certain incoming headers, and if anything in your environment sends in new headers, the AJP connector is choking on them. You can use various tools to find WHAT those headers are (and the Tomcat docs lists which ones it accepts by default). Again, see my post for more details.But I will note that I have seen folks using Apache who found that if they did a rewrite (whether via mod_rewrite or a .htaccess file) to a CF page, that CF page now failed to load, with errors due to this. Again, as a shortcut, just add the “.*” pattern indicated above, to allow any headers (or dig into finding and naming only the ones that you need). Just note that the AJP connector listens on a non-standard port, and the new secret feature (above) means that the chances of some unexpected, bad-guy request to it are now very slim. So “opening this hole” may not be as bad as it seems, especially as you struggle to get things working again.

Finding more detail

Some readers may be able to to take the ball (what I have shared above) and run with it.

But note that the technote for the updates (which I pointed to in my opening sentence here) do offer more details on each of these 3 points.

Beyond that many will have more questions (ranging from those who don’t do such updates often/don’t understand these things well, to those who DO apply such updates often/DO understand these things well), and I help such folks in the more elaborated post on this topic on my site, where I address the following questions/topics in more detail.

Dealing with the problem immediately:

  • How you can easily upgrade your CF web server connector
  • “I never ran this wsconfig tool, so does this not apply to my sites?”
  • Finding more about the update from Adobe
  • Why your sites may fail/what was changed with this update
  • How your sites may fail: what you may see
  • How this update affects any existing connector “secret” configuration
  • Handling if your web server is on a different machine than CF
  • What if I am in cf11 or earlier (or choose not to apply the Mar 2020 update), but want the security fix?

Thinking about the problem:

  • How would you have known of the need to upgrade the connector?
  • How such a connector upgrade was often recommended before, but is required with this update
  • How Adobe could make it MORE CLEAR that we might need to take these two extra steps
  • How these two “extra steps” will apply to those who skip this updates but do the next one
  • How a new CF installer for CF2018 and 2016 would really help us now
  • These changes are indeed ALL that this update implements

Finally, if you may have problems after applying the update and you feel that none of the 3 points above apply for you, see yet another blog post I’d done a year ago this month, “Having problems after applying a CF update? What to check, and how to recover!

Hope that’s helpful to readers.


For more blog content from Charlie Arehart, see his posts here as well as his posts at carehart.org. And follow him on Twitter and other social media as carehart.

5 Comments
2022-01-19 14:03:58
2022-01-19 14:03:58

[moved to below, being a reply to Laurie’s comment] 

Like
2022-01-19 13:39:39
2022-01-19 13:39:39

Hi Charlie,

I’ve installed CF2018 along with all the updates and then created an IIS connector using the manual process as per the adobe technote. I’ve used the manual configuration as software vendor we need CF for has recommended it.

If I look as the sever.xml the ‘secret’ is in the AJP 1.3 connector in the server.xml file.

If I run the wsconfig tool it does not show any connectors, I am assuming that this is because I have set this up manually.

Is there a manual way of adding the secrete information to a manually created connector?

Laurie

Like
(3)
>
Laurie218172189s5b
's comment
2022-01-19 14:04:25
2022-01-19 14:04:25
>
Laurie218172189s5b
's comment

Things can get messy, especially if done manually. But we should be able to solve whatever is amiss.

As for manually configuring things now, as the cf update technotes (like update 8 for cf2018) show, put a secret line in the workers.properties file for your connector, with its value matching the secret on the AJP connector line in the server.xml. Then restart IIS.

As for the wsconfig ui showing nothing, well, it shows something based not on any config in the web server like IIS (which it seems you may have created manually), nor even on the existence of a new numbered subfolder under the wsconfig folder (which you may have created manually). Instead it shows things based on the wsconfig.properties file (in the wsconfig folder), which perhaps you failed to create manually. And that file maps the web server site to the numbered wsconfig folder. A technote on manually configuring things should include that step, but maybe it doesn’t because the presumption is that if you’re doing things manually, you’d not then want to use the wsconfig tool. 

I hope the info above may help, along with replies I’d offer to your answers to my questions. But if you “just need to get it done”, we could solve this likely in minutes in an online session together. If interested, see the consulting page at carehart.org.

Like
>
Charlie Arehart
's comment
2022-01-20 16:17:26
2022-01-20 16:17:26
>
Charlie Arehart
's comment

Hi Charlie,

Firstly thank you for replying.

Looking in my server.xml fine in the connector protocol AJP/1.3 line there is a ‘secret’ value only.

The manual process for setting up the connect is taking from the adobe document located here https://helpx.adobe.com/coldfusion/kb/coldfusion-iis-manual-connector-configuration.html 

The document does not mention a wconfig.properties file so you are correct that I have not created one.

As this is a new server would it just be better to scrap the manualy created connector and run wsconfig?

Regards

Laurie

Like
>
Laurie218172189s5b
's comment
2022-01-20 16:57:24
2022-01-20 16:57:24
>
Laurie218172189s5b
's comment

Better? That’s debatable. Fixable as is? Definitely.

As for the secret, rename it to requiredSecret in server. xml, if you’ve applied recent cf updates.

As for the wsconfig.xml, do you have any working example on another machine? If so, use that as a model. Am writing from phone so can’t offer now.

Or again, we can resolve all this quickly in a consulting session, if you want to avoid that reinstall.

Like
Add Comment