It produced this output:
Attempting to parse the version 1.18.0 renewal configuration file found at /etc/letsencrypt/renewal/mail.lukraun.com.conf with version 1.12.0 of Certbot. This might not work.
My web server is (include version):
Apache version 2.4.48
The operating system my web server runs on is (include version):
Debian 11 Bullseye
My hosting provider, if applicable, is:
Hetzner
I can login to a root shell on my machine (yes or no, or I don't know):
yes
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
Webmin v 1.98
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
root@yingarna /etc/letsencrypt/live/mail.lukraun.com 02:28 PM # certbot --version
certbot 1.12.0
The 1.12 to 1.18 error message threw me
I think what has occured is snap installed 1.18 of certbot and then somehow webmin or maybe even update from command line has regressed the install back to 1.12
I did a remove and reinstalled snap and certbot I am now at 1.19.
certbot 1.19.0 from Certbot Project (certbot-eff✓) installed
Also webmin now says i don't have then agree-to set and tells me to use cli options to set these correctly.
Option --agree-tos must be enabled. Use CLI Options to fix this.
Option --email must be enabled. Use CLI Options to fix this.
Option --no-eff-email must be set. Use CLI Options to fix this.
but if i save it tells me i don't have a cli.ini
Failed to open /etc/letsencrypt/cli.ini for writing : No such file or directory.
I will upgrade webmin to 1.981 see if that fixes it but i doubt it it is probably something to do with the way snap installs it.
Sorry to go to press so fast on this error message
ok upgraded webmin to 1.981 no change
I did an edit config in the certbot module within webmin it created a blank cli.ini and the letsencrypt directory under /etc.
I set all the settings it was complaining about via webmin but i still had to edit the cli.ini via vi to set the no-eff-email to false I also placed this 4th on the list in the file IE
I'm trying to create a certificate with a wildcard for multiple virtual domains. That way I can just generate three certificates for the three domains I host but have apache serving up multiple different virtual domains all using those three certificates.
I'm guessing that this won't work because it can't resolve a wildcard address you can only do that with self signed.
The error I get is
certbot --apache -d *.example.com --preferred-challenges=dns
None of the preferred challenges are supported by the selected plugin
If i try without the preferred challenges parameter it says
Client with the currently selected authenticator does not support any combination of challenges that will satisfy the CA. You may need to use an authenticator plugin that can do challenges over DNS.
I will probably have to go back to the old method i used with a certificate for each virtual domain which seems wrong. I will probably leave the mail server certificates the same though to match MX etc
Doesn't like -i apache on debian 11
Ok foolishly I tried to get wildcards to work by installing a dns plugin And ran a command line install command from another post on wildcards to install
python3-certbot-dns-google
It overwrote my certbot install back to 1.12..
So it seems I need to figure out how to add DNS capability via a snap install
There is currently no Certbot plugin for the use of Hetzner-DNS.
You might have a look at this guide to achieve your goal:
Using the above tutorial from my hoster and dns provider I was able to set up two of the three wildcard dns records for the three domains I have. Since the domain i was unsuccessful with was a .com.au in Australia where i am, and the dns is in Germany and the Debian server running apache is in Finland I think the issue will be with propagation of dns records.
I haven't looked at mail certs yet and the letsimap plugin I use. But I expect that will work as well.
I need to rationalize my dns records with wildcard certificates.
I didn't realize you can specify *.domain.blah in a dns so you can setup any virtual host without specifically having to add a DNS entry for it and just using the wildcard letsencrypt certificate. I'm sure it's some kind of security risk but it's useful, not the forum, but welcome comments. I only enabled TLS1.2 and TLS1.3
The original problem was command line apt and webmin plugins panel causing regression from the version of certbot snap installs 1.19 to the default 1.12 from the Debian 11 sources which I should also fix.
I recommend this setup for anyone with multiple virtual domains. I think I'll be ok from here on.
Of course 3rd party plugins might not be as stable as official plugins though. Also the snap by "Michael Cramer (bigmichi1)" seems to be a fork of the original plugin. However, that's probably a good thing, as the bigmichi1 fork has 29 additions to the original at the moment, mostly snap-related stuff. But seems to be more actively maintained, which is good!
One last post.
The Hetzner method is best because with the hook it automatically renews whereas with the plugin it is manual renewal.
Both methods are useful. There was one domain I could not generate a certificate for so i installed the hetzner plugin and generated a certificate manually and added the two text records to my dns to validate. Then i went back regened the api key and reran the certbot command with wildcards for all three domains and now it's all singing and dancing.
