With --keep by the way, certbot will not acquire a new certificate if your current one is not close to expiration. It simply "reinstalls" your existing certificate if one is available.
In addition to what @petercooperjr said, I'd like to add a hybrid approach. You can always use the following to prevent certbot from modifying your apache configuration with its "installer" while still using the apache "authenticator". It will save your from having to enter/maintain the webroot folders in your certbot renewal configuration files by still using the apache "authenticator" (which does not modify your apache configuration files).
Note: This method requires you to either already have a functioning port 443 vhost or create one yourself using the SSL directives in other, existing port 443 vhosts as working examples.
I know just enough about Apache to be dangerous, but I think something along those lines would work, yes. And then you can run certbot in webroot mode instead of apache mode, so it won't touch your configuration files at all. Give it some --dry-run attempts and see!
There are a lot of ways one can set things up, depending on what exactly you're trying to do. I only mentioned the webroot approach because you'd mentioned preferring certbot not touch your configuration files. (Whereas one of the main purposes of certbot can be to "fix my configuration to start serving HTTPS for me", that might not be your specific goal here.) And of course, there are plenty of clients other than Certbot available too, if you have even more specialized requirements or preferences.
Thanks. As a semi-retired webmaster, I'm looking to keep things simple though these days.
I am wondering how I can create the ip6.f4g.tech again which is ipv6 specific. Why did it cause a problem? It seemed like a legitimate configuration albeit very simplistic.
Also f4g.tech and www.f4g.tech certificates were renewed yesterday. OK for sure, just not sure how this happened?
Hence why I suggested the hybrid solution using the certbot apache authenticator and deployment hook. Since it uses no certbot installer, it shouldn't modify your apache configuration. Thus, you benefit over the webroot authenticator by not needing to specify webroot directories for certbot for each domain name you certify.
The trouble with the IPv6-specific virtual host is that it was more specific than the correct wildcard-ip (*) hosts and therefore had higher precedence.
Name-based virtual hosting is a process applied after the server has selected the best matching IP-based virtual host.
I think all you need to do is add the ipv6 name as a ServerAlias on the appropriate virtual host, and then have the ipv6 name only have an AAAA record in DNS. I think it should be fairly straightforward, though like I just said I know just enough about Apache to be dangerous.
Please read my response above yours regarding IP-based virtual hosts in apache, @petercooperjr.
There's never a point to do this, to my knowledge, since IP-matching occurs before name matching. It's a creative solution though, but apache just isn't that flexible.
I thought you'd changed all the virtualhosts to be *:80 / *:443 format, so it was just using the ServerName/ServerAlias now? Perhaps I misunderstood what changes you've already made; I'm probably just confused and should stop talking.
Definitely listen to @griffin, he certainly knows more about Apache & certbot than I do.
I believe (though I don't have a specific reference) that apache will only choose an IP server name if the IP address is presented as the host in the SSL handshake for https or host header for http, which would only occur if the visitor actually used the IP address in their address bar.
This is why I cringe every time I see IP addresses listed anywhere in an apache configuration file (except for reverse proxy). Almost no one uses them correctly.
Right, so what I thought you'd done was remove the IP addresses from the config, so if Apache is just based on names now then it should allow for adding another name (the ipv6 one) to the same virtual host. If you're still IP-address based, though, then yeah it might not work as easily.
You are correct there, but then how would ip6.f4g.tech be IPv6-specific without specifying the IP address via <VirtualHost IPv6:80>?
Here's the conundrum about ip6.f4g.tech as I understand from the apache documentation link I posted above:
If you specify the IPv6 specifically, it will take precedence over every virtual host with a wildcard IP
If you specify a wildcard, it will also be included for IPv4 matching
The only solution I see available in apache parlance is to additionally specify the IPv6:80 in every virtual host (in addition to the *:80) so that they will be considered for the second-tier name matching after the first-tier IP matching. Silly, huh?
One would think apache would match both the best IP address and best name at the same time/level.
Because the name in DNS would only have an AAAA record.
The usual way I'd expect this to work is that the "normal" DNS entry has both an A and AAAA record, but the "ipv6" DNS name entry has only the AAAA record, and probably the same one.
So you just need Apache to expect that both names mean the same host.
But yes, this is assuming you're using only *:443 type virtualhost records.
Ah... you're filtering the possible IP-address presentation to the apache server at the DNS-record level. Clever. That would work. I've done that for other circumstances (like eliminating the useless www subdomain from my domain names), but never for IP address types.
Well, why would you add an A record to an ipv6-specific address? What would you put there?
Though at this point, IPv6 support is generally good enough (where even if you don't have IPv6 access adding the AAAA record is unlikely to break things) that just having one dual-stacked name is the best approach for most user-facing things. But adding an ipv6-specific name can help when testing some things, certainly, when you're wondering why some systems can connect and some can't.
Makes sense. I've unfortunately found that most of the time when an experience differs from IPv4 to IPv6, it's almost always a bad thing via degraded functionality when using IPv6. This isn't a reflection on IPv6 itself, but the adoption of it. I don't know enough about the nuances of IPv6 to know if there are some kind of "added features" or "performance benefits" (or something else) available when using IPv6 over IPv4.
To summarize what @petercooperjr and I were discussing, you can have ip6.f4g.tech be IPv6-specific by:
Adding a AAAA record to your DNS specifically for ip6.f4g.tech
Removing any A records in your DNS for ip6.f4g.tech
Removing any AAAA records in your DNS for f4g.tech and any of its subdomains except the ip6 subdomain (only if you don't want them to respond over IPv6)
Changing all of the IP addresses in your apache configuration files to *'s.
I've done that for other circumstances (like eliminating the useless