I just reported the following to firstname.lastname@example.org: Let's Encrypt has issued the following certificates in violation of the Baseline Requirements' CAA checking requirement: 1. https://crt.sh/?sha256=C396951C4C594897BE11B09494DD567B00A0A946735F3DECC01A9D966A179F41 2. https://crt.sh/?sha256=435F08B5A9536E2B8F91AB8970FF9F8D93A1A0A5529C2D8388A10FA59FF3758C Certificate 1 contains a single DNS identifier for cname-deny-sub.basic.caatestsuite.com. The following DNS records are relevant: cname-deny-sub.basic.caatestsuite.com. IN CNAME sub.deny.basic.caatestsuite.com. deny.basic.caatestsuite.com. IN CAA 0 issue "caatestsuite.com" There is no CAA record at sub.deny.basic.caatestsuite.com. According to RFC 6844, the only CA allowed to issue for cname-deny-sub.basic.caatestsuite.com is caatestsuite.com. Certificate 2 contains a single DNS identifier for expired.caatestsuite-dnssec.com. 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 expired.caatestsuite-dnssec.com were expired. It appears from https://unboundtest.com/ 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.
Josh, 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: https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
Assignee: kwilson → jaas
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.
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: https://groups.google.com/d/msg/mozilla.dev.security.policy/9y-XTajmOCw/5hicEUHqAAAJ
Given Mozilla's position, cert #1 is not misissued. The issue relating to cert #2 has been remediated. Gerv
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.