1597948 - Sectigo: CCADB failed ALV - D-TRUST CA 2-1 2015

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Robin Alden]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36

Actual results:

Kathleen's email alerted us to the recent 'Failed ALV results' report in CCADB.
This indicated that we had a total of 9 Intermediate CA Certificates with Failed ALV Results.
This bug addresses 1 of those 9:

D-TRUST CA 2-1 2015
https://crt.sh/?id=12729288

This CA certificate is under audit, but the audit report does not include the SHA-256 thumbprint. A new Audit Attestation is being prepared which will include the SHA-256 thumbprint. The expected delivery date of this is during the first half of December.

Comment 1

[Robin Alden]

We apologize for the delay in our response.

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.

Kathleen sent an email to all CAs on the mozilla-dev-security-policy list at 08/OCT/2019 20:50 BST, entitled
"Audit Letter Validation (ALV) on intermediate certs in CCADB"
https://www.mail-archive.com/[e-mail]/msg12730.html

The email pointed out a new summary item in the CCADB home page for CAs that listed (for Sectigo):
"Intermediate Certs with Failed ALV Results: 9"

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.

23 June 2017 Mozilla published version 2.5 of its Root Store Policy, which specified in section 3.1.4 that audit statements must contain the SHA256 fingerprint of each root and intermediate certificate that was in scope of the audit.

30 November 2018 D-Trust's audit report [1] was issued.
Sectigo did not verify that the audit report complied with section 3.1.4 of Mozilla's policy.

Kathleen sent a number of follow-up emails on the same thread, expanding and clarifying the ALV issues and Mozilla's requirements on 10th, 15th, 29th October.

On 9th October 2019 we started evaluating options to fix the failed ALV results.

Although the CA was included in the audit statement registered for it in CCADB there were two issues with the audit report:
a) The registered audit report was the version in the German language instead of being the English language version as Mozilla's policy required
b) The audit report included the certificate serial number but not the SHA-256 hash

18th November 2019 we emailed D-Trust explaining the issue.
19th November 2019 we received a reply from D-Trust indicating that a new Audit Attestation would be available in mid December.
16th December 2019 we received the new Audit Attestation from D-Trust
2nd January 2020 we posted the new Audit Attestation [2] to CCADB.

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.

NA

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 CA certificate issued on 25 June 2015

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/?id=12729288

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

When Sectigo received its own WebTrust audit report in June 2018 our auditors correctly included SHA-256 hashes over each CA certificate, but we failed to check for the presence of SHA-256 hashes in the report presented to us by D-Trust.

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.

In future we will more diligently check audit reports presented to us for compliance with Mozilla's policy. The CCADB's automatic Audit Letter Validation (ALV) tool will be a valuable aid to this checking.

[1] https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/67118UE_s.pdf

[2] https://www.tuvit.de/fileadmin/Content/TUV_IT/zertifikate/en/AA2019120304_Comodo_RSA_Certification_Authority_V1.0_s.pdf

Comment 2

[Ben Wilson]

According to the CCADB, the D-TRUST CA 2-1 2015 passed the ALV check in January based on an updated audit report from TuvIT dated 2019-12-03 which listed the SHA2 hash of the certificate that matches the SHA2 hash for the D-TRUST CA 2-1 2015. The incident report adequately explains the remediation steps taken by Sectigo. Therefore, I am closing this bug.