CAA Record checked after DNS Challenge completed

Help
#1

It seems that the CAA Record in the following case is checked after the DNS entries were registered and DNS-Challenge completed : (for the test I set: 0 issue “;”)

certbot certonly --staging --test-cert --cert-name domain.rsa --dns-route53 -d domain.de -d www.domain.de

Output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Found credentials in shared credentials file: ~/.aws/credentials
Plugins selected: Authenticator dns-route53, Installer None
Starting new HTTPS connection (1): acme-staging.api.letsencrypt.org
Obtaining a new certificate
Performing the following challenges:
dns-01 challenge for domain.de
dns-01 challenge for www.domain.de
Starting new HTTPS connection (1): route53.amazonaws.com
Waiting 10 seconds for DNS changes to propagate

Waiting for verification…
Cleaning up challenges

Resetting dropped connection: route53.amazonaws.com
An unexpected error occurred:
Error creating new cert :: Rechecking CAA: While processing CAA for www.domain.de: CAA record for www.domain.de prevents issuance, While processing CAA for domain.de: CAA record for domain.de prevents issuance

I checked Route53: the DNS entries for domain.de and www.domain.de were registered .

I think the DNS should be changed only after the assessment of the CAA entries. I rerun the test three times with the same result. I used the current certbot version 0.21.1 via yum on CentOS 7.4.

#2

Hi,

You will need to check if you have any DNS CAA record exist for this domain.

(Although i can’t find any)

Please show us your real domain.

Thank you

#3

This should be in #help

#4

Sorry, domain.de is only an example.

Yes the record is there. If the CAA record would not exist, certbot would not abort because of it.

Certbot aborts, but only after fulfilling the DNS-Challenge. I think the termination should be before.

#5

Hi,

nope, it’s actually after DNS are finished.
P.S. Comodo and globalsign all are done in this way. (You finished the verification, then they can’t issue you the cert because policy block, which means you still get to finish verification.)

Thank you

#6

“We’ve always done it that way.” “This is the way it’s done in the industry.”

#7

I don’t really know what’s the reason they did in this way since I’m not related to anyone in CA industry, maybe @schoen can clarify?

#8

CA must check CAA-Records before issuance, not before Challenge. RFC 6844.

Challenge is valid for several days, so checking before challenge don’t make sense - CAA-Record can be changed between challenge and issuance.

2 Likes
#9

Moved to “Help” topic. Arguably it could belong in “Issuance Policy” as well.

#10

When your ACME client POSTs a challenge associated with a pending authorization for a domain Let’s Encrypt performs an initial CAA validation request for the domain alongside the challenge validation request.

Since as @tob mentions (thanks!) we are also required by the baseline requirements & RFC 6844 to check CAA within 8 hours of issuance, we also may have to recheck CAA for a name at the time of issuance when the valid authorization held by the account for the identifier was validated > 8 hours ago.

In this case since the error message was prefixed by “Rechecking CAA:” we can tell this second condition is what happened. Your issuance was likely using a previously validated authorization (recall that valid authorizations are reused) that was validated more than 8 hours ago, requiring a CAA recheck that failed the issuance.

We do check CAA before the DNS challenge is completed for the initial pending authorization. Hope that helps explain things.

3 Likes
#11

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