1451446 - DigiCert / ABB: greater than 825 day cert issuance

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Brenda Bernal]

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

Jason Sabin (CIO) was notified by Alex Gaynor 2018-03-16 14:03 UTC that one of our SubCA's, ABB, had issued a certificate with greater than an 825 day lifespan.

2.	A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

-	2018/03/01: Ballot 193 maximum 825-day life takes effect
-	2018/03/15, 09:08 UTC: ABB mis-issued a certificate valid for 30 months
-	2018/03/16, 13:03 UTC: DigiCert notified by Alex Gaynor regarding this certificate
-	2018/03/16, 15:52 UTC: DigiCert contacted ABB requiring revocation
-	2018/03/16, 19:21 UTC: ABB revoked the certificate using a web console operating locally in IST (UTC+4.5) that submitted the revocation to the CA system using a revocation effective date that accounted for the time zone difference, and then the CA system also accounted for this time difference and produced a CRL entry with a 2018-03-16 14:51 UTC time. The revocation occurred at 19:21 UTC, just over six hours after awareness of the need to revoke.

3.	Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

ABB has stopped issuing certificates as of 2018/03/19.

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.
One problem certificate was created on 2018/03/15:

One problem certificate was created on 2018/03/15:
https://crt.sh/?q=565E431800200E427F55A48013D29D45B51DF681D6737CF927CC93996E242A13

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.

https://crt.sh/?q=565E431800200E427F55A48013D29D45B51DF681D6737CF927CC93996E242A13

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

ABB was not aware of the lifespan rule change. DigiCert requires subCAs to monitor improvements implemented by the CABF, and that was not the case for this incident.

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.

This issue was lack of communication from us to our subCAs and the expectation that subCAs were actively monitoring policy change as required by contract. ABB did not willfully violate a requirement. DigiCert has sent reinforcing notices to all subCAs stressing the importance of this change and all changes created by the CABF and/or browser policy improvements. Our subCA policy retains the right to stop issuance privilege in cases of non-compliance. ABB are complying with our enforcement by moving to a service we manage, and has ceased their own issuance.
We previously adopted a policy to move all external TLS issuance into our managed services. We are actively addressing geographic data privacy concerns that cause issuance from customer premises, with the near future intent to leave zero objections to moving to operations we manage with organization and domain validation performed by our own audited validation staff. Acknowledging our communication issue, and while we manage this migration, we are implementing mandatory recurring discussions with each owner of an external subCA. These sessions will not only clear the obstacles to migration, but also confirm awareness and planned compliance with changes initiated by CABF and browser policy. Our resolution is more direct and frequent contact with external subCAs than prior to this event.

Comment 1

[Wayne Thayer]

Brenda: thank you for the incident report.

With no technical controls in place to detect or prevent this type of issue, what assurance is there that it won't happen again?

What is the timeline for ABB completing the move to the managed CA service? Has it been completed and their legacy system configured to prevent further issuance?

Comment 2

[Brenda Bernal]

(In reply to Wayne Thayer [:wayne] from comment #1)
> Brenda: thank you for the incident report.

You're most welcome.
> 
> With no technical controls in place to detect or prevent this type of issue,
> what assurance is there that it won't happen again?
> 
 
ABB has stated and will be required to send proof that all certificate templates were disabled in their issuing system on 2018-03-19. This technical control prevents issuance of any kind. To prevent re-enablement of templates, DigiCert is completing an amendment to the agreement for the subCA service that stops further issuance with penalty of revocation and the resulting damage to active systems migrating to certificates from the managed service. This control creates great consequence for issuing.
 
SubCAs were provided notice of policy compliance that they SHALL comply with all Applicable Requirements (Final Guidelines adopted by the CA/Browser Forum, WebTrust Requirements, Mozilla Root Store Policy (including the Common CA Database Policy), Microsoft Root Store Policy, the US Federal PKI Policy, the DigiCert Certificate Policy, and other similar industry-wide standards).  Failure to comply with Applicable Requirements for any Publicly Trusted SubCA MAY result in immediate revocation at DigiCert’s sole discretion.
 
> What is the timeline for ABB completing the move to the managed CA service?
> Has it been completed and their legacy system configured to prevent further
> issuance?

ABB has an active and validated account in our managed service as of March 28, 2018.  The current contract amendment sent to ABB reflects agreement for no new issuance off their OmniRoot Services platform.

Comment 3

[Wayne Thayer]

Actions completed, resolving.