CAA record suddenly failing for wildcard certificates

Help
1

Since today, the renewal of my certificates fails, I'm getting the error "Challenge failed: CAA record for *.abrecht.li prevents issuance". It was working before for years, and I haven't changed anything. I do have a CAA record, and it does list letsencrypt:

dpa@dragonfly:~$ nslookup -query=CAA abrecht.li
Server:		10.60.10.2
Address:	10.60.10.2#53

Non-authoritative answer:
abrecht.li	rdata_257 = 128 iodef "mailto:caa@danielabrecht.ch"
abrecht.li	rdata_257 = 128 issuewild "letsencrypt.org; validationmethods=dns01"
abrecht.li	rdata_257 = 128 issue "letsencrypt.org; validationmethods=dns01"

I tried adding the "issuewild" entry today after I got that error, but it didn't help at all. DNSSEC also seams to still work fine. I don't see anything wrong on my side, so please fix whatever has broken at LE.

My domain is: dpa.li, abrecht.li, danielabrecht.ch

I ran this command:

My own script GitHub - Daniel-Abrecht/DPA-ACME2: A small ACME v2 client which uses other programs to solve ACME challanges instead of doing it itself

./DPA-ACME2/dpa-acme2.py \
  --ca https://acme-v02.api.letsencrypt.org/directory \
  --account-key account.key \
  --csr certs/domains.csr \
  --output certs/domains-new.pem \
  --contact mailto:letsencrypt@danielabrecht.ch \
  -- \
  dns-01 zone-update.py --server 127.0.0.1

But that's not relevant, the error was returned from letsencrypts servers.

It produced this output:

  File "/var/local/acme/./DPA-ACME2/dpa-acme2.py", line 170, in completeChallenge
    raise Exception('Challenge failed: '+challenge_result['error']['detail'])
Exception: Challenge failed: CAA record for *.abrecht.li prevents issuance

My web server is (include version):
I'm using bind9 and the DNS01 challenge

My hosting provider, if applicable, is: Me

I can login to a root shell on my machine (yes or no, or I don't know): yes

2

Let’s Encrypt has recently started supporting validationmethods, which is why this started failing. Enabling ACME CAA Account and Method Binding

You need to have dns-01 specified. Note the dash, which your entry is missing.

14 Likes
3

Thank you very much, that was it. Now it works again!

6 Likes
4

Since LE only recently started supporting it, shouldn't the issuance have failed before? @DPA has set the critical flag, which means "if you don't understand it in full, you are not allowed to issue a certificate".

5

Well, the actual feature has been added to Boulder 4 years ago already: https://github.com/letsencrypt/boulder/pull/3716

So one can argue Boulder actually understood it, but choose to ignore it, as the feature was disabled up until December 2022.

The RFC does not forbid "understanding but ignoring" a critical feature I think.

That said, if I read the Boulder code correctly:

It does not actually check for issue/issuewild parameters except for the values it knows. And does not error out if it comes across an unknown parameter.

3 Likes
6

I just had a look at the RFC again, and it says

A CA MUST NOT issue certificates for any FQDN if the Relevant RRset for that FQDN contains a CAA critical Property for an unknown or unsupported Property Tag.

defining "Tag" as "The Property identifier", e.g. "issue" or "iodef". So I think I got this wrong in the first place, as it simply doesn't apply to values and parameters. RFCs really have to be read like legal texts. However it also says "unsupported", which means, in case of a Tag, ignoring it is not an option. :grinning:

I now think the sole purpose of the critial flag is to make the standard future-proof. There's simply no reason to set it for any of the Tags defined with the first version of the standard.

3 Likes
7

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