1464335 - Firmaprofesional: Undisclosed Intermediate certificate SIGNE

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[chemalogo]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180517113820

Steps to reproduce:

Look at https://crt.sh/mozilla-disclosures#disclosedbutincrl
or CCADB to seek for disclosed and not disclosed CAs


Actual results:

After the issuance of the technically constrained sha256withRSA SIGNE subordinate CA we did not disclose it into the CCADB.


Expected results:

We should have disclosed it.

Comment 1

[chemalogo]

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.

Bugzilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1455119
2018-04-18 14:04 PDT
 
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-04-19 06:40 PDT we had warnings about it was not needed to disclose such a CA certificate, since it was technically constrained.
2018-04-19 10:31 PDT: after clarifications on the previous step, we disclosed the CA

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.

As far as we are aware, all Subordinates CAs has been disclose. However, we continue working and updating our internal hierarchy procedures to add the disclosure as a step when issuing new CA certificates.

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.

https://crt.sh/?sha256=1cb470728cf56f302003bb0e4eb062414fa11d4f97e3f061170c96c88071d711&opt=mozilladisclosure

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.

crt.sh ID 	240192053

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

It was not procedured internally the disclosure of new CA certificates into the CCADB.

The internal procedure is being modified to include this step when a new CA certificate issuance occurs.

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.

We disclosed the affected certificate.

We are updating our internal hierarchy procedures to add the disclosure as a step when issuing new CA certificates.

Comment 2

[Stefan [:StefanG_QA]]

Based on other similar reports I think the correct component would be NSS::CA Certificate Mis-Issuance. Please change if this is not the right component.

Comment 3

[Wayne Thayer]

CCADB is being updated to properly detect intermediate certificates requiring disclosure based on the current disclosure requirements for email certificates.