Detect and Notify Users about Incompatible/Not-Fully-Compatible Apache Modules

[jvanasco]

Certbot's Installer works great with "vanilla" Apache, but is often incompatible with many of the "mod_" plugins for at least the two following reasons:

1- Some mods extend the Apache configuration files with inline scripting (e.g. mod_perl, mod_python). Certbot cannot parse these files. These issues pop up often on the LetsEncrypt forum, but there are only about 3 people there who have used those mods before and recognize the unsupported syntax in the file – so people often end up doing extensive troubleshooting for an obvious problem.

2- Some mods define unique commands that are unsafe to copy. Issues #4797 and #8373 cover this, with #4797 deciding to eventually support a blocklist of these commands.

To better support both situations, I would like to see the following change in Certbot:

Detect the presence of problematic Apache modules when possible (basically anything that allows scripting within configuration files). If there is an error during installation, note something like the following to the user:

The issue is possibly due to Certbot not supporting the syntax of the following detected apache modules: [list here].  The Certificate may still be automatically installed.

If you're able to detect a blocklisted configuration command, notifying that via #4797 should still be done.

Most people who use the scripting modules will be familiar enough with Apache to install the Certificate themselves. The ones who don't, are likely to post the message to the LetsEncrypt forum – which will give a lot of community members a valuable clue.

[alexzorin]

1. For the inline scripting, we have done this recently with the nginx plugin and lua blocks: #9475. If it's possible to do this with Augeas, we could try it. The httpd.aug grammar will probably need to be updated. It appears to already support inline <perl> code: https://github.com/certbot/certbot/blob/71a14f5193722b2f6b01d3a128cedb2575e06fd1/certbot-apache/certbot_apache/_internal/augeas_lens/httpd.aug#L182-L184 Is there an example of inline mod_python code in the wild, and any examples of inline scripting code crashing Certbot?

2. I like this approach. We can note potentially problematic directives that are encountered during parsing, and then mention them if a parsing error or error during the Apache restart post-installation occurs.

[jvanasco]

I can't recall any examples offhand. I can look on the community site the next break i have. From personal experience, most times I've seen this issue no Apache configuration had been shared yet - I just recognized the error, I'd tell the OP it sounds like "mod_whatever" can't parse the file and a manual config will work, and they reply back in 2 minutes that a manual config worked perfectly and the issue was solved. People running this stuff tend to know Apache well and can handle the configuration themselves rather easily - they just see some incredibly popular tool like Certbot failing and think everything must be broken because they expected it to easily handle their use-case.

I do think one of the Apache mod_*s broke outside of a <Perl></Perl> (or whatever) block, because of the following pattern:

• Apache configuration block included mod_whatever
• mod_whatever enabled advanced parsing/interpolation on normal configuration lines that used a syntax unsupported in normal Apache. e.g. the line contained something like "Foo ${{Bar}}${{Biz}};"

So my suggestion above was meant to not just cover known directives and "potentially unsafe" sections, but also track the inclusion of the various mod_* projects and suggest they may be the cause when an installation error occurs within a block containing them.

[jvanasco]

Note: This also fails on OpenResty (Nginx) install attempts. See https://community.letsencrypt.org/t/access-by-lua-block-and-certbot/209409