ISRG / Let's Encrypt: CAA Misissuances



CA Certificate Mis-Issuance
6 months ago
6 months ago


(Reporter: Andrew Ayer, Assigned: Josh Aas)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [ca-compliance])



6 months ago
I just reported the following to

Let's Encrypt has issued the following certificates in violation of the
Baseline Requirements' CAA checking requirement: 


Certificate 1 contains a single DNS identifier for  The following DNS records
are relevant: IN CNAME IN CAA 0 issue ""

There is no CAA record at  According to
RFC 6844, the only CA allowed to issue for

Certificate 2 contains a single DNS identifier for  This DNS name has no CAA record, but at
the time I requested an authorization for it (Sat Sep  9 03:07:05 2017 UTC),
the RRSIGs for were expired.

It appears from that Let's Encrypt's DNS resolver
does not consider expired DNSSEC signatures to be an error.  This violates
RFC 4033 Section 8.1:

"The signatures associated with signed zone data are only valid for the
time period specified by these fields in the RRSIG RRs in question."

and RFC 4034 Section 3.1.5:

"The RRSIG record MUST NOT be used for authentication prior to the
inception date and MUST NOT be used for authentication after the
expiration date."

Therefore, the CAA record lookup for this DNS name should fail and since
there is a DNSSEC validation chain from this zone to the ICANN root,
this failure cannot be treated by the CA as permission to issue.

Comment 1

6 months ago

Please update this bug promptly to indicate acknowledgement of the problem and a timeline for resolving the immediate problem.

Then provide an incident report in this bug, as described here:
Assignee: kwilson → jaas
Blocks: 1029147
Whiteboard: [ca-compliance]

Comment 2

6 months ago
We received an email about this on Friday September 8 at 10:04pm Pacific. Within 24 hours of receiving the report we:

* investigated both reported compliance issues
* confirmed certificate details and revoked both certificates in question
* deployed all necessary fixes to our production infrastructure
* communicated the results of our investigation to the reporter

With the exception of any necessary wider communication, we consider the matter closed.

Regarding Certificate #1

We are aware that the observed behavior is technically non-compliant, however:

* We believe our behavior is preferable and that the CA community generally agrees.
* We believe the BRs will be amended soon to make our current behavior compliant.
* We believe root programs will not have an issue with our current behavior.
* We believe a short-term change in longstanding behavior may be confusing to subscribers.
* We believe fixing this short-term will create unnecessary code churn, which introduces risk.

So long as a ballot to fix the BRs is proceeding, or until a root program objects, we are not planning to change our behavior in this regard. We will revoke certificates for this issue if requested in good faith by the subscriber.

If Mozilla would like us to change our behavior please let us know as soon as possible. We advise against it.

Regarding Certificate #2

Our resolver accepted the expired response because by default it allowed for some clock skew (i.e. there was an expiration grace period). Within 24 hours of the initial report we deployed a change to our production environment that eliminates the clock skew allowance.

Comment 3

6 months ago
On Thursday September 14 between 10am and 11am Pacific Let's Encrypt deployed a change bringing our CAA checking algorithm into compliance.

Since deploying that change we have received numerous reports of problems due to the compliant but problematic algorithm and we expect problems to mount as certificate renewal cycles come around. We have asked for public permission from the Mozilla root program to return to the algorithm we were originally using, which is generally believed to be better and will likely become compliant over the next couple of months:
Given Mozilla's position, cert #1 is not misissued. The issue relating to cert #2 has been remediated.

Last Resolved: 6 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.