I'd like to push a bit harder on searching for more systemic remediations. "We forgot to get around to revoking it" is a pretty common element of CAs' post-mortems, I think it'd be good for us to dig deeper.
For example, does Let's Encrypt have a runbook that gets used on misissuance reports? Is one the steps creating a persistent tracking item (e.g. a bug/ticket/issue) to revoke as required? I created https://misissued.com/ to assist the mdsp community in tracking these types of issues. It doesn't have any auth, so obviously anyone can put whatever garbage they want in (please don't though :-)), but if someone would find exposing data on a per-CA basis, or as JSON, or something else useful, I'd be more than happy to. These are just some off the cuff thoughts, but IMO "human error" should be a root cause of last resort. Alex On Mon, Sep 11, 2017 at 11:08 AM, josh--- via dev-security-policy < [email protected]> wrote: > This was simple human error. There isn't a programmatic fix. > > Our team is planning to scan our database for weak keys again early this > week. In any case, any weak key certs issued prior to our July 20 fix will > expire in at most 37 days. > > On Monday, September 11, 2017 at 8:24:49 AM UTC-5, Alex Gaynor wrote: > > Hi Josh, > > > > Does Let's Encrypt plan to implement any systematic or programmatic fixes > > to ensure certificates are promptly revoked in the future? > > > > Did you perform a scan of all your issued certificates to see if any > others > > were effected? > > > > Alex > > > > On Sat, Sep 9, 2017 at 8:14 PM, josh--- via dev-security-policy < > > [email protected]> wrote: > > > > > Thank you for bringing this oversight to our attention. The > certificate in > > > question has been revoked. > > > > > > The original incident report from July 16 was accidentally considered > > > closed on the basis of a fix for our infrastructure without actually > > > revoking the certificate that led to the report. > > > > > > Reading the recorded conversation, it seems we got overly focused on > fix > > > for our infrastructure and lost sight of the fact that the certificate > > > itself needed to be revoked. I imagine our guard was let down a bit by > the > > > fact that the cert was issued specifically to test us, it wasn't a > weak key > > > "in the wild." > > > > > > Let’s Encrypt has checked for some forms of weak keys since we > launched, > > > and we added additional checks that would have caught this on July 20, > > > 2017. We were already in the process of developing and deploying the > > > additional checks before we received the original report from Hanno. > > > > > > On Saturday, September 9, 2017 at 2:22:07 PM UTC-5, Hanno Böck wrote: > > > > Hi, > > > > > > > > A while ago I tested how some CAs would react to certificate requests > > > > with debian weak keys. > > > > > > > > I was able to get a certificate from Let's Encrypt with a debian weak > > > > key. Here is it: > > > > https://crt.sh/?id=173588030 > > > > > > > > I reported this to Let's Encrypt. They told me that they are aware > they > > > > weren't checking debian weak keys, but they were in the process of > > > > deploying a check: > > > > https://github.com/letsencrypt/boulder/pull/2765 > > > > > > > > I don't know if this is active by now, but I assume so. > > > > > > > > Maybe notable: The certificate hasn't been revoked, despite me > > > > reporting it. However I haven't explicitely asked for revocation > (and I > > > > could revoke it myself, given that I have the private key). > > > > > > > > > > > > I have also tried to get a cert with a debian weak key from the > > > > free trial offerings from Comodo and Symantec. Both rejected the > > > > request. > > > > > > > > -- > > > > Hanno Böck > > > > https://hboeck.de/ > > > > > > > > mail/jabber: [email protected] > > > > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > > > > > > _______________________________________________ > > > dev-security-policy mailing list > > > [email protected] > > > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
