1610000 - SSL.com: Intermediate certificate not listed in audit reports

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Thomas Zermeno]

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.

SSL.com became aware of this issue via observation of an ALV flag in CCADB (see:https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/M7NGwCh14DI)
As this flag appeared to be related to an active bug related to audit reporting of a cross-signed root by another CA, no immediate action was taken (https://bugzilla.mozilla.org/show_bug.cgi?id=1598277). As of November 21 2019 a review of the flag led to a deeper investigation.

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.

Nov 21 2019: ALV result reviewed, initial investigation suggested this was related to audit reporting issues due to crosssigning w/Asseco root (see: https://bugzilla.mozilla.org/show_bug.cgi?id=1598277 )
Nov 21-25 2019: Further research performed, determination made that issue stemmed from unsubmitted root.
Nov 26 2019: Request for guidance from MRSP. Initial recommendation from MRSP (add cert to CRL) considered fraught. Followup suggestion acceptable (update current audit report/include cert in all future reports).
Dec 4-10 2019: Conferred w/external auditors re: options. Carried auditor preference (inclusion in future reports only, no revision of current reports) to MRSP; however, revision of current reports stated as required by MRSP.
Jan 7 2019: Further guidance requested and received from MRSP regarding ALV compliance.
Jan 16 2019: Confirmation by external auditors that current audit report revision underway. Clarification requested and received from MRSP regarding incident reporting.
Jan 17 2019: Incident filed (this bug).

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.

This Root CA Certificate was not introduced as a Trust Anchor to Mozilla and is not in use.

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 Root CA Certificate is involved in this issue, issued April 6 2017.

**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.
Data may be found here: https://crt.sh/?q=89EFEB25096BA4CCD40AF4FB8756F0A4843995974822020914C4E859D932B7F3

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

The certificate in question was created on April 6 2017. A reissued certificate (using the same subject and SPKI) was created May 31 2017 in order to correct minor issues before submission to root programs. A CCADB record was created for each of these certificates. However, only the May certificate has been submitted to root programs, and issued certificates.
The ALV flag results from the treatment of the April certificate as an intermediate of the May certificate. As helpfully explained by a Mozilla representative:
"a valid chain may be constructed as: leaf --> untrusted root --> trusted root. In other words, that "untrusted" root is technically trusted by Mozilla because it chains to a trusted root. Weird, but true. Therefore the CA certificate in question is a trusted intermediate certificate that was not audited, in violation of Mozilla policy."
Our close reading of applicable policy did not suggest this outcome, based on definitions provided of intermediate and root certificates.

6. 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.

Since the "April" Certificate shares the same Name and SPKI as the "May" Certificate, the handling of the key material is the same and properly audited and reported (for the "May" Certificate).
Our external auditors (BDO) are revising the audit reports to include the "April" Certificate.
Once we have the updated audit reports, a new audit case will be submitted directing MRSP to revised audit reports.

Comment 1

[Thomas Zermeno]

Audit case 00000564 [1] has now been completed. This case resolves the ALV issue described above.

[1] https://ccadb.force.com/5001J00000rGSqC

Comment 2

[Wayne Thayer]

Confirmed that this issue is resolved via the updated audit statement.