Closed Bug 1596931 Opened 27 days ago Closed 10 days ago

DigiCert: Verizon CPS lacks problem reporting instructions


(NSS :: CA Certificate Compliance, task)

Not set


(Not tracked)



(Reporter: agwa-bugs, Assigned: jeremy.rowley)


(Whiteboard: [ca-compliance])

Per BR 4.9.3:

The CA SHALL publicly disclose the [problem reporting] instructions through a readily accessible online means and in section 1.5.2 of their CPS.

However, the CPS disclosed for does not contain problem reporting instructions in section 1.5.2:

Assignee: wthayer → jeremy.rowley
Ever confirmed: true
Whiteboard: [ca-compliance]

It contains the certificate problem report email in section 4.11 which specifies the email address as This is not the section required in the BRs so I'll investigate why the wrong section was used and report back. As always, anyone can email for any sub CA certificate that requires revocation or investigation as well since we are the root.

On Friday November 15th Verizon was alerted that Section 1.5.2 of its Cybertrust Certification Practice Statement (CPS) did not contain contact information for Certificate Authority support. As of Monday November 18th this issue has been resolved, and the revised CPS was published today (November 19th). Verizon takes the requirements of CPS seriously, and remains committed to full compliance with applicable standards.

Thank you for updating your CPS. What is your process for keeping the CPS up-to-date with the Baseline Requirements, what failed with that process, and what changes are you making to ensure that there won't be another failure in the future?

This page explains what Mozilla expects from CAs following a compliance incident:

Flags: needinfo?(stephane.mans)

We looked through our other sub CAs to verify compliance. We've asked two others to update their CPS to be more clear, although they do contain contact information. We've also scanned through CCADB and found other CAs that have this issue. We've sent them a notice to fix it.

We've been talking to Verizon and they should be shortly posting a real incident report .

Incident Report

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, a Bugzilla bug, or internal self-audit), and the time and date.

11/15/2019, 21:41(GMT): Andrew Ayer opened this Bugzilla to report issue with CA contact information.

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.

Creation of the BR 1596931: 11/15/2019 21:41 (GMT)
Digicert email to Verizon management: 11/15/2019 23:51 (GMT)
Verizon Acknowledgement of receipt: 11/16/2019 12:21 (GMT)
Verizon Internal review meeting & doc review: 11/16/2019 11:00 (GMT)
Verizon start corrections and review: 11/18/2019 06:00 (GMT)
Verizon Policy Authority Committee review: 11/18/2019 18:00 (GMT)
Verizon Published updated CPS, v5.15: 11/19/2019 08:06 (GMT)

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.

N/A. Verizon is not issuing certificates from this CA.

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.

N/A. Verizon is not issuing certificates from this CA.

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 IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

N/A. Verizon is not issuing certificates from this CA.

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

Verizon created their CPS based on RFC 3647, unfortunately this was missed that the BR’s had additional content over and above the RFC.

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.

Verizon has implemented an enhanced review process for CPS within the Policy Authority Committee. For any updates this will review the entirety of the CPS based on standards including BR’s and Mozilla policy rather than just focusing on the change to be implemented.

However there is not an expectation to update the CPS further prior to the shut down of the CA in January 2020

Wayne: I'm not sure whether you'd like an additional issue created for the DigiCert-management side of this (see Jeremy's Comment #4). I think that represents the more interesting question here. I can understand that Verizon management is focused on the shutdown next month, but based on Comment #4, it sounds like there were a total of three sub-CAs of DigiCert that escaped notice.

Jeremy: You can see I'm looking for some sort of detail. I think the only question is whether it's this bug or a new bug :)

Flags: needinfo?(stephane.mans) → needinfo?(wthayer)

re: Comment 4. The CAs sent notice were not DigiCert-controlled CAs. They are independent CAs in the root program.

We looked at all the DigiCert Sub CAs and didn't find any others that lacked contact information.

Gotcha. Thanks, I misread the following:

We've asked two others to update their CPS to be more clear, although they do contain contact information.

Which, in hindsight, made it clear it was fine :)

It appears that all questions have been answered and remediation is complete.

Closed: 10 days ago
Flags: needinfo?(wthayer)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.