Wildcard certificate renewal fails for some domains

Help
1

Hi,

I already setup certbot on a debian system to get wildcard certificates and I could happily get a few certificates for a few quarters.

But since a few months 2 out of the 3 domains I'm managing for a friend are unable to get renewed.

The failure message is:

Processing /etc/letsencrypt/renewal/example.com.conf

Simulating renewal of an existing certificate for *.example.com and example.com

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: example.com
Type: unauthorized
Detail: Incorrect TXT record "......." (and 1 more) found at _acme-challenge.example.com

Domain: example.com
Type: unauthorized
Detail: Incorrect TXT record "..." (and 1 more) found at _acme-challenge.example.com

Hint: The Certificate Authority failed to verify the DNS TXT records created by the --manual-auth-hook. Ensure that this hook is functioning correctly and that it waits a sufficient duration of time for DNS propagation. Refer to "certbot --help manual" and the Certbot User Guide.

Failed to renew certificate example.com with error: Some challenges have failed.

I usually produce "standalone" certificates that I securely communicate to the friend that he can deploy on his self-hosted server.

I'm using certbot 1.29.0:

$ certbot --version
certbot 1.29.0

Before being able to sucessfully generate a wildcard certificate, I had to dig into the internet for a while.
I'm using certbot and acme-dns-auth.py.
See acme-dns-certbot-joohoi.

A quite good and concise tutorial among many can be found there: How To Acquire a Let's Encrypt Certificate Using DNS Validation with acme-dns-certbot on Ubuntu 18.04.

For each domain there is a CNAME Resource Record pointing to auth.acme-dns.io. :
_acme-challenge CNAME 1800 xxxxxxxxx.auth.acme-dns.io.

This suppress the need to manually setup a TXT resource record and wait for its propapagation.

Some of the commands I could use successfully are:
$ sudo certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d \*.example.com -d example.com
$ sudo certbot renew

The failure when renewing some wildcard certificates seems related to the TXT resource record (automated via CNAME resource record pointing to xxx.auth.acme-dns.io.)

=
Now, I just checked the CNAME resoure record for these three domains.
I can see an anomaly: the two domains that have failure for getting certificate renewal have the same CNAME RR! Who did that?...

From there, I deleted one domain managed by certbot which certificate renewal failed.
$ sudo certbot delete --cert-name example1.com

Then doing:
$ sudo certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d \*.example1.com -d example1.com
I hoped to be requested to add a new CNAME, say:

Please add the following CNAME record to your main DNS zone:
_acme-challenge.subdomain.your-domain CNAME 8450fb54-8e01-4bfe-961a-424befd05088.auth.acme-dns.io.

But I just encountered a failure message introduced herebefore.

Let's assume getting a new unique CNAME for each of these 2 domains is the solution.
Do you agree?

If you agree, can you tell me how to do that?
Thanks.

2

Looking in the forum for some hints, I found that topic:
CNAME Unknown for certbot renew

This is exactly what I did: puling out the CNAME value for the 2 affected domains from /etc/letsencrypt/acmedns.json
And this solved my problem. Great!

How could I solve that problem cleanly from the CLI?

What are the necessary commands to manage (create, delete, revoke, etc.) standalone TLS certificates?
Here are the commands I mainly use:
$ sudo certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d \*.your-domain -d your-domain
$ sudo certbot certonly --manual --manual-auth-hook /etc/letsencrypt/acme-dns-auth.py --preferred-challenges dns --debug-challenges -d \*.your-domain -d your-domain
$ sudo certbot renew
$ sudo certbot delete --cert-name example.com
$ sudo certbot revoke --cert-name example.com
$ sudo certbot certificates
Some kind of minimalistic but complete certbot guide about "How to automatically generate TLS certificates in standalone mode with certbot and acme-dns-certbot-joohoi"?

Side questions:
Q1 Is it possible to setup several certbot servers to deliver TLS certificates? (I suppose it is, if there is one CNAME RR on each domain for each certbot server)

Q2 Is using acme-dns-certbot-joohoi (i.e. using xxx.auth.acme-dns.io) 100% safe?...

3

Why would you need to do these commands?:

4 Likes
4

for Cuba libre, of course!

1 Like
5

Instead of pulling out the CNAME value from /etc/letsencrypt/acmedns.json how could I solve that problem cleanly from the CLI?

Regarding Side questions do you prefer that I create new topics?

Q1 Is it possible to setup several certbot servers to deliver TLS certificates? (I suppose it is, if there is one CNAME RR on each domain for each certbot server)

Q2 Is using acme-dns-certbot-joohoi (i.e. using xxx.auth.acme-dns.io) 100% safe?...

Q1 seems easy and Q2 is not that simple.

6

Using acme-dns.io requires trusting the operator of that DNS server, which is not 100% safe.

4 Likes
7

You can, however, run your own instance of acme-dns, so it doesn't require 3rd party services.

Of course for utmost safety, you'd need to screen the source code of acme-dns for vulnerabilities or back doors yourself and compile it yourself too :wink: The latter isn't hard (quite easy frankly), but the former is perhaps more difficult :stuck_out_tongue:

5 Likes
8

Can you elaborate about the risks? The scope appears fuzzy to me.

What damages could make the owner of auth.acme-dns.io?

9

They could potentially obtain certificates from your domain.

4 Likes
10

Is there a way to be informed that certificates have been delivered against my will?
By, say, letsencrypt.org?

In addition, I control the DNS example.com -> IP addr .
So if a guy would illegaly generate a certificate for my domain, he would also need to change this DNS record so people rech his fake site.
Am I forgetting something?...

11

This is one of the use-case of Certificate Transparency. You can subscribe to a service that monitors these logs for you and notifies you.

Various companies offer this as a service (Cloudflare, StatusGator, Facebook, sslmate and many more) and of course you can also do it yourself.

Not necessarily. Traffic running through the internet can be intercepted by malicious parties to invisibly read, modify or redirect network packets. This is why we even use HTTPS in the first place. The exact attacks used vary depending on where the attacker sits and who the victim is. It can range from attacks on single LAN networks to wide internet range BGP attacks, wire manipulations and much much more.

6 Likes
12

GREAT LINK! @Nummer378 Thanks!

5 Likes
13

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