This mis-issuance incident was reported by Cybertrust Japan (CTJ), an 
intermediate CA of DigiCert.  
(https://bugzilla.mozilla.org/show_bug.cgi?id=1445857)

Here's the incident report:

1.    How your CA first became aware of the problem (e.g. via a problem report 
submitted to your Problem Reporting Mechanism, via a discussion in 
mozilla.dev.security.policy, or via a Bugzilla bug), and the date.

CTJ found a misissued certificate through its regular quality-control checking 
using cablint on cert.sh.
https://crt.sh/?id=353098570&opt=cablint

2.    A timeline of the actions your CA took in response.

A.      Mar 12, 2018 13:02:22 (JST) - The certificate was issued
B.      Mar 13, 2018 10:38 (JST) - Found the certificate during our daily check 
on cert.sh
C.      Mar 13, 2018 11:00 (JST) - Contacted the customer
D.      Mar 13, 2018 13:43:27 (JST) - Revoked the certificate
E.      Mar 14, 2018 - patched and tested issuance system

 3.    Confirmation that your CA has stopped issuing TLS/SSL certificates with 
the problem.

CTJ patched its system to reject the problematic request on Mar 14.

4.    A summary of the problematic certificates. For each problem: number of 
certs, and the date the first and last certs with that problem were issued.

Number of the affected certificate is one (1).  CTJ scanned all certificates 
issued in the past and only found the one reported above.

 5.    The complete certificate data for the problematic certificates. The 
recommended way to provide this is to ensure each certificate is logged to CT 
and then list the fingerprints or crt.sh IDs, either in the report or as an 
attached spreadsheet, with one list per distinct problem.

Please see https://crt.sh/?id=353098570&opt=cablint

6.    Explanation about how and why the mistakes were made or bugs introduced, 
and how they avoided detection until now.

The bug was not previously found by CTJ QA. The affected certificate was issued 
through an enterprise RA system. CTJ's front-end system rejects incorrect FQDN 
if request is for additional SAN(s) in certificate.  However, this checking 
function was missed for the CN.

7.    List of steps your CA is taking to resolve the situation and ensure such 
issuance will not be repeated in the future, accompanied with a timeline of 
when your CA expects to accomplish these things.

A. CTJ scanned already-issued certificates to see if they contained the 
incorrect string in the FQDN and to investigate if any additional problematic 
certificates existed.
B. CTJ patched its system on Mar 14.

Ben Wilson, JD, CISA, CISSP
DigiCert VP Compliance


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

Reply via email to