I've been able to successfully install letsencrypt certificates using certbot. However, in order to do so, I had to disable my apache2 configs that rely on mod_perl because of parsing failures. I cannot remove this dependency, so my first instinct was to use renewal-hooks to disable then re-enable certain configs around the renewal process. However, the 'pre' hooks don't run until after the apache configuration is validated... so that's not going to work for me (renewal doesn't make it past the validation).
Does anyone have recommendations for inserting a script into the certbot renewal pipeline before validation?
I attempted to modify the systemd snap.certbot.renew.service (not recommended, according to certbot docs -- and the file itself) by adding ExecStartPre=/path/to/deconfig.sh, but I'm not so sure that is working. Testing with certbot renew --dry-run still fails validation.
System Info: Ubuntu 20.04 with Apache 2.4, root access, no control panels, self-hosted. Latest version of certbot installed via snap.
Wow, mod_perl! I haven't used that in 15 years! It sounds like you're using mod_perl for a bit of configuration and not just as an application framework.
I think the easiest solution in your case will be dropping the "apache" plugin and either using the webroot (as @rg305 suggested) or standalone plugins. With webroot, you configure both apache and certbot to serve the acme-challenge file from the same filesystem directory. With standalone, certbot runs it's own server; you can specify it on a higher port with " --http-01-port=8081", and then you proxypass the well-known requests to apache onto that port. Personally, I prefer to use standalone because I find the configuration and coordination much easier.
Another popular strategy is to run another service in front of the mod_perl server (which you set to run at higher port), such as nginx or a "vanilla apache", which will terminate the SSL, handle certbot, and proxy-pass back to the mod_perl apache. This is very popular with mod_perl developers when they use the library as an application framework, but it might not be easily compatible with your usage. From personal experience, nginx in front of mod_perl has made nodes incredibly more efficient and really reduced server costs.
thanks @rg305, I double-checked and configtest runs fine, as does the site (both before and after installing certs)...
I'll see about using --webroot and report back!
@jvanasco yep, we're serving up a 25 year-old application... and perl is tightly intertwined with the apache processes. I may play around with the standalone approach, but I'm guessing that you're probably right that webroot is likely to be my easiest path forward.
That really isn't the whole story there. Apache is notorious for running at all costs.
Triple check that there aren't any overlapping name:port entries.
Whether you're doing webroot or standalone, I strongly suggest you approach a solution by setting up a dummy response that can be tested before using certbot. With standalone, I spin up a dummy python webserver (fake_server.py); with webroot you need to make sure Apache is mapping the right directory to the url.
The mod_perl library lets you place Perl and, a bunch of library specific stuff, into an Apache configuration file. Regular Apache, and tools like Certbot which parse the Apache configuration file format, can not read the mod_perl enabled files - which break the syntax and format.
