Closed Bug 1596744 Opened 5 years ago Closed 4 years ago

Izenpe: CA certificates not listed in audit report

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: o-garcia, Assigned: o-garcia)

Details

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

  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.
    November, 14th -> We became aware of this problem by the CCADB Audit Letter Validation (ALV) 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.
    October 25 -> we logged into CCADB, but misinterpreted what this was about and postponed any further action. Asked Kathleen for clarifications by email the same day.
    November 14th -> based on recommendations from Kathleen and our internal discussions, we decide to prepare a plan to revoke all affected certificates.
  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.
    SHA2 version CA certificates were issued between 2007 and 2010, so all subscriber certificates issued by SHA1 version CAs are expired.
  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.
    SHA1 version of all subCA and root CA certificates of Izenpe
  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.
    Izenpe.com
    https://crt.sh/?id=13917
    CA Teknikoa - CA Tecnica
    https://crt.sh/?id=12724269
    Herritar eta Erakundeen CA - CA de Ciudadanos y Entidades (4)
    https://crt.sh/?id=9035578
    Herritar eta Erakundeen CA - CA de Ciudadanos y Entidades (3)
    https://crt.sh/?id=9035577
    Eusko Jaurlaritzako langileen CA - CA personal Gobierno Vasco
    https://crt.sh/?id=19353
    EAEko Herri Administrazioen CA - CA AAPP Vascas (2)
    https://crt.sh/?id=47051
    EAEko HAetako langileen CA - CA personal de AAPP vascas (2)
    https://crt.sh/?id=9035576
    CA de Certificados SSL EV
    https://crt.sh/?id=13918
  6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
    We were aware of the mistake looking at the ALV results, and comparing them with Kathleen explanations, where we saw that although all CA certificates were covered in the audit, SHA1 version CA certificates were not included in the report.
  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’re going to revoke all affected CAs. Some of these CAs issue certificates for natural and legal persons, and many of these certificates are used to sign. At this moment we need to analyse the impact of the revocation, especially in case of qualified certificates (according to eIDAS). Therefore, we’re preparing a plan for that revocation, based on the impact on our customers and the citizenship.
Assignee: wthayer → o-garcia
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: CA certificates not listed in audit report → Izenpe: CA certificates not listed in audit report
Whiteboard: [ca-compliance]

We have two different sets of subCAs:

a) subCAs issuing SSL/TLS certificates:

CA de Certificados SSL EV
https://crt.sh/?id=13918

EAEko Herri Administrazioen CA - CA AAPP Vascas (2)
https://crt.sh/?id=47051

Eusko Jaurlaritzako langileen CA - CA personal Gobierno Vasco
https://crt.sh/?id=19353

b) subCAs issuing non SSL/TLS certificates

CA Teknikoa - CA Tecnica
https://crt.sh/?id=12724269

Herritar eta Erakundeen CA - CA de Ciudadanos y Entidades (4)
https://crt.sh/?id=9035578

Herritar eta Erakundeen CA - CA de Ciudadanos y Entidades (3)
https://crt.sh/?id=9035577

EAEko HAetako langileen CA - CA personal de AAPP vascas (2)
https://crt.sh/?id=9035576

Three subCAs in the first group will be revoked next Friday 22th. In case of that second group, we're still analyzing the impact in our customers,
because the subscriber certificates are distributed to all citizens and entities in the Basque Country, and used to generate qualified signatures (many of them need to verify the subCA status to validate the signature).

Currently our best option would be to add them to OneCRL, according to the message published by Mozilla [1], and not to revoke them.

[1] https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/M7NGwCh14DI

Regards

Oscar: Thanks for reporting this.

Note, in line with https://groups.google.com/d/msg/mozilla.dev.security.policy/M7NGwCh14DI/9Go4rOTgBgAJ , Google expects that there is a clear plan for revocation, as that is the only path to bring these roots back in compliance with the Baseline Requirements, which requires revocation for CAs that are not appropriately audited. In line with the principles in https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation , we understand there may be exceptional situations, and it is up to the CA to establish the factors that a CA uses in determining their revocation timeline. Such an incident is still a BR violation, as with any violation of the requirements, but our response to violations is to build a holistic picture of how a CA addresses and resolves non-compliance, and how systemically, things can improve.

As similarly captured on that page, discussion with all root programs is recommended, as root programs do not and cannot grant exceptions to the BRs, merely address how they will handle violations of the BRs and root store requirements.

All subCAs issuing SSL/TLS certificates have been revoked:

CA de Certificados SSL EV
https://crt.sh/?id=13918

EAEko Herri Administrazioen CA - CA AAPP Vascas (2)
https://crt.sh/?id=47051

Eusko Jaurlaritzako langileen CA - CA personal Gobierno Vasco
https://crt.sh/?id=19353

Another bug (Bug 1598608) has been opened to notify the incident for not revoking the 4 pending subCAs within the BR defined time period

Complying with the defined timeline, all pending subCAs have been revoked:

CA Teknikoa - CA Tecnica
https://crt.sh/?id=12724269

Herritar eta Erakundeen CA - CA de Ciudadanos y Entidades (4)
https://crt.sh/?id=9035578

Herritar eta Erakundeen CA - CA de Ciudadanos y Entidades (3)
https://crt.sh/?id=9035577

EAEko HAetako langileen CA - CA personal de AAPP vascas (2)
https://crt.sh/?id=9035576

Flags: needinfo?(wthayer)

It appears that all questions have been answered and remediation is complete.

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