2054450 - Firmaprofesional: Chrome Root Program Policy - Incorrect CCADB hierarchy associations

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Chema]

Preliminary Incident Report

Summary

• Incident description: On 2026-07-10 at 15:23 UTC, the Chrome Root Program notified Firmaprofesional that four unexpired and unrevoked subordinate CA certificates were improperly disclosed in CCADB because their records were associated only with the 2009 self-signed root certificate record and were not associated with the Chrome-included 2014 root certificate record, even though the 2009 and 2014 root certificates share the same Subject and SPKI. The four certificates identified by Chrome were:

  1. AC Firmaprofesional - OTC 2020.
  2. AC Firmaprofesional - CA1.
  3. AC Firmaprofesional - Timestamp 2021.
  4. AC Firmaprofesional - CFEA 2020.

  During the resulting reconciliation, Firmaprofesional identified three additional unexpired and unrevoked subordinate CA certificates in the same situation:

  5. AC Firmaprofesional - CUALIFICADOS (4CCF17C0…3741E74F).
  6. AC Firmaprofesional - CUALIFICADOS (2B75CC4F…FF2960CF).
  7. SIGNE Autoridad de Certificacion - 2020 (B8DF384F1FCD6ECB3F4D7DD6380E54D354C61256560A599D80453247D93AF5EA).

  The known impact at the time of this preliminary report is therefore seven CCADB subordinate CA records: the four identified by the Chrome Root Program and the three additional records identified during Firmaprofesional's internal reconciliation. CCADB rejects the creation of a second Intermediate Certificate record with the same SHA-256 fingerprint as a duplicate. On 2026-07-10, Firmaprofesional applied provisional remediation by updating the Parent CA Owner/Certificate field of the seven existing unique records so that they are associated with the 2014 root record (0011J00001MknHQQAZ). The broader CCADB corpus review remains in progress. Firmaprofesional has also requested confirmation from the Chrome Root Program that this re-association is the CCADB representation expected when it referred to the certificates being “also disclosed” beneath the 2014 root. The incident therefore remains under investigation pending completion of the corpus review and confirmation of the expected representation.

• Relevant policies:

  • CCADB Policy, version 2.1, Section 1, “General Provisions”, requiring CA Owners to keep information about their certificates accurate and up to date.
  • CCADB Policy, version 2.1, Section 3.2, “Subordinate CA Certificates”, requiring disclosure of all subordinate CA certificates capable of validating to a certificate included in a Root Store.
  • Chrome Root Program Policy, version 1.8, Section 1.1.2, “Common CA Database”.
  • Chrome Root Program Policy, version 1.8, Sections 1.5 and 1.5.1, “Reporting and Responding to Incidents” and “Incident Reports”.

• Source of incident disclosure: Third Party Reported (Chrome Root Program). Firmaprofesional's internal reconciliation expanded the initially reported scope from four to seven affected CCADB records by identifying both AC Firmaprofesional - CUALIFICADOS certificates and SIGNE Autoridad de Certificacion - 2020 as three additional records with the same incorrect parent association.

Comment 1

[Chema]

Status Update

Our investigation and preparation of the Full Incident Report remain in progress.

Since publication of the Preliminary Incident Report, we have continued reviewing the affected CCADB hierarchy associations, the incident timeline, Root Cause Analysis, remediation plan, and certificate appendix. Current-state verification of the seven known affected Intermediate Certificate records has confirmed that they are now associated with the 2014 root certificate. No additional affected records have been identified beyond the seven disclosed in the Preliminary Incident Report.

Final validation of the scope and supporting evidence is still in progress, including whether additional CCADB history is available for the original parent associations and the 2026-07-10 parent-field updates.

We will publish the Full Incident Report no later than 2026-07-27 11:16 UTC, or earlier if the remaining review is completed sooner. We will report any material change before that time.

We request that the Bugzilla Whiteboard Next update field be set to 2026-07-27.

Comment 2

[Chema]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000006.
• Incident description: On 2026-07-10 at 15:23 UTC, the Chrome Root Program notified Firmaprofesional that four unexpired and unrevoked subordinate CA certificate records were associated in CCADB only with the 2009 self-signed root certificate record and not with the Chrome-included 2014 root certificate record. The 2009 root is signed using SHA-1 and the modified 2014 root is signed using SHA-256; they are distinct certificates with different fingerprints but share the same Subject and SPKI, so the same subordinate CA certificates can validate to both roots. Firmaprofesional's reconciliation identified three additional records in the same condition, establishing a total scope of seven records. CCADB would not allow the same subordinate certificate to be added beneath the 2014 root because it enforces one Intermediate Certificate record per SHA-256 certificate fingerprint. Firmaprofesional therefore changed the Parent CA Owner/Certificate field on the seven existing unique records to the 2014 root. Chrome independently reproduced and agreed with this CCADB limitation. Subject to no disagreement from other CCADB-participating Root Store Operators, Chrome stated that it would recommend not blocking closure of this incident on a CCADB system change to permit duplicate disclosure. Chrome nevertheless clarified that new subordinate CA disclosures made after creation of the modified 2014 root record should originally have been made beneath that record rather than beneath the 2009 root record.
• Timeline summary:
  • Non-compliance start date: Undetermined and not reconstructable from the evidence available to Firmaprofesional. The public CCADB reports and authenticated CA Community record views expose the current parent association but not the record creation date, historical parent values, field-change timestamps, or changing actor. Firmaprofesional therefore cannot establish a verifiable start date for each record and will not substitute a certificate issuance date or an estimated date.
  • Non-compliance identified date: 2026-07-10 15:23 UTC for the four records reported by Chrome. Firmaprofesional identified the other three records on 2026-07-10.
  • Non-compliance end date: 2026-07-10. Firmaprofesional changed the parent association of all seven records to the 2014 root on that date.
• Relevant policies:
  • CCADB Policy version 2.1, Section 1, requiring CA Owners to keep information about their certificates accurate and up to date.
  • CCADB Policy version 2.1, Section 3.2, requiring disclosure of subordinate CA certificates capable of validating to a certificate included in a Root Store.
  • Chrome Root Program Policy version 1.8, Section 1.1.2, "Common CA Database".
  • Chrome Root Program Policy version 1.8, Sections 1.5, 1.5.1, and 1.5.2, concerning incident reporting and response.
  • CCADB Incident Reporting Guidelines version 3.2.
• Source of incident disclosure: Third Party Reported - Chrome Root Program. Firmaprofesional's internal reconciliation expanded the initially identified scope from four records to the final total of seven records.

Impact

• Total number of certificates: 7 subordinate CA certificate records. The full CCADB hierarchy review confirmed that there are no additional affected records.
• Total number of "remaining valid" certificates: 7 at the incident-awareness time. On 2026-07-17 at 16:27 UTC, all seven were verified in the public CCADB V5 report as Not Revoked and within their validity periods.
• Affected certificate types: Subordinate CA certificates and their CCADB hierarchy metadata. The issue is the CCADB parent association for subordinate CA records capable of validating to the Chrome-included 2014 root that shares Subject and SPKI with the 2009 root, not the contents of subscriber certificates.
• Incident heuristic: The affected corpus consists of seven unexpired and unrevoked subordinate CA certificates that can validate to two distinct self-signed root certificates sharing the same Subject and SPKI: the SHA-1-signed 2009 root and the SHA-256-signed 2014 root. Their single CCADB Intermediate Certificate records were associated with the 2009 root rather than the Chrome-included 2014 root. Firmaprofesional's review found no additional records requiring corrected CCADB parent association.
• Was issuance stopped in response to this incident, and why or why not?: No issuance was stopped specifically in response to this metadata incident. The identified non-compliance concerns CCADB hierarchy association data rather than issuance from the affected subordinate CA certificates. Separate issuance and browser-trust issues arising from the same Chrome notification are tracked in Bug 2054448.
• Analysis: The seven subordinate certificates each have one SHA-256 fingerprint and one unique Intermediate Certificate record in CCADB. Because CCADB rejects a second record with the same fingerprint, it cannot represent the same subordinate certificate simultaneously beneath both same-key root records by duplicating the Intermediate Certificate record. This constraint is material for subordinate records that predate the modified 2014 root and cannot have been originally created beneath it. Chrome reproduced the behavior in the CCADB Sandbox and agreed with Firmaprofesional's conclusion. Chrome also stated that it did not consider a CCADB code change to be a necessary closure dependency, subject to no disagreement from other participating Root Store Operators. This did not remove Chrome's separate expectation for record placement: disclosures newly created after the modified 2014 root record should have selected the 2014 parent rather than the 2009 parent. On 2026-07-18, Firmaprofesional verified the current authenticated CCADB CA Community submission workflow. The PEM submission form does not present a parent selector or display the selected parent. Instead, the parent is determined implicitly by the root record from which the New Intermediate Cert action is initiated. Because the 2009 and 2014 root records have the same displayed certificate name, the form does not itself provide an explicit confirmation distinguishing the roots. The root detail pages can be distinguished by their certificate fingerprints and Root Store inclusion status; therefore, this interface behavior increases the likelihood of an incorrect parent association but does not make correct placement technically impossible. The available CCADB views do not provide record creation dates or historical parent values, so Firmaprofesional cannot retrospectively determine the precise start date of the metadata condition for each record or verify that the historical submission interface behaved identically. On 2026-07-17 16:27 UTC, Firmaprofesional verified the public CCADB V5 All Certificate Information report for all seven affected fingerprints. Every record was present, its Parent SHA-256 Fingerprint was 57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A, the 2014 root showed Google Chrome: Included, and every subordinate record showed Revocation Status = Not Revoked. The broader corpus review found no additional affected records.
• Additional considerations: Chrome's response means that closure should not depend on CCADB being changed to support duplicate Intermediate Certificate records, subject to its stated condition regarding other participating Root Store Operators. It does not mean that Chrome withdrew the incident or its expectation that new disclosures after creation of the modified 2014 root should have been placed beneath that root. Chrome did not request an additional immediate technical action in its follow-up response beyond the incident handling already underway.

Timeline

• 2009-05-20 - The SHA-1-signed 2009 self-signed root certificate Autoridad de Certificacion Firmaprofesional CIF A62634068, SHA-256 fingerprint 04048028BF1F2864D48F9AD4D83294366A828856553F3B14303F90147F5D40EF, became valid. The public CCADB V5 report currently shows Apple: Included; Google Chrome: Not Included; Microsoft: Included; Mozilla: Removed.
• 2014-09-23 - The SHA-256-signed modified self-signed root certificate with the same Subject and SPKI, SHA-256 fingerprint 57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A, became valid. The public CCADB V5 report currently shows Apple: Not Included; Google Chrome: Included; Microsoft: Included; Mozilla: Included.
• 2009-08-25 to 2021-04-13 - The seven affected subordinate CA certificates became valid on the dates listed in the Appendix. Two have Valid From dates before the modified 2014 root became valid and five have later Valid From dates. These dates are not used as CCADB disclosure dates. The public and authenticated CCADB views do not expose the original record creation timestamps, historical parent values, or parent-change timestamps; consequently, a per-record non-compliance start date cannot be reconstructed from verifiable CCADB data.
• 2026-07-10 15:23 UTC - Firmaprofesional received Chrome's notification. This is the incident-awareness time for the four externally reported records.
• 2026-07-10 - Firmaprofesional's internal reconciliation identified three additional affected records: both AC Firmaprofesional - CUALIFICADOS certificates and SIGNE Autoridad de Certificacion - 2020. No exact UTC time is stated because no verifiable audit record is available.
• 2026-07-10 - Firmaprofesional changed the Parent CA Owner/Certificate field on all seven existing unique records to the 2014 root certificate, SHA-256 57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A. The exact time and per-record sequence cannot be independently reconstructed because the available CCADB public and authenticated views do not expose the relevant audit history.
• 2026-07-11 13:32 UTC - Firmaprofesional responded to Chrome, reported the additional SIGNE certificate, corrected the EKU characterization of OTC 2020 and CFEA 2020 for the related Bug 2054448, described the CCADB reconciliation, and requested confirmation that updating the existing unique records was the expected CCADB representation.
• 2026-07-13 11:16 UTC - Firmaprofesional published the Preliminary Incident Report in Bug 2054450.
• 2026-07-13 20:37 UTC - Chrome acknowledged Bugs 2054448 and 2054450, confirmed the CCADB duplicate-record limitation, stated its conditional position that Bug 2054450 should not be blocked on a CCADB code change, and clarified that subordinate CA disclosures made after creation of the modified 2014 root record should have been made beneath that 2014 root record.
• 2026-07-17 16:27 UTC - Firmaprofesional verified the public CCADB V5 All Certificate Information report for the seven affected SHA-256 fingerprints. All seven records were present, associated with parent SHA-256 57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A, and marked Not Revoked.
• 2026-07-18 - Firmaprofesional reviewed the current authenticated CCADB CA Community intermediate-certificate submission workflow. The PEM submission form did not display or allow direct selection of the parent root. The parent was supplied implicitly by the root record from which New Intermediate Cert was initiated. The two relevant root records displayed the same certificate name but could be distinguished on their detail pages by fingerprint and Root Store inclusion status. No record was created or modified during this verification.

Related Incidents

Firmaprofesional reviewed public Bugzilla incidents from other CA operators concerning CCADB subordinate CA disclosure, hierarchy metadata accuracy, cross-certification controls, and CCADB disclosure completeness. We haven't find equivalent Incidents but, still, we've reviewed the followign. Bug 1904041 is included as a close public analogue slightly outside the two-year window.

Bug	Date opened or published	Description
1904041	2024-06-21	NETLOCK reported intermediate CA certificates not disclosed to CCADB. The incident is relevant to timely and complete CCADB subordinate CA disclosure controls and verification after third-party detection.
1982646	2025-08-12	Actalis reported missing CCADB disclosure for a newly created SubCA and related cross-certification scenario. The incident is relevant to recognizing when a trust-path or cross-certificate change makes additional subordinate CA disclosures required.
2007116	2025-12-18	D-Trust reported inaccurate CRL URL metadata in CCADB Intermediate CA certificate records. The incident is relevant to controls that compare CCADB metadata against certificate contents and correct metadata discrepancies promptly after detection.
2007089	2025-12-19	SHECA reported subordinate CA CRL URL disclosure gaps in CCADB. The incident is relevant to ensuring that subordinate CA records in CCADB contain complete and accurate disclosure data for certificates in scope.

Root Cause Analysis

Firmaprofesional does not identify the CCADB duplicate-record behavior or CCADB interface design as remediation items that Firmaprofesional can directly change. Those constraints are described in this report because they affected the available remediation path and the controls needed in Firmaprofesional's procedures.

Root Cause #1: The disclosure process did not define or independently verify which same-key root record should be selected as parent for new subordinate CA disclosures

• Description: For subordinate CA disclosures created after the modified 2014 root record, Firmaprofesional's process did not require selection of the root record based on its full certificate fingerprint, Root Store inclusion state, and the effective browser trust path, followed by verification of the resulting parent fingerprint. Chrome stated that those new disclosures should have been made beneath the 2014 root rather than the 2009 root. The current CCADB workflow makes the parent selection implicit in the root record from which the submission is initiated rather than exposing it as a field in the PEM form.
• Timeline: The exact start date cannot be reconstructed because the available CCADB views do not expose the creation date or historical parent association of each Intermediate Certificate record, or at leats we haven't been bale to fnd them.
• Detection: Chrome reported four records on 2026-07-10 at 15:23 UTC. Firmaprofesional identified three further records during the response on the same date.
• Interaction with other factors: The shared Subject and SPKI made the roots appear interchangeable at the certificate-validation level, while CCADB required a single parent record. Because CCADB rejects duplicate Intermediate Certificate records with the same subordinate certificate SHA-256 fingerprint, Firmaprofesional's remediation was to change the single existing parent association to the Chrome-included 2014 root. Without a procedure tied to Root Store inclusion, fingerprint-based root selection, and post-submission verification, records could remain associated with the older root.
• Root Cause Analysis methodology used: Process gap analysis against Chrome's clarified expectation for post-2014 disclosures.

Lessons Learned

• What went well:
  • Firmaprofesional did not limit the review to Chrome's four initially reported records and identified three additional records in the same condition.
  • Firmaprofesional updated the parent association of the seven existing records on 2026-07-10 and asked Chrome to confirm the expected CCADB representation.
  • Chrome independently reproduced the duplicate-record behavior and stated that closure should not be blocked on a CCADB system update, subject to no disagreement from other participating Root Store Operators.
• What didn't go well:
  • Firmaprofesional's procedure did not specify how to select the parent for new disclosures when two distinct root certificates shared Subject and SPKI.
  • The review process did not require the single parent association to be checked against Root Store inclusion state and the effective browser-trusted path.
  • Firmaprofesional did not detect the issue through a recurring internal CCADB corpus reconciliation before Chrome's notification.
  • CCADB's available public and authenticated views do not provide verifiable record creation dates or parent-field audit history, making the per-record start dates and exact remediation times impossible to reconstruct from the available evidence.
• Where we got lucky:
  • CCADB's duplicate-record behavior could be reproduced and explained quickly, reducing ambiguity about whether duplicate Intermediate Certificate records were technically possible.
  • Firmaprofesional identified three additional records during the first response cycle rather than after publication of the preliminary report.
• Additional: CCADB metadata accuracy must be verified as a representation of the effective trust graph, not only as a unique inventory of certificate fingerprints. Where CCADB permits only one parent, Firmaprofesional's procedure must require selection of the parent record that corresponds to the applicable Root Store disclosure expectation.

Action Items

The following commitments address Root Cause #1 and the controls needed to prevent or detect recurrence.

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Document the CCADB historical-evidence boundary and retain the verified current-state evidence for the seven records	Detect/Mitigate	Root Cause #1	Evidence identifies the CCADB fields that were verified, the historical fields not exposed in the available public and authenticated views, and the reason no exact start or change time is asserted; current parent state for all seven records is retained	2026-07-17	Complete
Document and retain evidence of the completed full CCADB corpus review for same-Subject/SPKI roots, cross-certification, and multi-parent cases	Detect	Root Cause #1	Review evidence covers all CA certificates in scope and confirms that no additional affected records exist beyond the seven listed in this report	2026-07-20	Complete
Update the CCADB disclosure procedure for same-key or otherwise ambiguous root relationships. Require the operator to open the intended root record by full SHA-256 fingerprint, verify its Root Store inclusion state before initiating New Intermediate Cert, and verify the resulting Parent SHA-256 Fingerprint after creation or update	Prevent	Root Cause #1	The approved procedure requires fingerprint-based root selection, Root Store inclusion-state verification, post-creation or post-update parent verification, and independent review for new or changed subordinate CA disclosures	2026-08-15	Ongoing

We request that the Bugzilla Whiteboard Next update field be set to 2026-08-15, aligned with the due date of the remaining open Action Item.

Appendix

The complete affected corpus of seven certificates is listed below. The Parent before remediation value reflects the condition described in Chrome's notification and Firmaprofesional's preliminary report. The Parent after remediation value was verified against the public CCADB V5 All Certificate Information report on 2026-07-17 at 16:27 UTC.

#	CA certificate	Serial number	Validity	SHA-256 fingerprint	Parent before remediation	Parent after remediation	Status at awareness
1	AC Firmaprofesional - OTC 2020	330478E03741E36995159A82B1996E96	2020-07-30 09:17 UTC to 2030-12-31 04:02 UTC	2E60F867E8887CE218059E85403F3613D28DA9EF658874D0C6F9FF25F2DDB6E5	2009 root SHA-256 04048028BF1F2864D48F9AD4D83294366A828856553F3B14303F90147F5D40EF	2014 root SHA-256 57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A	Unexpired and unrevoked
2	AC Firmaprofesional - CA1	533015E09A9EB866	2009-08-25 10:05 UTC to 2030-06-16 10:05 UTC	0EBBDF146E63F70FAA5927EE8E5346E9C96C5F0D9BDD3212B04ED6687179874D	2009 root SHA-256 04048028BF1F2864D48F9AD4D83294366A828856553F3B14303F90147F5D40EF	2014 root SHA-256 57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A	Unexpired and unrevoked
3	AC Firmaprofesional - Timestamp 2021	08A9744596640672CDD227C2621607C4	2021-04-13 09:32 UTC to 2030-12-31 04:02 UTC	75B14D4D63806F30F538060F2EB65C1365BFC0CD7F3ECDC6C0070218B6E46759	2009 root SHA-256 04048028BF1F2864D48F9AD4D83294366A828856553F3B14303F90147F5D40EF	2014 root SHA-256 57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A	Unexpired and unrevoked
4	AC Firmaprofesional - CFEA 2020	137814F80E61E1F3C8412DD335D01F77	2020-07-30 09:11 UTC to 2030-12-31 04:02 UTC	3F4E45A8508BF83137F966AC961EF45AF573F25AA14D83C2A7F23B80A831C93C	2009 root SHA-256 04048028BF1F2864D48F9AD4D83294366A828856553F3B14303F90147F5D40EF	2014 root SHA-256 57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A	Unexpired and unrevoked
5	AC Firmaprofesional - CUALIFICADOS	7DB68BA268505737	2018-12-14 10:13 UTC to 2030-12-31 04:02 UTC	4CCF17C0C8C1C10D5876EC5E3280FE8D134DF36AEDD8444289B990BC3741E74F	2009 root SHA-256 04048028BF1F2864D48F9AD4D83294366A828856553F3B14303F90147F5D40EF	2014 root SHA-256 57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A	Unexpired and unrevoked
6	AC Firmaprofesional - CUALIFICADOS	0D0366455E6E29D4	2014-09-18 10:00 UTC to 2030-12-31 04:02 UTC	2B75CC4F36759CFC4C6637B1E0E54359457DB57E74DE4D2DC5D02CDDFF2960CF	2009 root SHA-256 04048028BF1F2864D48F9AD4D83294366A828856553F3B14303F90147F5D40EF	2014 root SHA-256 57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A	Unexpired and unrevoked
7	SIGNE Autoridad de Certificacion - 2020	547B28543C3112C972B6F2915F231875	2020-07-30 09:26 UTC to 2030-12-31 04:02 UTC	B8DF384F1FCD6ECB3F4D7DD6380E54D354C61256560A599D80453247D93AF5EA	2009 root SHA-256 04048028BF1F2864D48F9AD4D83294366A828856553F3B14303F90147F5D40EF	2014 root SHA-256 57DE0583EFD2B26E0361DA99DA9DF4648DEF7EE8441C3B728AFA9BCDE0F9B26A	Unexpired and unrevoked

The complete affected corpus of seven certificates is also provided in the supporting CSV, Affected certificates.csv, using the standard field order required by the CCADB Incident Reporting Guidelines version 3.2. The precertificate hash and dNSNames fields are reported as N/A for these subordinate CA certificates. Because the certificates are unrevoked and revocation is neither planned nor delayed, the Is revoked? field is reported as No and the revocation date and reason as N/A.

Comment 3

[Chema]

Attachment: Affected certificates.csv

Comment 4

[Chema]

Status Update

Work on the remaining open Action Item described in the Full Incident Report remains in progress.

The Full Incident Report and the supporting Affected certificates.csv attachment were published on 2026-07-24. There are no material changes to report at this time.

We reiterate our request that the Bugzilla Whiteboard Next update date be set to 2026-08-15, aligned with the due date of the remaining open Action Item. We will provide an earlier update if the Action Item is changed, completed, or delayed.

Comment 5

[Javier Manzano]

Status Update

The remaining Action Item described in the Full Incident Report, with a published due date of 2026-08-15, has been completed.

The approved CCADB disclosure procedure now requires:

• Selection of the intended root record using its full SHA-256 fingerprint
• Verification of the root's applicable Root Store inclusion state before initiating New Intermediate Cert
• Verification of the resulting Parent SHA-256 Fingerprint after a new or updated subordinate CA disclosure
• Independent review of new or changed subordinate CA disclosures

All Action Items disclosed in the Full Incident Report are now complete.

Comment 6

[Javier Manzano]

Report Closure Summary

• Incident description: Seven subordinate CA certificate records capable of validating to both the 2009 and Chrome-included 2014 Firmaprofesional root certificates were associated in CCADB only with the 2009 root record. Firmaprofesional updated the seven existing unique records so that they are associated with the 2014 root record.
• Incident Root Cause(s): The CCADB disclosure process did not define or independently verify which same-key root record should be selected as parent for new subordinate CA disclosures. The process did not require selection by full certificate fingerprint and Root Store inclusion state or verification of the resulting parent fingerprint.
• Remediation description: Firmaprofesional retained the verified current-state evidence and documented the limits of the historical evidence available from CCADB, completed a full corpus review that identified no additional affected records, and updated the CCADB disclosure procedure. The procedure now requires selection of the intended root by full SHA-256 fingerprint, verification of its applicable Root Store inclusion state, verification of the resulting Parent SHA-256 Fingerprint, and independent review of new or changed subordinate CA disclosures.
• Commitment summary: Firmaprofesional will maintain the updated fingerprint-based root-selection and verification controls for future new or changed subordinate CA disclosures. Current-state verification confirms that all seven affected records remain associated with the intended 2014 root record.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 7

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2026-09-01.