Extend the CAA Exception period

Issuance Policy
1

With the emails that went out ~ 3 days ago regarding CAA exception, it did not contain which domains assigned to your account have an incorrect setup.

Ourselves, and I imagine many others, manage hundreds or thousands of domains via LetsEncrypt, and it is unfeasible for these to be tested manually.

I would like to request an extension to the 1 1/2 months grace period on the workaround until a better way to notify administers has been found, whether that is an improved email with a list of the failed domains, or some other means.

With it also potentially requiring a fix by DNS providers, 1 1/2 months seems dangerously short notice to identify the domains, DNS providers, notify the providers and expect a fix to be rolled out into production.

Thanks,
Alex.

2

Hi @alexbowers,

From September 8th, the CAA check will be mandatory for all CAs, so in my opinion, an extended period won't be possible but @cpu or @jsha could give you accurate info regarding this issue.

Just in case you want to check it, the current baseline requirements document is here https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.8-redlined.pdf

And the section regarding CAA records is 3.2.2.8:

3.2.2.8. CAA Records

This section is effective as of 8 September 2017. 

As part of the issuance process, the CA MUST check for a CAA record for each dNSName in the subjectAltName extension of the certificate to be issued, according to the procedure in RFC 6844, following the processing instructions set down in RFC 6844 for any records found. If the CA issues, they MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater. 

[...]

Cheers,
sahsanu

3

I wasn’t aware of a hard date set into the document. That’s a shame.

Perhaps the other part of the request could be actioned on then?

To notify with the correct domain name before this comes into force, so that there is a higher chance of any issues being resolved.

4

CAs are permitted to treat a record lookup failure as permission to issue if:

  • the failure is outside the CA's infrastructure;
  • the lookup has been retried at least once; and
  • the domain's zone does not have a DNSSEC validation chain to the ICANN root.

Let's Encrypt could continue CAA exceptions indefinitely, but would probably have to make software modifications to meet the requirements.

(For example, i don't think Boulder currently asks the DNS resolver whether a domain uses DNSSEC.)

5

It’s also worth noting that Let’s Encrypt already implements aspects of the CAA check process. A response indicating Let’s Encrypt is not an authorized CA, or a servfail response, already prevents Let’s Encrypt from providing a certificate. This has been the case for weeks, so if you would be affected by this change, you should already be seeing renewal failures.

6

There is other topic regarding this issue CAA exception notifications don't mention the failing domain

7

Hi @alexbowers,

Sorry again for failing to include the list of affected domains in the email that got sent out. I’ve updated the CAA SERVFAIL changes thread with the list of all affected domains, to cross-reference against your own.

It’s worth noting that if you renew any affected certs shortly before the deadline (say, August 30), then you have a full 90 days before those certificates expire in which to help users fix the problem or migrate DNS providers. And I definitely sympathize about having a short timeline to fix things. We tried to get the communication out sooner, but as often happens, events intervened.

Let us know if we can be of any help diagnosing specific problems.

1 Like
8

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