Deleted the _acme-challenge txt record

Help
1

Hi,
By mistake I ended up with two _acme-challenge txt records on the dns for this domain.
When I noticed it and after trying to figure out which one was the correct without any luck I deleted both thinking that the process might generate a new _acme-challenge info so I could add it to the dns again, which it did not happen and now obviously the renewal process fails since the _acme-challenge txt record is missing.

Is there anyway / anywhere I can get back the correct _acme-challenge txt record data to put back on the dns?
The current certificate is still valid until March 9, 2022

My domain is: bijoux.pt

I ran this command: Renewal it's auto run by the Plesk interface

It produced this output: ------

My web server is (include version): Apache 2.4.37-43 / PHP 7.4.27-1

The operating system my web server runs on is (include version): CentOS Stream 8

My hosting provider, if applicable, is: OVH

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): Plesk Obsidian Version 18.0.41

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): ----

2 Likes
2

Welcome to the Let's Encrypt Community, Fernando :slightly_smiling_face:

You need not worry since _acme-challenge TXT records for the DNS-01 challenge are only used once and should be removed immediately after each verification attempt regardless of whether the verification succeeded or failed.

If, on the other hand, you removed an _acme-challenge CNAME record, which delegates the DNS-01 challenge to another domain name, that would need to be restored.

5 Likes
3

There's no delegation I just added a domain alias and would need to include the wildcard on the certificate so I followed the reissue process but it fails with a message

image
image1922×1089 144 KB

2 Likes
4

I think the issue is that your CAA records should be letsencrypt.org and not just letsencrypt.

6 Likes
5

Thank you.
You made really look into the dns and there was the obvious error...

||bijoux.pt.|3600|CAA|1 issue "letsencrypt"||
||bijoux.pt.|3600|CAA|1 issuewild "letsencrypt"|

instead of letsencrypt.org I had just letsencrypt
fixed it and all is good now

/note to self... do not cleanup dns zones late at night

Thank you so much @griffin

4 Likes
6

You are quite welcome!

:blush:

3 Likes
7

One last question if you do not mind, if I understood you correctly I should actually delete the _acme-challenge TXT records?

Wouldn't that prevent the auto-renewal done automatically by Plesk when needed (before expiration etc)?

2 Likes
8

Correct. Or rather, Plesk should. There's no harm in your doing so though.

Nope. The TXT records are one-shot and never reused, so Plesk would need to add new records at renewal time anyhow.

8 Likes
9

Thank you for clarifying it @griffin

I use a mix system, the dns is on OVH system and on my the actual dedicate servers I do not run dns (bind) at all, email is also elsewhere (on google) so I do have to add records by hand and in this case I'll delete them too.

3 Likes
10

If you're adding DNS TXT records manually, the certificates won't renew automatically. Automatic renewal for DNS-01 assumes that you have a method for automatically adding and removing the TXT records.

Also, some hints regarding your CAA records:

;; ANSWER SECTION:
bijoux.pt.              3600    IN      CAA     1 issuewild "letsencrypt.org"
bijoux.pt.              3600    IN      CAA     1 iodef "mailto:info@bijoux.pt"
bijoux.pt.              3600    IN      CAA     1 issue "letsencrypt.org"

You have set the least significant bit of the flags value on your CAA records. As per RFC 8659, this bit is currently reserved for future use and must not be set.

You probably intended to set the critical flag, which would mean setting the MSb. However, the current spec doesn't allow that either, as that's meant for extensions, not the base spec. As per the current specification, the flag value should be 0. Let's Encrypts CAA checker is relatively permissive at this time, but future changes to the CAA specification can create unpredictable changes to that behaviour, if your CAA record violates the specification.

Additonally, having both issue and issuewild set to the same value is redundant. issue controls all issuance, if issuewild is not present. So you do not actually require the issuewild directive in your case.

Also, note that many CA's, including Let's Encrypt, do not support CAA iodef, so you won't see any mails regarding (failing) CAA.

7 Likes
11

@_az

Per this:

Is there an issue here with Let's Debug considering the records to be marked as critical?

5 Likes
12

Thanks, it's fixed now. Let's Debug was treating iodef as unknown which was interacting poorly with the detection of unknown critical flags.

5 Likes
13

Should it have been marked as critical at all though given the LSb vs MSb difference? Maybe I'm misunderstanding @Nummer378's comment.

4 Likes
14

There's also this to consider, which I'll probably copy over as well.

3 Likes
15

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