Is LE currently checking for CAA records?


#1

Hi everyone,
I recently started to add CAA records for my domains to only allow LE to issue certificates, but I have not tested them out until now.

dig crashsec.com CAA returns this:

crashsec.com.           2419166 IN      CAA     1 issue "\;"
crashsec.com.           2419166 IN      CAA     0 iodef "mailto:domains@ayesh.me"
crashsec.com.           2419166 IN      CAA     0 issuewild "\;"

I tested this with all CAs disallowed, but I could generate a certificate successfully without a problem, from both staging server and production. (https://crt.sh/?id=113804463)

I’d appreciate if someone could shed a light if my DNS setup is at fault, or if LE is not actively checking CAA records prior to the certificate issuing just yet.


#2

LE does check CAA records.

In your dig output, you’ve got the Issuer Critical Flag set to “1”, which is incorrect according to the RFC. However, in my dig just yet, you’ve set it to the correct value of 128.
Did you check it with the new value too? I’m not sure if LE is picky about this, but it might.


#3

Thanks for the reply.
I changed it to 128 a few minutes ago, but AFAIK, Boulder allows both 128 and 1.


#4

I think boulder currently checks CAA at the time of challenge validation rather than during issuance. That means if you try to obtain a certificate using an account key that has successfully passed the ownership validation for your domain in the past 60 days (that’s the current lifetime for authorizations; it’ll be shortened to 30 days in the next few months), newly-added CAA records won’t affect issuance.

I don’t think issuance should work if you try this with a new account key, unless I misread the CAA record.


#5

This is the kind of self-referential habit that leads to hard-to-kill legacy problems. Boulder only (wrongly) allows this because people can’t read or understand RFCs, which in turn leads to people taking Boulder as a reference to confirm that 1 ought to be a valid value. It’s not.

I strongly recommend sticking to the RFC and not using a wrong value based on a single lax implementation.

  To ensure compatibility with future extensions to CAA, DNS records
  compliant with this version of the CAA specification MUST clear
  (set to "0") all reserved flags bits.

Boulder also shouldn’t violate the RFC intentionally:

  Applications that interpret
  CAA records MUST ignore the value of all reserved flag bits.

But what do I know. How can you expect a proper working standard if people not only violate it but implementers then bend to the invalid usage? It makes no sense to me. It’s like raising kids without setting any boundaries and then expecting them to follow rules.


#6

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