Hi Daymion, I will summarise briefly my understanding of this report in case it is wrong, if so please correct me, I apologise, and the rest of the email is probably of no further importance:
GoDaddy integrated a linter (checking the certificates for sense) in November 2017, and in February this linter caught an error of the same sort described in this report and GoDaddy corrected the software defect which made it possible for the error to occur. In May other certificates with the error (some of them still in-date) were reported to GoDaddy, and these have been revoked and replaced. In terms of lessons learned, obviously this incident is further evidence of the value of "linting" as a valuable defence in depth for Certificate Authorities, and I hope anybody else who was still on the fence about that has it on their TODO list. But it seems to me that the February incident could and should have triggered somebody at GoDaddy to scan their store of issued certificates back then for any previous examples, and thus avoided the subsequent incident report. Commercially this offers better value to GoDaddy subscribers, since if you did this internally you'd be able to offer subscribers a more generous and business-aligned timeline to revoke and replace, rather than being on the clock due to an incident report for their certificate. I also have a small question: Does GoDaddy's linter check the To Be Signed Certificate, or the finished signed Certificate (or both)? The effect here is that the tbsCertificate doesn't constitute issuance, but technically once the certificate is signed it "exists" even if you are careful never to deliver a certificate to the subscriber if the linter detects a problem. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
