Closed Bug 1445857 Opened 2 years ago Closed 2 years ago

DigiCert: Mis-issuance of certificate with https in CN/SAN

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: benwilsonusa, Assigned: benwilsonusa)

Details

(Whiteboard: [ca-compliance])

This mis-issuance incident is reported by Cybertrust Japan (CTJ), an intermediate CA of DigiCert. 

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 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 find 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.
Whiteboard: [ca-compliance]
(In reply to Ben Wilson from comment #0)
> This mis-issuance incident is reported by Cybertrust Japan (CTJ), an
> intermediate CA of DigiCert. 
> 
> Here's the incident report: 
>   
Ben - thanks for reporting this. Please also post this incident report to m.d.s.p. - it is standard practice to record and track incidents in Bugzilla but to also disclose them on m.d.s.p.

> 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
> 
Why is this check not being performed prior to issuance?
Flags: needinfo?(ben.wilson)
(In reply to Wayne Thayer [:wayne] from comment #1)
> (In reply to Ben Wilson from comment #0)
> > This mis-issuance incident is reported by Cybertrust Japan (CTJ), an
> > intermediate CA of DigiCert. 
> > 
> > Here's the incident report: 
> >   
> Ben - thanks for reporting this. Please also post this incident report to
> m.d.s.p. - it is standard practice to record and track incidents in Bugzilla
> but to also disclose them on m.d.s.p.
> 
Will do.
> > 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
> > 
> Why is this check not being performed prior to issuance?
CTJ does operate a front end checking system that was capable of catching a malformed SAN but did not have a filter for this particular instance with a malformed Common Name.  That front end system has now been patched.  CTJ will explore the viability of other pre-issuance mechanisms, things similar to cablint.
Flags: needinfo?(ben.wilson)
A post to mozilla.dev.security.policy from Ben Wilson contains the following update: we are integrating pre-issuance checking via the established certificate linting program into our issuance pipeline. It is scheduled to deploy by the end of next week.

Ben: Please confirm when this has been completed.
Assignee: wthayer → ben.wilson
QA Contact: kwilson → wthayer
Cybertrust Japan has now integrated pre-issuance checking into its issuance pipeline via a certificate linting program.  I believe this matter should be closed.
Action items complete; resolving.
Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Summary: Mis-issuance of certificate with https in CN/SAN → DigiCert: Mis-issuance of certificate with https in CN/SAN
You need to log in before you can comment on or make changes to this bug.