Adding --pre-hook and --post-hook for certbot?

Webmin
1

OS: Ubuntu 24.04.3 LTS x86_64
Webmin version: 2.520

The problem is that apache2 is already running on port 80 (and will continue to be).

I’m having some difficulty figuring out how to get certbot --pre-hook and --post-hook running via Webmin. For now I’m just trying to get setup for Webmin to use Let’s Encrypt rather than the default self-signed cert. However I will also be migrating other domains to the server later, and want to have this sorted out in advance.

I’ve tried adding the files with root execute permission (or all users, it doesn’t matter):

/etc/letsencrypt/renewal-hooks/pre/000-apache2-stop.sh
/etc/letsencrypt/renewal-hooks/post/000-apache2-start.sh

However they appear to be ignored when using certbot via Webmin. Nor is there a configuration option (that I could find) for adding them via Webmin Configuration → SSL Encryption → Let’s Encrypt. Also, apart from the FQDN I’m using the “Certbot built-in webserver” option, and the rest left to defaults.

What is the best place to add these hooks so that apache2 doesn’t interfere with Webmin’s management of certbot certificate requests and auto-renewals?

Or, is it safe to simply execute: certbot certonly --standalone --pre-hook "service apache2 stop" --post-hook "service apache2 start" -d $DOMAIN via the command line (as I normally would)?

FYI, I do have Virtualmin installed also, though my setup is already on a VPS and I don’t expect to be deploying additional virtual servers via Virtualmin. I also couldn’t locate any relevant setting in the Virtualmin configuration.

I’m open to suggestions if I’m overlooking something or there’s a better approach.

2

So, a few…comments, not really answers.

  1. Webmin can request certs for itself (it uses certbot, but it handles the renewals and putting the cert into place), and it can do so using Apache.
  2. certbot can also work with Apache and doesn’t need to stop it. Don’t use the standalone mode if you’ve already got Apache running on port 80, instead just configure certbot to use an Apache VirtualHost document root for the validation.

This feels like an “everything works if you let it” situation. It seems like you’re going out of your way to make this complicated and then running into complications.

3

Oh, wait. What the hell does Webmin need more certs for, if you’re using Virtualmin? Just connect to any domain you’re managing with Virtualmin and has a TLS cert. Webmin isn’t separate from Virtualmin. Webmin doesn’t need any of its own certs, if you already have certs for Virtualmin-managed domains.

So, you’re making this even more complicated…just let Virtualmin do it.

4

I hear you. Part of the reason I have it stopping and starting apache is because my apache config has a directive to automatically upgrade http requests to https across the board (all virtualhosts), which interferes with certbot wanting to use a plain text connection on port 80 via /.well-known. Since the renewals only happen every 60 days or so, I don’t consider it a problem for the server to get stopped for a few seconds every once in a while. It’s functionally no different than my rebooting when there’s a kernel update.

5

This is a brand new install. I’m just getting it configured before migrating my existing services over to it. I’m not using Virtualmin. It’s a VPS (QEMU) with Ubuntu as the base OS, and I used the automatic install script which came with Virtualmin. I almost certainly won’t be using Virtualmin for anything (just Webmin and occasionally Usermin) and have nothing setup with Virtualmin thus far beyond the defaults it came with. All I’ve done up to this point is install a few packages, and some preliminary security hardening via Webmin and the cli.

6

FYI, maybe I’m misunderstanding what Virtualmin even does. This is my first time having it available, so I’m not sure what it’s functionality is exactly or how it would fit with my use-case. I have used Webmin as a stand-alone admin tool, but not in several years. Previously I’ve done everything by hand via the cli. So, my approach may be flawed based on lack of understanding / n00b’ness. I had the impression Virtualmin was for deploying VPS’s, which wouldn’t make sense since I’m already on a VPS with limited resources for anything more than apache2, mariadb and postfix, et al.

7

No.

Virtualmin is a web hosting control panel.

1 Like
8

Guess I need to scour the docs. I have to come up with a migration plan for several domains I’m hosting, including email, so can’t really afford to f things up if it can be helped. certbot is also kinda finicky if it’s not setup right in the first place, particularly in light of the whole http/https config, etc. I know how to do it manually via the cli, but not sure what the impacts of having Virtualmin do that will be.

9

You just need to not do that. Or, at least not do it that way. You need to exclude .well-known from any redirection and proxy rules.

That’s true with Virtualmin, too. Nothing can make validating Let’s Encrypt via HTTP work if it can’t retrieve the verification file via HTTP.

10

To be fair, that’s the point of pre/post hooks… I suppose I could rejig how I’m doing https upgrades, but that’s a whole other rabbit hole that’s likely to complicate things in itself. Would be nice if Webmin et al, just respected /etc/letsencrypt/renewal-hooks.

11

Virtualmin will set this up correctly for your hosted VirtualHost (websites) so that ACME HTTP-01 validation works; we also create redirects to HTTPS in Virtualmin, but .well-known is always excluded.

And yes, hooks won’t work with Webmin because we don’t use certbot renew. We use certbot certonly everywhere since Webmin has an option to set up a renewal schedule.

I suggest giving Virtualmin a try. It will save you a lot of time in the end.

1 Like
12

Thanks. I’ve obviously got some reading to do. Thankfully I gave myself ample lead time to migrate everything, and have at least one domain with very low traffic to experiment with first in case of snafu.

Just a side-note, but my understanding is that certbot certonly also uses the renew hooks. I gotta learn more about how that all works with Webmin/Virtualmin to decide if it’s gonna be worth it and so I can use it effectively. I’ve previously had some experience using Plesk because clients had it preinstalled, and frankly it’s roll-your-own way of dealing with certbot ended up causing me endless needless headaches. I’m really hoping this will be different, particularly if/when it comes time to move anything off this system to a server without Webmin/Virtualmin.

13

Yes, since we use certonly and --no-autorenew, it won’t run any hooks.

However, @Jamie, we could easily make it an option and add --deploy-hook /path/to/hook/hook.sh if it’s set.

But with Virtualmin, you don’t need to worry about any of this.

1 Like
14

That has my vote fwiw. Particularly for those who have Webmin installed by itself without Virtualmin.

If I were to run certbot (eg. with certonly --standalone) via the cli without going through Webmin/Virtualmin, would that interfere with Virtualmin, or can they safely operate side-by-side? Specifically at the moment I don’t have any domains setup other than the hostname provided by my ISP, and it won’t have a website or even necessarily email.

Also where can I find documentation about how/where Webmin/Virtualmin store their configuration (presuming it’s not directly modifying the vendor configs in their usual location)? I’m used to doing everything manually via the cli, and would feel more comfortable if I can keep my typical workflow as needed without causing myself extra headaches.

15

This is perhaps a bit off-topic from the OP, but my main concern in coming up with a migration plan is how to switch the DNS over for each of the domains.

That will be especially critical when it comes to email. I have a bunch of extra postfix config (including opendkim, etc) that I’ll probably want to add manually (ie. via main.cf, etc) and need to make sure there’s as little to no downtime or bounces as possible when that happens.

16

Yes, later releases of Virtualmin can work well with some websites renewed manually using the certbot command outside of Virtualmin. But you shouldn’t really do this, as you should let Virtualmin handle it all for you, hassle-free.

You can set up an automatic SSL request for the hostname in Virtualmin. It handles everything for you, including renewals.

All Virtualmin configs are stored in the /etc/webmin/virtual-server directory. Both Webmin and Virtualmin also surgically modify service configs directly, like for Apache, Dovecot, or Postfix, etc.

Yes, it’s supported in most cases, but it’s better if you know and understand Virtualmin more to co-collab seamlessly.

We have good documentation here:

You can easily install Virtualmin using the following command:

sudo sh -c "$(curl -fsSL https://software.virtualmin.com/gpl/scripts/virtualmin-install.sh)" -- --bundle LAMP
1 Like
17

DNS is simple. You spin up a new system, test things using local DNS or the “Preview Website” feature in Virtualmin, and when everything is ready, just change the DNS to it.

We support all those too, and it should work, though it may require manual intervention depending on what kind of custom configuration you have.

1 Like
18

Thanks!

That’s what I did. I haven’t added anything yet via Virtualmin whatsoever as I’m still trying to wrap my head around it. I was thinking I’d add the FQDN associated with reverse DNS first (assigned by the ISP), just to get a feel for it, and then move on to the domain with least traffic to be sure I’ve got the process nailed down perfectly before I try with anything mission critical

.

19

I didn’t install bind during the installation process. Does that matter? Will that prevent requesting TLS certs if I haven’t yet switched the DNS via my hosting provider? I don’t mind using bind (albeit it’s been years) if it’s possible to do so retroactively, but I didn’t want to complicate things when my external DNS hosting has generally been bulletproof so far. Also, the registrars are scattered all over the place, so I didn’t want the extra hassle of contacting clients and trying to fiddle with their existing NS settings.

20

Bind is installed automatically. Yet, you don’t really need it if you use cloud DNS or host DNS elsewhere.

It will work just fine with the HTTP challenge. However, if you want the DNS challenge to work, which is basically required for wildcard certs only, you will need to let Virtualmin control your DNS.

To be clear, it’s always better to let Virtualmin manage your DNS, especially since you’re going to host mail.

You’ll need to do quite some work to add SPF and DKIM records to DNS and such; it’s not worth it. For the test FQDN you mentioned earlier, just add an NS record in your existing DNS zone pointing to your Virtualmin server. That’ll let Virtualmin manage this domain DNS and all its sub-records. You’ll see how much easier and faster it makes things.

Start with your domain or subdomain to understand how it works; you don’t need to change it on the register side for a dedicated subdomain.