2017.09.09 Late Weak Key Revocation

On July 16, 2017 it was reported to Let’s Encrypt by researcher Hanno Böck that it was possible to get a certificate using a key known to be generated using the weak Debian random number generator. A specific certificate was given as an example. It so happens that Let’s Encrypt was already working on enhanced weak key checking which would have prevented the issuance in questions and deployment was imminent. Those mitigations were deployed to our production infrastructure on July 27, 2017.

Let’s Encrypt was already checking for some types of weak keys as required by the Baseline Requirements, but we were not checking for the particular type of weak key that was reported to us on July 16, 2017. The Baseline Requirements specify that weak key checking must be done but they do not specify a particular algorithm, therefore Let’s Encrypt weak key checking was formally compliant both before and after the weak key mitigations deployed on July 27, 2017. However, we are always happy to improve the quality of our weak key checker.

The Baseline Requirements do, however, require Let’s Encrypt to ensure that certificates are revoked if the associated private key is known to be compromised. We should have revoked the certificate referenced in the report from July 16, 2017, within 24 hours of receiving the report. We did not revoke the certificate within 24 hours of the report due to two contributing factors: the team was focused on improving weak key checking and the certificate was issued to a security researcher for testing purposes only. It was revoked on September 9, 2017, at 23:49 UTC, after the reporter posted publicly about the issue.

As a result of this late revocation we have reviewed and improved our processes for handling incoming reports.