Open Bug 2054448 Opened 1 month ago Updated 4 days ago

Firmaprofesional: Chrome Root Progam Policy - Dedicated TLS hierarchy / EKU requirements

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: clopez, Assigned: clopez, NeedInfo)

Details

(Whiteboard: Next update 2026-09-18 [ca-compliance])

Attachments

(1 file)

Affected certificates.csv
2.68 KB, text/csv
Details

Preliminary Incident Report

Summary

  • Incident description: On 2026-07-10 at 15:23 UTC, the Chrome Root Program notified Firmaprofesional that unexpired and unrevoked subordinate CA certificates capable of validating to the Chrome-included root certificate Autoridad de Certificacion Firmaprofesional CIF A62634068 do not meet the dedicated TLS server authentication hierarchy requirements of the Chrome Root Program Policy. Our initial review has confirmed seven affected subordinate CA certificates:

    1. AC Firmaprofesional - CUALIFICADOS (4CCF17C0…3741E74F) — no extendedKeyUsage extension.
    2. AC Firmaprofesional - CUALIFICADOS (2B75CC4F…FF2960CF) — no extendedKeyUsage extension.
    3. AC Firmaprofesional - OTC 2020 — id-kp-clientAuth, Microsoft Smart Card Logon, and 1.2.840.113583.1.1.5.
    4. AC Firmaprofesional - CA1 — no extendedKeyUsage extension.
    5. AC Firmaprofesional - Timestamp 2021 — id-kp-timeStamping.
    6. AC Firmaprofesional - CFEA 2020 — id-kp-clientAuth, Microsoft Smart Card Logon, and 1.2.840.113583.1.1.5.
    7. SIGNE Autoridad de Certificacion - 2020 (B8DF384F1FCD6ECB3F4D7DD6380E54D354C61256560A599D80453247D93AF5EA) — id-kp-clientAuth and id-kp-emailProtection.

    The known impact at the time of this preliminary report is seven CA certificates. The broader certificate corpus and any subscriber-certificate implications remain under review. The policy non-compliance is not considered contained at this preliminary stage because the affected CA certificates remain unexpired and unrevoked. Firmaprofesional does not intend to seek continued inclusion of this hierarchy in the Chrome Root Store and intends to proceed with Chrome's announced phase-out, with sctNotAfter = 2026-09-30 23:59:59 UTC, rather than seek an exemption or submit a replacement root for this purpose.

  • Relevant policies:

    • Chrome Root Program Policy, version 1.8, Section 1.3.2, “Promote use of Dedicated TLS Server Authentication PKI Hierarchies”.
    • Chrome Root Program Policy, version 1.8, Section 3.2.2, "PKI Hierarchies included in the Chrome Root Store""
    • 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). During the resulting internal scope review, Firmaprofesional identified SIGNE Autoridad de Certificacion - 2020 as one additional affected certificate not enumerated in the notification.

Correction to the Preliminary Incident Report

The second policy bullet in the Preliminary Incident Report contains a drafting error. It cites Chrome Root Program Policy version 1.8, Section 3.2.2; however, Section 3.2.2 was the numbering used for the dedicated TLS hierarchy requirement in policy version 1.6. In policy version 1.8, the applicable requirement is Section 1.3.2, “Promote use of Dedicated TLS Server Authentication PKI Hierarchies”. Accordingly, the attribution of Section 3.2.2 to version 1.8 and the duplicated quotation mark should be disregarded. This correction does not change the incident scope or the seven affected subordinate CA certificates.

Status Update

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

Since publication of the Preliminary Incident Report, we have continued reconciling the subordinate CA certificate corpus and reviewing the incident timeline, Root Cause Analysis, remediation plan, and certificate appendix. No additional affected subordinate CA certificates have been identified beyond the seven disclosed in the Preliminary Incident Report. Final validation of the scope and supporting evidence is still in progress.

There is no change to our previously communicated decision to proceed with Chrome's phase-out, with sctNotAfter = 2026-09-30 23:59:59 UTC, rather than seek an exemption or a replacement Chrome-trusted root for this hierarchy.

We will publish the Full Incident Report no later than 2026-07-27 11:10 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.

Whiteboard: Next update 2026-07-27 [ca-compliance]

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 unexpired and unrevoked subordinate CA certificates capable of validating to the Chrome-included root Autoridad de Certificacion Firmaprofesional CIF A62634068 did not meet the dedicated TLS server authentication hierarchy requirements in Chrome Root Program Policy version 1.8, Section 1.3.2. Chrome initially identified six illustrative certificates. Firmaprofesional's subsequent review identified a seventh affected certificate, SIGNE Autoridad de Certificacion - 2020, which Chrome confirmed as non-compliant on 2026-07-13. Chrome announced an sctNotAfter constraint of 2026-09-30 23:59:59 UTC. Firmaprofesional will not seek an exemption or a replacement Chrome-trusted root for this hierarchy and will request voluntary removal of the affected root from the applicable browser Root Programs.
  • Timeline summary:
    • Non-compliance start date: 2026-06-15, when the dedicated TLS hierarchy requirement became applicable to existing Chrome-included roots.
    • Non-compliance identified date: 2026-07-10 15:23 UTC.
    • Non-compliance end date: Ongoing. The affected hierarchy cannot be modified to remedy this non-compliance. Firmaprofesional will therefore request removal of CN=Autoridad de Certificacion Firmaprofesional CIF A62634068; C=ES from the applicable browser Root Programs, with a requested effective removal date of 2026-10-19. Firmaprofesional accepts Chrome's phase-out measure, under which Chrome will apply sctNotAfter = 2026-09-30 23:59:59 UTC. The incident will end when removal has taken effect in each applicable Root Program and the approved Action Items have been completed.
  • Relevant policies:
  • Source of incident disclosure: Third Party Reported — Chrome Root Program.

Impact

  • Total number of certificates: 7 subordinate CA certificates. The seven-certificate corpus is disclosed in the Appendix. Chrome clarified that its original list was illustrative rather than exhaustive.
  • Total number of "remaining valid" certificates: 7. Chrome's notification described the relevant subordinate CA certificates as unexpired and unrevoked, and the subsequent reconciliation confirmed the seventh certificate as unexpired and unrevoked.
  • Affected certificate types: Subordinate CA certificates. DV, OV, IV, and EV policy OIDs are not the characteristic causing this incident; the non-compliance concerns the EKU profile of the CA certificates. No TLS subscriber certificate has been issued by any of the subordinate CAs identified in the Appendix.
  • Incident heuristic: Firmaprofesional reviewed the complete corpus of unexpired and unrevoked subordinate CA certificates that, as of 2026-06-15, could validate to Autoridad de Certificacion Firmaprofesional CIF A62634068, and evaluated their EKU profiles against Chrome Root Program Policy Section 1.3.2. Seven certificates matched the incident condition. They are disclosed by full SHA-256 fingerprint in the Appendix.
  • Was issuance stopped in response to this incident, and why or why not?: No, issuance was not stopped across all affected non-TLS services. The affected subordinate CAs support active non-TLS trust-service use cases, and the Chrome enforcement mechanism is a phase-out of browser trust through an sctNotAfter constraint rather than an instruction to stop all non-browser issuance. For publicly trusted TLS certificates issued under other compliant CA certificates, Firmaprofesional has started issuing through DigiCert. During this transition, Firmaprofesional continues to issue only those certificate profiles that DigiCert does not yet support. DigiCert is expected to support the remaining profiles by 2026-08-31, at which point Firmaprofesional plans to transition those profiles as well. Firmaprofesional accepts the Chrome Root Program phase-out measure effective 2026-09-30 23:59:59 UTC.
  • Analysis: Immediate revocation of the seven subordinate CA certificates would interrupt active non-TLS services and relying parties. Firmaprofesional is therefore pursuing an orderly migration to its newer ECC hierarchy, which separates services across FIRMAPROFESIONAL CA ROOT-A WEB, FIRMAPROFESIONAL CA ROOT-B GP, and FIRMAPROFESIONAL CA ROOT-C LATAM and their service-specific subordinate CAs. In parallel, publicly trusted TLS issuance is being transitioned to DigiCert. Firmaprofesional's intended browser-trust outcome is that the legacy RSA root will be voluntarily removed from the applicable browser Root Programs with a requested effective date of 2026-10-19 and that, consistently with Chrome's announced phase-out, certificates with SCTs signed after 2026-09-30 23:59:59 UTC will not be trusted by default in Chrome. Certificates with SCTs signed before that time may continue to be trusted by Chrome until their expiry.
  • Additional considerations:
    • The intended voluntary removal of CN=Autoridad de Certificacion Firmaprofesional CIF A62634068; C=ES is distinct from Bug 2024749, which concerns FIRMAPROFESIONAL CA ROOT-A WEB.

Timeline

  • 2024-11-13 20:48 UTC — Firmaprofesional received the Chrome Root Program Policy version 1.6 preflight, requesting CA Owner feedback by 2024-12-15. Firmaprofesional did not respond.
  • 2025-02-15 — Chrome Root Program Policy version 1.6 became effective. Chrome contacted CA Owners requesting acknowledgement of the update.
  • 2025-03-03 — Firmaprofesional acknowledged through Chrome's survey that it had read, understood, and intended to comply with policy version 1.6. Chrome's notification confirms the date; no contemporaneous record available to Firmaprofesional includes the survey submission time, so only the confirmed date is reported.
  • 2025-05-27 15:26 UTC — Chrome's request regarding Firmaprofesional's open Root Inclusion Request was received and recorded in Jira. Chrome requested a description of progress against version 1.6 expectations. Firmaprofesional did not respond.
  • 2025-10-24 16:14 UTC — Firmaprofesional received the policy version 1.8 preflight, which requested feedback by 2025-11-26. Chrome's 2026 phase-out notification separately described the preflight as sent on 2025-10-20 with feedback requested by 2025-11-20. The delivery record available to Firmaprofesional does not explain that discrepancy. Firmaprofesional did not respond.
  • 2026-02-05 21:26 UTC — Firmaprofesional received the publication notice for Chrome Root Program Policy version 1.8 and Chrome requested CA Owner acknowledgement by 2026-02-27.
  • 2026-02-23 — Firmaprofesional acknowledged through Chrome's survey that it had read, understood, and intended to comply with policy version 1.8. Chrome's notification confirms the date; no contemporaneous record available to Firmaprofesional includes the survey submission time, so only the confirmed date is reported.
  • 2026-06-15 — The dedicated TLS server authentication hierarchy requirement became applicable to existing Chrome-included roots.
  • 2026-07-10 15:23 UTC — Firmaprofesional received Chrome's phase-out notification. This is the incident-awareness time.
  • 2026-07-10 15:24 UTC — An internal incident record was created and investigation began.
  • 2026-07-10 17:33 UTC — The internal response draft already documented SIGNE Autoridad de Certificacion - 2020 as an additional affected certificate and identified the correct clientAuth EKU in AC Firmaprofesional - OTC 2020 and AC Firmaprofesional - CFEA 2020.
  • 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, described the CCADB reconciliation, and stated that it would proceed with the phase-out rather than seek an exemption or replacement Chrome-trusted root for this hierarchy.
  • 2026-07-13 11:10 UTC — Firmaprofesional published the Preliminary Incident Report in Bug 2054448.
  • 2026-07-13 20:37 UTC — Chrome confirmed that SIGNE was non-compliant and accepted Firmaprofesional's EKU correction for OTC 2020 and CFEA 2020. Chrome also clarified that its original certificate list was illustrative rather than exhaustive. Chrome did not identify an additional immediate action in this response.
  • 2026-07-20 09:41 UTC — Firmaprofesional published Comment 1, correcting the policy citation in the Preliminary Incident Report, confirming that no additional affected subordinate CA certificates had been identified beyond the seven already disclosed, and committing to publish the Full Incident Report no later than 2026-07-27 11:10 UTC.
  • 2026-07-20 14:22 UTC — Bugzilla recorded Next update 2026-07-27 [ca-compliance] in the Whiteboard.
  • 2026-09-30 23:59:59 UTC — Chrome-announced sctNotAfter enforcement date, which Firmaprofesional accepts.
  • 2026-10-19 — Effective date that Firmaprofesional will request for removal of the affected root from the applicable browser Root Programs.

Related Incidents

Bug Date opened Description
1965264 2025-05-08 IZENPE requested postponement of removal of its legacy TLS root. Chrome instead applied an SCTNotAfter phase-out while IZENPE transitioned TLS issuance to an external provider. It is relevant to browser-trust phase-out, subscriber migration, issuance reduction, and measurable transition milestones.
1983955 2025-08-19 Certigna reported clientAuth-only subscriber certificates issued under a CA that also supported TLS profiles and accelerated migration to a dedicated client-authentication hierarchy. It is relevant to EKU governance and separation of certificate purposes.
2026351 2026-03-25 IdenTrust reported cross-certificates missing EKU values required by CCADB Policy. The governing rule differs, but the incident is relevant to policy inventory, CA profile review, and EKU control.
2038351 2026-05-08 Let's Encrypt reported cross-certified subordinate CAs missing required EKUs. The incident is relevant to the limitations of relying only on Baseline Requirements and general-purpose linters when Root Program or CCADB rules impose additional CA-profile requirements.

Root Cause Analysis

Root Cause #1: The migration strategy was not converted into a Root Program compliance plan before the applicable date

  • Description: Firmaprofesional had developed a newer ECC architecture with separate roots and service-specific subordinate CAs and intended to move issuance away from the legacy multipurpose RSA hierarchy. However, that operational migration strategy was not converted into a deadline-driven Chrome Root Program compliance plan. In particular, the migration schedule was not aligned with the 2026-06-15 applicability date, and a documented decision to convert, seek an exemption for, or remove the affected legacy hierarchy was not completed and communicated to Chrome before that date. The subsequent transition of publicly trusted TLS issuance to DigiCert, the planned migration of the remaining services, and the voluntary root-removal request address the resulting condition but do not alter the fact that the Chrome requirement became applicable while the legacy hierarchy remained included.
  • Timeline: The ECC migration architecture existed before incident awareness. The required compliance disposition remained unresolved through 2026-06-15 and was made explicit following Chrome's notification on 2026-07-10 15:23 UTC.
  • Detection: The Root Cause was identified by comparing the existing migration roadmap and its milestones with Chrome's applicability date and the available compliance dispositions for the affected hierarchy.
  • Interaction with other factors: No additional contributing factor has been validated. The causal gap was the failure to turn the existing migration strategy into an approved Root Program compliance plan with an applicable deadline, accountable execution milestones, and a defined exit from browser trust.
  • Root Cause Analysis methodology used: Timeline and gap analysis. Firmaprofesional compared the documented ECC migration strategy, the Chrome policy communications and applicability date, the available compliance dispositions, and the actions completed before and after the requirement became applicable.

Lessons Learned

  • What went well:
    • Firmaprofesional already had an ECC migration architecture with separate roots and service-specific subordinate CAs, providing an established destination for the migration of non-TLS services.
    • Firmaprofesional had started transitioning publicly trusted TLS issuance to DigiCert and limited its remaining TLS issuance to profiles that DigiCert does not yet support.
    • Firmaprofesional did not limit its review to Chrome's illustrative list and identified SIGNE as a seventh affected certificate.
    • Firmaprofesional identified and reported Chrome's incorrect serverAuth characterization for OTC 2020 and CFEA 2020; Chrome subsequently confirmed that those certificates contain clientAuth.
    • Firmaprofesional accepted Chrome's phase-out measure and decided to request voluntary removal of the affected root rather than seek continued browser inclusion.
  • What didn't go well:
    • The existing migration strategy was managed as an operational transition and was not converted into a Chrome Root Program compliance plan with the 2026-06-15 applicability date as a mandatory milestone.
    • A definitive disposition for the affected hierarchy—conversion, exemption, or removal—was not completed and communicated before the Chrome requirement became applicable.
    • The migration and browser-exit milestones now being executed occur after the policy applicability date.
  • Where we got lucky:
    • The Chrome phase-out mechanism allows certificates with SCTs signed on or before the enforcement date to remain trusted in Chrome until expiry, reducing abrupt relying-party impact while the migration is performed.
    • DigiCert already supports the publicly trusted TLS profiles transitioned to date, reducing the residual scope to the profiles not yet supported.
    • The existing ECC architecture allows the remaining non-TLS services to be migrated without designing a new target hierarchy during the incident response.
  • Additional: N/A.

Action Items

The following commitments and dates address Root Cause #1.

Action Item Kind Corresponding Root Cause Evaluation Criteria Due Date Status
Complete transition of the remaining publicly trusted TLS certificate profiles to DigiCert Mitigate Root Cause #1 DigiCert supports the remaining profiles and issuance records demonstrate that Firmaprofesional no longer issues those publicly trusted TLS profiles 2026-08-31 Ongoing
Submit and track voluntary removal requests for Autoridad de Certificacion Firmaprofesional CIF A62634068 with each applicable browser Root Program, requesting an effective removal date of 2026-10-19 Mitigate Root Cause #1 Submission receipt and expected enforcement behavior are documented for each applicable Root Program; public references are added where available 2026-09-18 Ongoing
Verify Chrome's sctNotAfter deployment and implement a control preventing accidental representation of post-phase-out certificates as Chrome-trusted Detect/Mitigate Root Cause #1 Chrome metadata deployment is confirmed and product and issuance controls distinguish browser-trusted from non-browser issuance after the enforcement time 2026-09-30 Ongoing

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

Appendix

The complete seven-certificate corpus is 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.

# CA certificate Serial number Validity SHA-256 fingerprint EKU observation Status at awareness
1 AC Firmaprofesional - CUALIFICADOS 7DB68BA268505737 2018-12-14 10:13 to 2030-12-31 04:02 4CCF17C0C8C1C10D5876EC5E3280FE8D134DF36AEDD8444289B990BC3741E74F No EKU Unexpired and unrevoked
2 AC Firmaprofesional - CUALIFICADOS 0D0366455E6E29D4 2014-09-18 10:00 to 2030-12-31 04:02 2B75CC4F36759CFC4C6637B1E0E54359457DB57E74DE4D2DC5D02CDDFF2960CF No EKU Unexpired and unrevoked
3 AC Firmaprofesional - OTC 2020 330478E03741E36995159A82B1996E96 2020-07-30 09:17 to 2030-12-31 04:02 2E60F867E8887CE218059E85403F3613D28DA9EF658874D0C6F9FF25F2DDB6E5 id-kp-clientAuth, Microsoft Smart Card Logon, 1.2.840.113583.1.1.5 Unexpired and unrevoked
4 AC Firmaprofesional - CA1 533015E09A9EB866 2009-08-25 10:05 to 2030-06-16 10:05 0EBBDF146E63F70FAA5927EE8E5346E9C96C5F0D9BDD3212B04ED6687179874D No EKU Unexpired and unrevoked
5 AC Firmaprofesional - Timestamp 2021 08A9744596640672CDD227C2621607C4 2021-04-13 09:32 to 2030-12-31 04:02 75B14D4D63806F30F538060F2EB65C1365BFC0CD7F3ECDC6C0070218B6E46759 id-kp-timeStamping Unexpired and unrevoked
6 AC Firmaprofesional - CFEA 2020 137814F80E61E1F3C8412DD335D01F77 2020-07-30 09:11 to 2030-12-31 04:02 3F4E45A8508BF83137F966AC961EF45AF573F25AA14D83C2A7F23B80A831C93C id-kp-clientAuth, Microsoft Smart Card Logon, 1.2.840.113583.1.1.5 Unexpired and unrevoked
7 SIGNE Autoridad de Certificacion - 2020 547B28543C3112C972B6F2915F231875 2020-07-30 09:26 to 2030-12-31 04:02 B8DF384F1FCD6ECB3F4D7DD6380E54D354C61256560A599D80453247D93AF5EA id-kp-clientAuth, id-kp-emailProtection Unexpired and unrevoked

Status Update

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

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

Whiteboard: Next update 2026-07-27 [ca-compliance] → Next update 2026-08-31 [ca-compliance]

Action Item Update — DigiCert transition completed

The Action Item “Complete transition of the remaining publicly trusted TLS certificate profiles to DigiCert”, due on 2026-08-31, has been completed.

All publicly trusted WebPKI TLS certificate profiles previously issued by Firmaprofesional are now issued through DigiCert's platform. Firmaprofesional has ceased issuing publicly trusted WebPKI TLS subscriber certificates from the legacy hierarchy. No further publicly trusted WebPKI TLS subscriber certificates will be issued under AC Firmaprofesional - Secure Web 2025.

As public issuance evidence, the crt.sh report for AC Firmaprofesional - Secure Web 2025 shows that the certificate with the latest notBefore value is the certificate for *.diputoledo.es, serial number 149B7F34AFE9C7772D230D09B3929890, with notBefore = 2026-08-06 07:00 UTC. This is consistent with our issuance records: no publicly trusted WebPKI TLS subscriber certificate has been issued from this hierarchy after that time.

At the time of this update, our current inventory identifies 948 unexpired publicly trusted WebPKI TLS subscriber certificates issued by this CA. These existing certificates may remain in use until expiry or revocation, but no new publicly trusted WebPKI TLS subscriber certificates will be issued from this hierarchy.

Accordingly, the status of this Action Item is now Completed.

The remaining Action Items in the Full Incident Report continue in progress. We request that the Bugzilla Whiteboard Next update date be set to 2026-09-18, aligned with the due date of the earliest remaining open Action Item. We will provide an earlier update if any Action Item is changed, completed, or delayed.

The timeline shows that this was not an unexpected compliance failure. Firmaprofesional received the Chrome Root Program Policy preflight in November 2024, acknowledged in March 2025 that it understood and intended to comply, did not respond to Chrome’s May 2025 request for progress, received another preflight in October 2025, and again acknowledged the policy in February 2026. The requirement became effective on June 15, 2026. Although Firmaprofesional reported on August 31 that publicly trusted TLS issuance had ceased under this hierarchy, the policy violation remains ongoing.

Against that history, the assertion that the hierarchy “cannot be modified” is not accurate. Existing certificates cannot be altered, but appropriately constrained replacement subordinate CAs can be issued, affected services can be migrated, and the seven non-compliant subordinate CA certificates can be revoked. Operational difficulty or service disruption does not make remediation technically impossible. It is the foreseeable consequence of failing to complete the migration before the deadline, not a basis for knowingly continuing a WebPKI violation.

Chrome Root Program Policy Section 1.3.2 says that Chrome will phase out violating hierarchies. It does not state that phase-out resolves the violation, grants an exception, or authorizes a CA to leave a non-compliant hierarchy in place until root removal or natural expiration. The temporary continued-inclusion provision is limited to qualifying replacement root requests. It is not presented as an alternative to remediation.

The CCADB Incident Reporting Guidelines describe incident reporting as a process through which underlying issues are identified and remediated. Allowing a known violation to continue until the hierarchy is phased out or removed is not remediation. It is allowing the violation to time out.

There is also a substantive revocation question. TLS Baseline Requirements Section 4.9.1.2 requires revocation of a subordinate CA certificate within seven days when the CA becomes aware that the subordinate CA has not complied with the applicable CP or CPS. The obligation to comply with Chrome and CCADB requirements is longstanding. The June 15, 2026 change in Chrome Root Program Policy Section 1.1.3 added the explicit requirement that this commitment be stated in the CP or combined CP/CPS.

Firmaprofesional should address the following:

  1. Please correct or substantiate the statement that the hierarchy “cannot be modified”. What technical barrier prevents issuing appropriately constrained replacement subordinate CAs, migrating the affected services, and revoking the seven non-compliant subordinate CA certificates?

  2. What normative provision permits these certificates to remain unrevoked when their profiles cause the hierarchy to violate Chrome Root Program Policy Section 1.3.2? Does Firmaprofesional consider this violation to be non-compliance with its applicable CP or CPS for purposes of TLS Baseline Requirements Section 4.9.1.2?

  3. If Section 4.9.1.2 applies, why were the subordinate CA certificates not revoked within seven days, and where is the corresponding delayed-revocation incident report?

  4. Firmaprofesional’s currently published CP/CPS documents do not appear to contain the explicit statement required by Chrome Root Program Policy Section 1.1.3. Please identify the authoritative document containing that statement, or explain whether this is an additional compliance failure.

I ask Chrome to clarify the following:

  1. Does phase-out under Section 1.3.2 authorize a CA to continue a known violation until the SCTNotAfter date or root removal, or is phase-out only Chrome’s response to a violation that the CA must still remediate? Can the incident be resolved while the certificates causing the violation remain unexpired and unrevoked under an included root?

  2. Does the CP/CPS commitment required by Section 1.1.3 bring compliance with Section 1.3.2 within the phrase “applicable Certificate Policy and/or Certification Practice Statement” in TLS Baseline Requirements Section 4.9.1.2?

  3. This appears to be Firmaprofesional’s only remaining directly trusted root identity in Chrome. If it leaves with this violation unresolved, how will that history be considered in any future inclusion request from the same CA owner, an affiliate, or a successor? More generally, may a CA owner avoid remediation for one hierarchy by accepting its phase-out while retaining other included roots or seeking inclusion again later?

The central question is whether phase-out is merely the consequence of non-compliance, or whether Chrome considers it a valid reason for knowingly allowing that non-compliance to continue. The policy language appears to establish the former, but the handling of this incident risks establishing the latter.

Flags: needinfo?(clopez)
Flags: needinfo?(chrome-root-program)
Assignee: nobody → clopez
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: Next update 2026-08-31 [ca-compliance] → Next update 2026-09-18 [ca-compliance]

Thank you for the questions raised in Comment 6.

To avoid ambiguity, the statement that the hierarchy “cannot be modified” referred only to the fact that existing CA certificates cannot themselves be altered.

Firmaprofesional has ceased publicly trusted TLS issuance under this hierarchy and has decided to exit the applicable public browser Root Programs.

We are reviewing the questions raised, including the applicability of TLS Baseline Requirements Section 4.9.1.2 to each Subordinate CA certificate and the policy-document question.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: