Closed Bug 1586115 Opened 5 years ago Closed 5 years ago

Firmaprofesional / SIGNE: No BR Audit for intermediate CA technically capable of issuing TLS certs

Categories

(CA Program :: CA Certificate Compliance, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kathleen.a.wilson, Assigned: chemalogo)

Details

(Whiteboard: [ca-compliance] [audit-failure])

There is no BR audit for the following subordinate CA of Firmaprofesional, but the subordinate CA is technically capable of issuing TLS certificates. This is a violation of section 8 of the CA/Browser Forum Baseline Requirements and of Mozilla's Root Store Policy.

Subject: CN=SIGNE Autoridad de Certificacion; O=SIGNE S.A.; C=ES
Issuer: CN=Autoridad de Certificacion Firmaprofesional CIF A62634068; C=ES
SHA-256 Fingerprint: 0431D736C77697A0310103C6F890BC41C3A3BB81128ADE8D3C3461B4028D4413

Per similar situations (e.g. Bug #1575125) the CA needs to provide an incident report about why there is a non-constrained subCA without the required audits.

I will indicate in CCADB that this cert should be added to OneCRL. Note that while this is currently considered sufficient for Mozilla, other root store operators may require actual revocation of this cert.

Reference:
https://cabforum.org/baseline-requirements-documents/
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits

Whiteboard: [ca-compliance] - Missing BR Audit

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.
On 2019-10-03 23:40 CET a bug was opened in Bugzilla in relation to this incident. We began to investigate about this issue from that moment.

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.
We still are carefully evaluating scenarios for the replacement of the certificates.

  • 2019-10-03 23:40 CET - identified the ongoing request of information in Bugzilla and started investigation about the requests.
  • 2019-10-04 16:00 CET - conclusion of investigation is that there is no BR Audit because SIGNE subCA with SHA-256 Fingerprint: 0431D736C77697A0310103C6F890BC41C3A3BB81128ADE8D3C3461B4028D4413 does not issue and has never issued any SSL or TLS certificates. Despite this, validations have been made confirming that it would be technically possible to issue this type of certificates.
  • 2019-10-04 18:30 CET - notified the company for which this Sub CA offers its services. A period begins to evaluate a revocation date of the Sub 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.
SSL certificates have never been issued in this Sub 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.
There is only one certificate affected: the one corresponding to the Sub 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 crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
https://crt.sh/?q=0431D736C77697A0310103C6F890BC41C3A3BB81128ADE8D3C3461B4028D4413

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The affected Sub CA was issued on 2010-07-21, when there were no restrictions about this kind of issuance of SSL certificates. This Sub CA has a SHA1 Signature Algorithm.
After that point, on 2015-07-29 a new Sub CA was issued but with a SHA256 Signature Algorithm. This SHA256 Sub CA was already issued with technical restrictions for avoiding SSL issuance. Previous SHA1 Sub CA was not revoked for compatibility reasons and because it was not mandatory at that time.

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.
The procedures to include the affected Sub CA in OneCRL will be initiated and it will be revoked.

The revocation of the certificate has been scheduled for 2019-10-22.

The certificate was revoked last October the 22nd, as planned.

I confirm that this cert has been revoked and will be added to OneCRL during our next batch of updates.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] - Missing BR Audit → [ca-compliance] [audit-failure]
Summary: Firmaprofesional / SIGNE: No BR Audit for subCA technically capable of issuing TLS certs → Firmaprofesional / SIGNE: No BR Audit for intermediate CA technically capable of issuing TLS certs
You need to log in before you can comment on or make changes to this bug.