Renewal failures - "CAA prevents issuance" with unchanged CAA

Help
1

LE is complaining that CAA prevents issuance during renewal. CAA has not changed last renewal, nor has certbot, its configuration., or the DNS records for the certificate.

CAA records are
litts.net. 600 IN CAA 128 iodef "mailto:security@litts.net"
litts.net. 600 IN CAA 128 issuewild "letsencrypt.org"
litts.net. 600 IN CAA 128 issue "letsencrypt.org"

Verified visible from multiple external systems. Verified OK with dnsviz.net (for DNSSEC).

The last successful renewal was 26-Mar-2023.

Has Boulder changed its CNAME processing, e.g. reduced tree climbing? If so, what are the minimal zones that need CAA records to make Boulder happy?

What's particularly odd is that NONE of the 6 domains requested in the certificate are accepted. So if is a tree-climbing issue, I would expect the non-CNAME domains too be happy...

My domain is: litts.net

The requested certificate:
Subject: CN = wikiworld.litts.net
Subject Alternative Name:
DNS:wikiworld.litts.net,
DNS:wikiworld.sb.litts.net,
DNS:wikiworld.v4.litts.net,
DNS:wikiworld.v4.sb.litts.net,
DNS:wikiworld.v6.litts.net,
DNS:wikiworld.v6.sb.litts.net

I ran this command:

certbot -n renew

It produced this output:
Renewing an existing certificate for wikiworld.litts.net and 5 more domains

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Domain: wikiworld.litts.net
Type: caa
Detail: CAA record for litts.net prevents issuance

Domain: wikiworld.sb.litts.net
Type: caa
Detail: CAA record for litts.net prevents issuance

Domain: wikiworld.v4.litts.net
Type: caa
Detail: CAA record for litts.net prevents issuance

Domain: wikiworld.v4.sb.litts.net
Type: caa
Detail: CAA record for litts.net prevents issuance

Domain: wikiworld.v6.litts.net
Type: caa
Detail: CAA record for litts.net prevents issuance

Domain: wikiworld.v6.sb.litts.net
Type: caa
Detail: CAA record for litts.net prevents issuance

The logfile doesn't reveal anything else of obvious interest.

My web server is (include version):
apache
The operating system my web server runs on is (include version):
Linux
I can login to a root shell on my machine (yes or no, or I don't know):
Yes
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 1.32.0

2

there was a resent change handling DNS on staging but don't think it landed prod yet

as it looks like you run own auth dns stack, can we know what your dns server runs?

3 Likes
3

There have indeed been recent changes made to DNS resolution in Boulder. I'm not sure if they're the cause of your problem though.

I have a few general remarks about your CAA records though, even if they're not directly related to your issue:

  • Setting issue and issuewild to the same value is redundant and has the same effect as just setting issue.

Ah, I think I have found it: A recent Boulder refactoring seemed to have changed the handling of criticial flags regarding iodef:

You have set the "critical" bit of the CAA records. Let's Encrypt never supported iodef and a recent refactoring seems to treat iodef as unknown. If you now set the critical bit on iodef, the CAA check fails.

This change landed in production yesterday.

Also, according to RFC6844 and RFC8659, the critical flag is meant for future extensions of the standard. issue, issuewild and iodef are all part of the baseline standard, so it's not clear whether they even can be "unknown extensions". I would recommend you to remove the critical bits, since they don't have any effect under normal circumstances anyway.

8 Likes
4

Independently reproduced myself on a test domain: Critical iodef fails CAA.

iodef.nocache.de:Verify error:CAA record for iodef.nocache.de prevents issuance

@lestaff Might want to look at whether this change was intended.

7 Likes
5

Yep, @Nummer378 found it. This is because you have the "critical" flag set on your iodef records.

The CAA RFC actually has two different pieces of language regarding the same behavior.

Section 3 just uses the phrase "unknown":

Issuers MUST NOT issue certificates for a domain if the relevant CAA Resource Record set contains unknown property tags that have the Critical bit set.

However Section 5.1 says both "unknown or unsupported":

A Certification Authority MUST NOT issue certificates for any Domain that contains a CAA critical property for an unknown or unsupported property tag that for which the issuer critical flag is set.

Let's Encrypt "knows about" but does not "support" the iodef property tag. Previously, our behavior matched the Section 3 langauge. Currently, our behavior matches the Section 5.1 language.

However, changing this behavior was not intentional, and even if it were intentional should have been accompanied by an API announcement and a turndown period.

Apologies for the breakage. I'm putting together a change to move us back to the Section 3 way of doing things, and you should be able to get issuance after the deploy next week.

That said, I strongly advise removing the "critical" bit from your iodef property tags, since that tag is not widely supported.

Edit: change is here: CAA: Don't fail on critical iodef property tags by aarongable · Pull Request #6921 · letsencrypt/boulder · GitHub

13 Likes
6

Thanks for tracking this down.

I'll remove critical from iodef since additional domains (and acme agents) are (still) failing.

I included critical because I'd rather have things break than unknowingly allow a rouge certificate to issue. I guess I got my wish :frowning:

7 Likes
7

The change to allow critical iodef is in staging as of yesterday and should be in production tomorrow.

8 Likes
8

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