Closed Bug 1769240 Opened 3 years ago Closed 3 years ago

Firmaprofesional: 2022 - SSL certificates issued with wrong Organization ID number

Categories

(CA Program :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mprieto, Assigned: mprieto)

Details

(Whiteboard: [ca-compliance] [ev-misissuance] [ov-misissuance])

Steps to reproduce:

1.3.6.1.4.1.13177.10.1.20.2 (QCP-w): It has been detected that two certificates had an incorrect Organization ID number, not corresponding with the number of registration as it appears in the official records.

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.
It is a finding identified during the annual eIDAS/ETSI audit being carried out these days.

Actual results:

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.
On 2022-05-10 (CEST):
10:15: During the annual eIDAS audit, the information appearing in the two Certificates was discovered to be inaccurate.

The evidence collected by the Operator was analyzed and it is verified that it was correct. However, when transcribing the organization's identification numbers, due to human error, the first digit was not copied.

11:30: Then, the rest of the SSL certificates issued were analyzed in case the same error had occurred in other certificates. A third certificate was identified with the same error.

13:00 Firmaprofesional was able to contact and inform the client of the first two certificates found, and informed them about the need of revoking the certificates within a maximum of 5 days.

Firmaprofesional internally analyzed the root cause of the problem and determined that it was a human error (typo) introducing the information. Additional technical controls could minimize the risk of repeating the error.

On 2022-05-12: Firmaprofesional received acknowledgement from that client that they were ready for revocation

18:00: Firmaprofesional revokes the first two certificates.
18:40: Firmaprofesional opens a JIRA ticket to define user story and functional analysis to develop automated checks

On 2022-05-15:

Firmaprofesional will revoke the third certificate, to comply with the 5 days window, despite the fact that the client did not have acknowledged if he already had a new certificate in place.

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.

The rest of the SSL certificates issued were analyzed in case the same error had occurred in other certificates. It was verified that there are only these 3 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.
Three affected certificates:

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.
See above.

Expected results:

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

See point 1.2.
Additionally, it is a mistake that lints can not detect, at least as far as we know.

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.

On 2022-05-12 Firmaprofesional opened a JIRA ticket to develop an automated check.
In 2 weeks a first version of the automated checks shall be in production.

The third certificate has already been revoked

Assignee: bwilson → mprieto
Status: UNCONFIRMED → ASSIGNED
Type: defect → task
Ever confirmed: true
Whiteboard: [ca-compliance]

The technical control of the Organization Identification Number field has already been uploaded to PRE. We are testing the effectiveness of the control.
Next week it will go into PRO.

The technical control of the Organization Identification Number field has already been uploaded to PRE. We are testing the effectiveness of the control.
Next week it will go into PRO.

The technical control of the Organization Identification Number field has already been uploaded to PRODUCTION.
In our opinion, this action solves the root cause of the problem and it is effective.

Flags: needinfo?(bwilson)

I don't see where it was explained "how" these certificates had the wrong organization ID number. Was it human error or something wrong with code?

I don't see where it was explained "how" these certificates had the wrong organization ID number. Was it human error or something wrong with code?

Dear Ben: In point 2 when it was opened this bug we writed: The evidence collected by the Operator was analyzed and it is verified that it was correct. However, when transcribing the organization's identification numbers, due to human error, the first digit was not copied.

All planned actions to fix this bug have been performed.
Please, Could this bug be closed?

I'll close this on or about Friday, 17-June-2022.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [ev-misissuance] [ov-misissuance]
You need to log in before you can comment on or make changes to this bug.