Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Let's Encrypt Incident Report: Broken CAA Record Checking
1,116 views
Skip to first unread message
jo...@letsencrypt.org
Dec 8, 2015, 11:17:18 AM12/8/15
to mozilla-dev-s...@lists.mozilla.org
ISRG CPS Section 4.2.1: "The CA checks for relevant CAA records prior to issuing certificates. The CA acts in accordance with CAA records if present."
At 9:45am U.S. Pacific time on December 7th, 2015, it was reported to us that our Certificate Authority Authorization (CAA) record checks were not working properly [1]. We determined that the report was accurate.
At 1:11pm U.S. Pacific time on the same day a fix was deployed to production. The fix has been verified to be correct.
The cause of the problem was determined to be a bug in our "boulder" CA software.
An analysis of logs and our certificate database determined that six certificates were improperly issued to domains restricted by CAA. These certificates have been revoked.
https://crt.sh/?id=11015552
https://crt.sh/?id=11129526
https://crt.sh/?id=11129525
https://crt.sh/?id=11145944
https://crt.sh/?id=11146361
https://crt.sh/?id=11147768
We work hard to make sure that we're issuing in compliance with all relevant policies. We will be reviewing our policies and procedures to determine how we might best reduce the risk of such a mistake happening again.
[1] https://github.com/letsencrypt/boulder/issues/1231
At 9:45am U.S. Pacific time on December 7th, 2015, it was reported to us that our Certificate Authority Authorization (CAA) record checks were not working properly [1]. We determined that the report was accurate.
At 1:11pm U.S. Pacific time on the same day a fix was deployed to production. The fix has been verified to be correct.
The cause of the problem was determined to be a bug in our "boulder" CA software.
An analysis of logs and our certificate database determined that six certificates were improperly issued to domains restricted by CAA. These certificates have been revoked.
https://crt.sh/?id=11015552
https://crt.sh/?id=11129526
https://crt.sh/?id=11129525
https://crt.sh/?id=11145944
https://crt.sh/?id=11146361
https://crt.sh/?id=11147768
We work hard to make sure that we're issuing in compliance with all relevant policies. We will be reviewing our policies and procedures to determine how we might best reduce the risk of such a mistake happening again.
[1] https://github.com/letsencrypt/boulder/issues/1231
Kathleen Wilson
Dec 8, 2015, 11:40:50 AM12/8/15
to mozilla-dev-s...@lists.mozilla.org
OneCRL: https://bugzilla.mozilla.org/show_bug.cgi?id=1231138
Of course, we also need to have a discussion about what actions we are
going to require of the CA to fully remedy this situation.
Josh, in the meantime, please keep this group informed of steps Let's
Encrypt is taking to ensure this has been fully addressed and will not
happen again.
Kathleen
Phillip Hallam-Baker
Dec 8, 2015, 12:37:54 PM12/8/15
to Josh Aas, mozilla-dev-s...@lists.mozilla.org
People are using CAA.
Cool!
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Cool!
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Peter Kurrasch
Dec 9, 2015, 6:39:46 PM12/9/15
to mozilla-dev-s...@lists.mozilla.org
FYI, the RFC URL in BR 1.3.1 section 1.6.1 for CAA is malformed.
Original Message
From: Phillip Hallam-Baker
Sent: Tuesday, December 8, 2015 11:37 AM
People are using CAA.
Cool!
Original Message
From: Phillip Hallam-Baker
Sent: Tuesday, December 8, 2015 11:37 AM
People are using CAA.
Cool!
0 new messages