Thanks Mike for bringing this up. We’ve looked into it and have an initial report to share.
After receiving the email on the Mozilla list, we investigated the identified certificates and discovered a couple of very related issues in our process that led to certificates with bad info: 1. As Jakob pointed out, part of the issue was that our intake form required a state if US was selected. As country is the last requested field, the state only became optional after the customer completed the rest of the form. This led to a lot of customers submitting bad data. 2. We have an old tool that generates information based on a customer’s location. This tool helps customers create CSRs and complete certificate requests. The tool inserts bad data into some fields if the field is left blank by the customer. The result was customers using this tool outside of the US had numbers included in the state field. 3. There was a gap in our validation process. This is the more important issue as the validation process should have caught the bad data inserted by the other two issues. Although we are obtaining validation documents from the appropriate government entity, the data submitted via the tool or intake form was not properly being updated with retrieved validated information. The end result was that the bad CSR data was submitted for signing instead of the data listed on the government document. This was a personnel problem, not a failure in our system as the validation staff was not appropriately updating the required signing fields. So far, we have identified approximately 600 certificates that have the wrong state, zip, or locality. This is just a measurement of the problem scope and not the exact number as we are still reviewing are certificate database using a mapping API to determine whether the address exists. We expect the search to have a lot of false positives initially but provide a maximum scope of the problem. In parallel, we are contacting each customer with a non-compliant certificate, replacing the certificate, and revoking the certificate. All mis-matched certificates are being uploaded to the Google and DigiCert CT logs. To fix our process, we are planning the following: a. We are immediately deprecating our geolocation tool and updating our intake form to help reduce the amount of bad data. b. We are updating our validation process to flag the differences in validation data and customer-provided data. c. We are providing our validation staff with an extra mandatory tool that checks address information for accuracy. Part of our process going forward will be to use a separate source to verify that the city/state are actually in the country specified by the certificate. 4. Finally, we are implementing additional restrictions on our CA that prohibit signing of bad locality/state/zip information. We have a tool internally named “cert shield”. This tool is similar to CAB lint and that checks information submitted to the CA for compliance with the BRs and EV Guidelines. The rule set in cert shield is being updated to include additional restrictions designed to catch issues like numeric states and cities. I’ll report back more on our progress next week with additional ideas. Please let me know if you have any questions. Jeremy -----Original Message----- From: Jeremy Rowley Sent: Wednesday, April 19, 2017 7:49 PM To: Jeremy Rowley <[email protected]>; [email protected]; Mike vd Ent <[email protected]> Cc: Ben Wilson <[email protected]>; mozilla-dev-security-policy <[email protected]> Subject: RE: CA Validation quality is failing FYI - still looking into this. I should have a report tomorrow. -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert....@lists.mozilla.org] On Behalf Of Jeremy Rowley via dev-security-policy Sent: Wednesday, April 19, 2017 2:27 PM To: [email protected]; Mike vd Ent <[email protected]> Cc: Ben Wilson <[email protected]>; mozilla-dev-security-policy <[email protected]> Subject: RE: CA Validation quality is failing I’m looking into it right now. I’ll report back shortly. Jeremy From: Ryan Sleevi [mailto:[email protected]] Sent: Wednesday, April 19, 2017 2:25 PM To: Mike vd Ent <[email protected]> Cc: mozilla-dev-security-policy <[email protected]>; Jeremy Rowley <[email protected]>; Ben Wilson <[email protected]> Subject: Re: CA Validation quality is failing On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy <[email protected] <mailto:[email protected]> > wrote: Ryan, My answers on the particular issues are stated inline. But the thing I want to address is how could (in this case Digicert) validate such data and issues certificates? I am investigation more of them and afraid even linked company names or registration numbers could be false. Shouldn't those certificates be revoked? You are correct that it appears these certificates should not have issued. Hopefully Jeremy and Ben from DigiCert can comment on this thread ( https://groups.google.com/d/msg/mozilla.dev.security.policy/DgeLqKMzIds/ig8UmHT2DwAJ for the archive) with details about the issues and the steps taken.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
