Thanks for sharing this. I'm sure others will find it useful.

Having said that, just in case you're not aware, so long as port 80 of your server is publicly available (via reverse proxy is fine too), TurnKey servers can get their own Let's Encrypt cert (via HTTP-01 challenges - via port 80). It can be configured and triggered via Confconsole >> Advanced >> Let's Encrypt.

The challenges are served via port 80 by our custom mini-server; "add water" (which leverages the Dehydrated tool - we chose that because it's smaller, faster and leaks less info than "certbot"). Our wrapper script stops and restarts the webserver (where relevant) so that there is no port conflict and webserver config doesn't need to be changed or even considered (e.g. redirecting port 80 to 443 doesn't need to be disabled). Our tool works with any webserver (although only tested with Apache, Nginx, LigHTTPd and Tomcat - as they're the only servers we ship using port 80) or even on servers which don't have a webserver.

In newer releases, Confconsole also supports DNS-01 challenges too. No external port 80 access is required, making it ideal for locally hosted servers that aren't publicly available. It also supports wildcard domains (e.g. *.example.com) so if you're using a reverse proxy, you could get a single cert to use for all your current and future sites. (As an aside, I have plans to provide a TurnKey Reverse Proxy appliance at some point, but higher priority keeps getting added to my todo list above it). Although the version of Confconsole included in v18.0 appliance is buggy. (Gross oversight on my behalf - I thoroughly tested on v17.x but only lightly tested on v18.0 assuming that v17.x and v18.x envs would be "near enough" - I was wrong...).

I have a beta build which I've attached to a post there which hopefully resolves most (if not all) of the issues. Although I note that there is still room for improvement. If it's of any value to you, I'd love an extra tester and some more feedback.

Also re Apache config, whilst what you are doing isn't wrong (clearly it works), the symlinks in /etc/apache2/sites-enabled can be managed via the a2ensite/a2dissite cli tools. They simply create/remove the symlinks in /etc/apache2/sites-enabled (which when enabled point to the relevant config file in /etc/apache2/sites-available - as you appear to be aware)).

E.g. to disable webdavcgi:

a2dismod webdavcgi
systemctl restart apache2

And to re-enable:

a2enmod webdavcgi
systemctl restart apache2

Also you mentioned that even when disabled, WebDAV-CGI is still noted in Confconsole. That is because the Confconsole UI is actually pretty dumb. The services listed there are simply read from a text file found at /etc/confconsole/services.txt. To update what is displayed, simply remove the relevant lines from that file and it should "just work" (although if you have Confconsole running already, you'll need to restart it).