On Debian 11 with version 1.12 format is 1.18

My domain is:
lukraun.com

I ran this command:
certbot revoke --cert-name mail.lukraun.com

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

Why?
What problem are you trying to fix with that?

Please show the output of:
certbot certificates

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

find / -name certbot
which certbot
/snap/bin/certbot --version

Revoking fixes nothing.

Yeah i set them up wrong in the first place

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

agree-tos=true
eff-email=true
email=xxx@xxx.xxx
no-eff-email=false

That fixes the first self inflicted problem.

This next bit isn't working for me.

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

Wildcard certs can only be done over DNS.
Try changing
--apache
to just
-i apache

[it should prompt/allow you to process the request (DNS portion) manually]
[if that "works", then you need to work on how to automate the renewals]

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

OR
Use another ACME client; One that has a DNS plugin for the DNS Service Provider (DSP) you use.

Please see the certbot site for this: Certbot - Debiantesting Apache (direct link to the wildcard tab/page)

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.

1 Like

Not officially, no, but I did find this 3rd party plugin on snap: Install certbot-dns-hetzner on Linux | Snap Store

1 Like

That comment about there not being a plugin was a cut and paste out of the support call I logged with Hetzner.

Boy, were they wrong! :grin:

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!

2 Likes

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.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.