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 <jeremy.row...@digicert.com>; r...@sleevi.com; Mike vd Ent 
<pasarellaph...@gmail.com>
Cc: Ben Wilson <ben.wil...@digicert.com>; mozilla-dev-security-policy 
<mozilla-dev-security-pol...@lists.mozilla.org>
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: r...@sleevi.com; Mike vd Ent <pasarellaph...@gmail.com>
Cc: Ben Wilson <ben.wil...@digicert.com>; mozilla-dev-security-policy 
<mozilla-dev-security-pol...@lists.mozilla.org>
Subject: RE: CA Validation quality is failing

I’m looking into it right now. I’ll report back shortly. 

 

Jeremy

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Wednesday, April 19, 2017 2:25 PM
To: Mike vd Ent <pasarellaph...@gmail.com>
Cc: mozilla-dev-security-policy 
<mozilla-dev-security-pol...@lists.mozilla.org>; Jeremy Rowley 
<jeremy.row...@digicert.com>; Ben Wilson <ben.wil...@digicert.com>
Subject: Re: CA Validation quality is failing

 

 

 

On Wed, Apr 19, 2017 at 3:47 PM, Mike vd Ent via dev-security-policy 
<dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> > 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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to