Re: Malformed Certificate Revocation - Godaddy
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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Malformed Certificate Revocation - Godaddy
CA first become aware: We first became aware of the malformed certificates https://crt.sh/?id=250008707=cablint,x509lint,zlint,ocsp & https://crt.sh/?id=49843724=zlint,cablint,x509lint,ocsp via a Bugzilla bug report on 5/18 and an email to practices@. Timeline of the actions: 5/18 1am UTC: Upon reviewing, and verifying the certs did indeed have a defect we started our revocation and rekey process by contacting the certificate owners. The owners were not immediately reachable, and/or needed time to perform the certificate swap. 5/19 10pm UTC: Certificates were revoked, after owner contact. Well within the 24hr required period. CA has stopped issuing defect: The identified certificates were defective due to a bug, which dated back to pre-2015. This defect rarely occurred. February 2018 the issue reoccurred, but was caught/prevented by the linter. We corrected the defect on 2/8/2018. Summary of the problematic certificates & complete certificate data: The printable string defect was found in the following certificates: This bug: https://crt.sh/?id=250008707=cablint,x509lint,zlint,ocsp https://crt.sh/?id=49843724=zlint,cablint,x509lint,ocsp Additionally, upon scanning our certificate store we identified: https://crt.sh/?id=167970618=cablint,zlint https://crt.sh/?id=246757501=cablint,x509lint,zlint All certificates with the defect were revoked within 24hrs following identification. Explanation about how and why the mistakes were made or bugs introduced: The defect occurred by improper handling of extended Unicode character. List of steps your CA is taking to resolve the situation: Certificates were revoked, rekeyed. Linting was added to the provisioning pipeline to prevent future occurrences in November 2017. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
