2056989 - FNMT: Issuance of intermediates after 2019-01-01 that do not comply with Mozilla Policy

Status: ASSIGNED

(CA Program :: CA Certificate Compliance, task)

Description

[Amaya Espinosa]

Preliminary Incident Report

Summary

• Incident description: On July 20, 2026, at 14:54 UTC, FNMT received an email informing us of a post on Mozilla’s “dev-security-policy” mailing list titled “MRSP Violations at the Intermediate Level (5.3), Mass Report of 26 Subordinate CAs".

  The notification identified two subordinate CA certificates issued by the FNMT after January 1, 2019, that lacked the required EKU extension. The affected subordinate CA certificates are:

  • AC Unidades de Sellado de Tiempo (EKU: absent), issued on 2019-11-28.
  • AC Sector Publico (EKU: absent), issued on 2019-11-28.

  These subordinate certificates are not used to issue public-trust TLS certificates. FNMT has already initiated the migration to dedicated single-purpose hierarchies. All subordinate CAs under the AC RAIZ NMT-RCM hierarchy that do not issue TLS server certificates are being migrated to dedicated hierarchies.

• Relevant policies: Mozilla Root Store Policy 2.6.1 requires in Section 5.3 Intermediate Certificates

Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate:

• MUST contain an EKU extension;
• MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and
• MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate.

• Source of incident disclosure: Third Party Reported

Comment 1

[Amaya Espinosa]

The full incident report is still being prepared. It will be published by August 3, 2026.

Comment 2

[Amaya Espinosa]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000274

• Incident description: On November 28,2019, FNMT issued two intermediate certificates, "AC Unidades de Sellado de Tiempo" and "AC Sector Publico", under the "AC RAIZ FNMT-RCM" hierarchy. Both certificates lacked the Extended Key Usage (EKU) extensions required by Mozilla Root Store Policy.

• Timeline summary:

  • Non-compliance start date: November 28, 2019
  • Non-compliance identified date: July 20, 2026
  • Non-compliance end date: Ongoing. The migration plan to dedicated single-purpose hierarchies is currently in progress. All subordinate CAs under the "AC RAIZ FNMT-RCM" hierarchy that do not issue publicly trusted TLS server certificates are being migrated to dedicated hierarchies according to their intended purpose.
    • AC Unidades de Sellado de Tiempo (EKU: absent) → Dedicated timestamping hierarchy.
    • AC Sector Publico (EKU: absent) → Dedicated client authentication and document signing hierarchy under the AC RAIZ FNMT-RCM root.

  As an interim risk mitigation measure while the migration is being completed, we will request inclusion of the affected intermediate CA certificates in OneCRL.

• Relevant policies: Mozilla Root Store Policy v2.6 requires in "5.3 Intermediate Certificates"

Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a private key with a corresponding root certificate:

• MUST contain an EKU extension;
• MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and
• MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection KeyPurposeIds in the same certificate.

• Source of incident disclosure: Third party reporter

Impact

• Total number of certificates: 2 (two) intermediate CA certificates

• Total number of remaining valid certificates: 2

• Affected certificate types: Intermediate CA certificate. There are no TLS subscriber certificates issued by any of the affected subordinate CAs.

• Incident heuristic: The compliance team reviewed the certificate hierarchy to identify any other non-compliant subordinate CA certificates. The review covered all intermediate CA certificates issued after 2019-01-01 without an EKU extension. Two non-compliant subordinate CA certificates were identified, and their details are provided in the Appendix.

• Was issuance stopped in response to this incident, and why or why not?: No. Issuance was not stopped because the affected subordinate CAs are used exclusively for non-TLS trust services. A migration plan to dedicated replacement hierarchies is already underway.

• Analysis: Immediate revocation of the two affected intermediate CA certificates would have a significant operational impact on existing services and relying parties. The affected hierarchies continue to support non-TLS trust services, and revoking the intermediate CAs before the migration to replacement hierarchies is completed would invalidate certification paths relied upon for signature and timestamp validation. The end-entity certificate types are:

  • Electronic signature: Certificates issued to civil servants and government agencies. Immediate revocation would disrupt essential public services.
  • Time-stamping: No new timestamping certificates are issued from the affected hierarchy; however, previously issued timestamps must remain verifiable until 14 December 2028. Revoking the issuing hierarchy before that date could prevent relying parties from validating historical timestamps.

  In addition, on October 10, 2024, the FNMT created two new hierarchies, “AC RAIZ FNMT-RCM G2” and “AC RAIZ FNMT-RCM TSA,” to establish dedicated single-purpose hierarchies for authentication and electronic documents signing, and for time-stamping, respectively. These hierarchies include new subordinate certification authorities that will replace the current "AC Sector Publico" and "AC Unidades de Sellado de Tiempo" hierarchies. Both new hierarchies were audited for compliance with the ETSI criteria on 10 March 2025.

  The affected hierarchies are included in the European Union Trusted List (EUTL) for qualified non-TLS trust services. Consequently, their replacement and the migration of relying parties must be carefully coordinated to avoid disrupting qualified trust services.

  The residual security risk associated with postponing revocation is limited because the affected intermediate CAs have never issued publicly trusted TLS server certificates and are dedicated exclusively to non-TLS trust services. To further mitigate the remaining risk during the migration period, a request for inclusion of the affected intermediate CA certificates in OneCRL will be submitted to Mozilla.

• Additional considerations: Mozilla Root Store Policy section 5.3.2 recognizes that technically constraining subordinate CA certificates may not be practical in all cases and, for such certificates, requires that they be audited in accordance with the Mozilla Root Store Policy and publicly disclosed in the CCADB.
  At the time the affected intermediate CA certificates were created, we had a valid ETSI audit report. The affected certificates were disclosed in the CCADB and were subsequently included in the next periodic ETSI audit report, in accordance with the requirements of section 5.3.2.
  Furthermore, the end-entity certificates issued under these CAs do not include dNSName values in the Subject Alternative Name (SAN) extension.

Timeline

• June 29, 2018: Mozilla Root Store Policy version 2.6 was published.
• July 1, 2018: Effective compliance date of the policy.
• November 28, 2019: Intermediate CA certificate "AC Sector Publico" was issued.
• November 28, 2019: Intermediate CA certificate "AC Unidades de Sellado de Tiempo" was issued
• October 10, 2024: A key ceremony was held to create the new root CAs “AC RAIZ FNMT-RCM G2” and “AC RAIZ FNMT-RCM TSA,” marking the start of our transition plan from the certificate hierarchy of our root CA “AC RAIZ FNMT-RCM.” The new hierarchies have been designed as single-purpose hierarchies: one for client authentication and document signing, and the other for timestamping. All intermediate certificates issued under these hierarchies include the extendedKeyUsage extension.
• December 16, 2024: Intermediate CA certificate "AC Sector Publico G2" was issued under AC RAIZ FNMT-RCM G2.
• March,10 2025: The new hierarchies were audited according to the ETSI criteria.
• December 14, 2025: "AC Unidades de Sellado de Tiempo" ceased certificate issuance. It was used exclusively for timestamping services.
• July 20, 2026:
  • 02:16 UTC: The post MRSP Intermediate Violations (5.3), Mass Report of 26 Subordinate CAs was created in the [e-mail] list.
  • 14:54 UTC: FNMT received a Certificate Problem Report identifying a potential Mozilla Root Store Policy non-compliance affecting two intermediate CA certificates.
  • 15:02 UTC: became aware of the reported issue.
• July 21, 2026 12:50 UTC: FNMT replied to the third party reporter to share an initial analysis.
• July 22, 2026 18:42 UTC: FNMT opened the Bug 2056989 to report the incident.
• August, 2026 (planned): Request inclusion of the affected intermediate CA certificates in OneCRL as an interim risk mitigation measure during the migration.
• Q1 2027 (planned): "AC Sector Publico" which is used exclusively for electronic signature certificates, will cease issuing new certificates.
• December 14, 2028 (planned): The validity of the timestamping end-entity certificates issued under "AC Unidades de Sellado de Tiempo" will expire and it will be revoked.
• Q1 2029 (planned): All remaining end-entity certificates issued under "AC Sector Publico" are expected to have expired or revoked. The subordinate CA will then be revoked.

Related Incidents

Bug	Date	Description
1717357	2021-06-20	Both bugs involve the issuance of non-compliant intermediate CA certificates with MSPR
1586787	2019-10-07	Both bugs concern the issuance of intermediate CA certificates without the required EKU extension, although the underlying root causes differ.
1586792	2019-10-07	Both bugs involve the issuance of non-compliant intermediate CA certificates with MSPR
1586795	2019-10-07	Both bugs involve the issuance of non-compliant intermediate CA certificates with MSPR

Root Cause Analysis

Contributing Factor #1: Incomplete interpretation of Mozilla Root Store Policy requirements

• Description: Although Mozilla Root Store Policy section 5.3 requires intermediate CA certificates created after January 1, 2019 to include an Extended Key Usage (EKU) extension, our compliance assessment placed undue emphasis on the provisions of section 5.3.2, which recognize that technically constraining subordinate CA certificates may not be practical in some cases and require such CAs to be audited in accordance with the Mozilla Root Store Policy and publicly disclosed in the CCADB. Because the affected hierarchies were non-technically constrained, were covered by a valid ETSI audit, and were disclosed in the CCADB, our review incorrectly concluded that satisfying the requirements of section 5.3.2 was sufficient.
  As a result, it failed to recognize that compliance with section 5.3—including the requirement for an EKU extension on intermediate CA certificates created after January 1, 2019—remained mandatory.
• Timeline: The incorrect interpretation was established during the compliance assessment performed before the issuance of the affected intermediate CA certificates and remained in place until the incident was identified in July 2026.
• Detection: The compliance gap was identified following the Mozilla community report in July 2026, which prompted a reassessment of our interpretation of sections 5.3 and 5.3.2 of the Mozilla Root Store Policy.
• Interaction with other factors: This interpretation, namely that compliance with the audit and disclosure requirements of Mozilla Root Store Policy section 5.3.2 was sufficient for these non-technically constrained hierarchies, prevented the organization from recognizing that the legacy certificate profiles reused for the affected intermediate CA certificates no longer complied with the requirement in section 5.3 to include an EKU extension.
• Root Cause Analysis methodology used: 5 Whys

Contributing Factor #2: Legacy certificate profile design

• Description: The affected intermediate CA certificate profiles were based on legacy subordinate CA profiles that had been successfully used in previous generations of the hierarchy. These profiles did not include an Extended Key Usage (EKU) extension because they had originally been designed to maximize interoperability with digital signature applications and avoid potential
  compatibility issues with relying-party software. The profiles were intended for subordinate CAs supporting non-TLS trust services. When the new intermediate CA certificates were created, the existing profiles were reused as the baseline without reassessing whether they complied with the Mozilla Root Store Policy requirements applicable at the time of issuance. As a result, the newly issued intermediate CA certificates inherited the same profile design, including the absence of the EKU extension.
• Timeline: The certificate profiles had been established before the issuance of the affected intermediate CA certificates and were used when those certificates were created on November 28, 2019.
• Detection: The issue remained undetected until the Mozilla community's review of intermediate CA certificates in July 2026
• Interaction with other factors: The reliance on legacy certificate profiles, originally designed to avoid interoperability issues with third-party digital signature applications, together with the incomplete interpretation of Mozilla Root Store Policy described in Contributing Factor #1, allowed the non-compliant profiles to remain in use until this incident was reported.
• Root Cause Analysis methodology used: 5 Whys.

Lessons Learned

• What went well:
  The affected intermediate CAs were subject to annual ETSI audits, and the corresponding audit statements were disclosed through the CCADB in accordance with Mozilla Root Store Policy section 5.3.2. These audits confirmed that the affected intermediate CAs were operated exclusively for non-TLS trust services and did not issue publicly trusted TLS server certificates.
• What didn’t go well:
  Our compliance management process did not identify that the EKU requirement introduced in Mozilla Root Store Policy section 5.3 applied to the affected intermediate CA certificates. As a result, legacy certificate profiles continued to be used without identifying the resulting non-compliance.
• Where we got lucky: A migration plan to dedicated single-purpose hierarchies had already been initiated before this incident was reported, facilitating the remediation process.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Complete the migration of all non-TLS trust services to dedicated single-purpose hierarchies with appropriately constrained intermediate CAs	Corrective	Root Cause # 1 and #2	All affected services operate from the new hierarchies and the legacy subordinate CAs have ceased issuing certificates	Q1 2027 (tentative, subject to completion of the migration plan)	Ongoing
Submit a request for inclusion of the affected intermediate CAs in OneCRL as an interim mitigation measure until the migration is completed	Mitigate	Root Cause # 1 and #2	OneCRL request submitted to Mozilla and tracked to completion	2026-08-31	Ongoing
Revoke the two affected intermediate CA certificates once there are no remaining valid certificates issued under them	Corrective	Root Cause # 1 and #2	Both affected intermediate CA certificates are revoked and disclosed in the CCADB	Q1 2029 (tentative, subject to completion of the migration plan)	Planned

Appendix

Descriptions of the affected certs are included here for ease of human reading, and attached as a CSV for machine reading.

• AC Sector Publico

Field	Value
Precertificate SHA-256 hash	N/A
Certificate SHA-256 hash	8265756DD5CD8A37EE61E40351288E4B16A89DD248C1EC4EBA25AAF161ABF498
Subject	CN=AC Sector Público,2.5.4.97=VATES-Q2826004J,OU=Ceres,O=FNMT-RCM,C=ES
Issuer	OU=AC RAIZ FNMT-RCM,O=FNMT-RCM,C=ES
Not before	2019-11-28 08:48:09 GMT
Not after	2029-11-28 08:48:09 GMT
Serial #	0x348160C51F5EDBCB5DDF89CAB4573392
dNSNames
Is revoked?	Planned
Revocation date	Q1 2029
Revocation reason	4 (superseded)

• AC Unidades de Sellado de Tiempo

Field	Value
Precertificate SHA-256 hash	N/A
Certificate SHA-256 hash	9CE630B35F8AE2C6419E734AD9D2FA30476DD9E7394B1E93B27F83F776A024EA
Subject	CN=AC Unidades de Sellado de Tiempo,2.5.4.97=VATES-Q2826004J,OU=Ceres,O=FNMT-RCM,C=ES
Issuer	OU=AC RAIZ FNMT-RCM,O=FNMT-RCM,C=ES
Not before	2019-11-28 08:50:02 GMT
Not after	2029-11-28 08:50:02 GMT
Serial #	0x2CED1A5E02805BBC5DDF8A3AECAA985A
dNSNames
Is revoked?	Planned
Revocation date	Q1 2029
Revocation reason	4 (superseded)

Comment 3

[Amaya Espinosa]

Attachment: affected_certificates.csv

Comment 4

[Wayne]

(In reply to Amaya Espinosa from comment #2)

Full Incident Report

...

• Analysis: Immediate revocation of the two affected intermediate CA certificates would have a significant operational impact on existing services and relying parties. The affected hierarchies continue to support non-TLS trust services, and revoking the intermediate CAs before the migration to replacement hierarchies is completed would invalidate certification paths relied upon for signature and timestamp validation. The end-entity certificate types are:
  • Electronic signature: Certificates issued to civil servants and government agencies. Immediate revocation would disrupt essential public services.
  • Time-stamping: No new timestamping certificates are issued from the affected hierarchy; however, previously issued timestamps must remain verifiable until 14 December 2028. Revoking the issuing hierarchy before that date could prevent relying parties from validating historical timestamps.

...

The affected hierarchies are included in the European Union Trusted List (EUTL) for qualified non-TLS trust services. Consequently, their replacement and the migration of relying parties must be carefully coordinated to avoid disrupting qualified trust services.

The residual security risk associated with postponing revocation is limited because the affected intermediate CAs have never issued publicly trusted TLS server certificates and are dedicated exclusively to non-TLS trust services. To further mitigate the remaining risk during the migration period, a request for inclusion of the affected intermediate CA certificates in OneCRL will be submitted to Mozilla.

...

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Complete the migration of all non-TLS trust services to dedicated single-purpose hierarchies with appropriately constrained intermediate CAs	Corrective	Root Cause # 1 and #2	All affected services operate from the new hierarchies and the legacy subordinate CAs have ceased issuing certificates	Q1 2027 (tentative, subject to completion of the migration plan)	Ongoing
Submit a request for inclusion of the affected intermediate CAs in OneCRL as an interim mitigation measure until the migration is completed	Mitigate	Root Cause # 1 and #2	OneCRL request submitted to Mozilla and tracked to completion	2026-08-31	Ongoing
Revoke the two affected intermediate CA certificates once there are no remaining valid certificates issued under them	Corrective	Root Cause # 1 and #2	Both affected intermediate CA certificates are revoked and disclosed in the CCADB	Q1 2029 (tentative, subject to completion of the migration plan)	Planned

To be clear you are stating because these Subordinate CAs are in the EUTL that revocation is not possible until at least 2029? The baseline requirements are quite clear on timelines for handling Subordinate CAs:

4.9.1.2 Reasons for Revoking a Subordinate CA Certificate
The Issuing CA SHALL revoke a Subordinate CA Certificate within seven (7) days if one or more of the following occurs:

1. The Subordinate CA requests revocation in writing;
2. The Subordinate CA notifies the Issuing CA that the original certificate request was not authorized and does not retroactively grant authorization;
3. The Issuing CA obtains evidence that the Subordinate CA’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise or no longer complies with the requirements of Section 6.1.5 and Section 6.1.6;
4. The Issuing CA obtains evidence that the Certificate was misused;
5. The Issuing CA is made aware that the Certificate was not issued in accordance with or that Subordinate CA has not complied with this document or the applicable Certificate Policy or Certification Practice Statement;
6. The Issuing CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
7. The Issuing CA or Subordinate CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
8. The Issuing CA’s or Subordinate CA’s right to issue Certificates under these Requirements expires or is revoked or terminated, unless the Issuing CA has made arrangements to continue maintaining the CRL/OCSP Repository; or
9. Revocation is required by the Issuing CA’s Certificate Policy and/or Certification Practice Statement.

Not withstanding that the above criteria has been breached, you are contending that were such an incident above to occur it would take years to resolve? That the Subordinate CAs are used in a non-TLS capacity does not change that they are technically capable of such issuance. Issuance for non-WebPKI purposes under a WebPKI Root does not change any of your obligations, nor does the identity of any subscribers and their use-cases.

AC Sector Publico is under the CPS here, there's an odd part:

3.1.5. Uniqueness of names
64. The distinguished name (DN) assigned to Certificates issued to a Subject under these SPPS within the Trust Service Provider’s domain will be unique.

3.1.5. Unicidad de los nombres
64. El nombre distintivo (DN) asignado a los Certificados expedidos a un Sujeto, bajo las presentes DPPP y dentro del dominio del Prestador de Servicios de Confianza, será único.

This seems to be badly phrased to state that a DN will be unique to an individual identity, but that is conflicted later. There is no definition as to what 'Subject'/'Sujeto' is anywhere in the CPS at all. Most references to that word (outside of legal phrasing) are in regards to the Subject field of a certificate - in both variants of the document. This is further made clear here:

7.1.5. Name constraints
295. The distinguished name (DN) assigned to the Subject of the Certificate under this SPPS shall be unique and be composed as defined in the Certificate profile.

7.1.5. Restricciones de nombres
295. El nombre distintivo (DN) asignado al Sujeto del Certificado, en el ámbito de la presente DPPP, será único y con la composición definida en el perfil del Certificado.

I believe at some point this was internally discovered as in the DGPC CPS 7.1.5 is described as:

7.1.5. Name restrictions
333. The distinguished name (DN) assigned to the Certificate Subscriber in the Trust Service Provider’s domain will be unique and will be composed as defined in the Certificate profile.

This is also reflected in the CPS for the timestamping intermediate. DGPC also makes clear in 1.2:

1.2. DOCUMENT NAME AND IDENTIFICATION
...
13. The specific Certification Policies and Practices will prevail over the content of this DGPC for specific aspects relating to the types of Certificate and/or service addressed.

So DGPC does not override that 7.1.5 in AC Sector Publico's CPS is more restrictive.

As written the CPS is stating that all certificates ever issued will have unique DNs under the relevant CPS. In addition the only Certificate profile across those documents are to outline the existing Root CAs in an appendix (DGPC).

Does this reflect actual practice?

6.3.2. Certificate operational periods and key pair usage periods
270. Operational periods for the Certificates and their associated Keys:
RSA hierarchy

• Root FNMT CA Certificate and Key pair: until 1 January 2030.
• Certificate of the Subordinate CA issuing Electronic Signature Certificates
  and Key pair: until 28 November 2029.
• Electronic Signature Certificates and Key pair: until 31 december 2028.
• Electronic Authentication Certificates and Key pair: until 31 december 2028.
• Code Signing Certificates and Key Pair: not in excess of 1 year.

The action items are functionally stating that no change will occur beyond oneCRL inclusion and a theoretical shift to move non-TLS to a different hierarchy. As stated by yourselves these are non-TLS Subordinate CAs, and given the shift to dedicated TLS architectures it seems prudent to handle this before the 'FNMT-RCM' Root expires 2030-01-01. I'm going to propose a different plan:

There is one Subordinate CA under that Root that seems relevant: 'AC RAIZ FNMT-RCM SERVIDORES SEGUROS G2R'. There's another Subordinate CA under that 'AC SERVIDORES SEGUROS TIPO2 G2R' with a total of 50 issuances.

Wouldn't it be simpler to move the TLS issuance under the 'FNMT-RCM' Root to a different hierarchy, and then remove the TLS trust bit from the Root entirely? The active TLS issuance is small enough that keeping them there is causing more problems than it's solving. I may be overlooking the relevant Subordinate CAs however.

Comment 5

[Amaya Espinosa]

(In reply to Wayne from comment #4)

Thank you for your proposal.

We agree that, from a WebPKI perspective, reducing the scope of the legacy root and ultimately removing the TLS trust bit from "AC RAIZ FNMT-RCM" is an appropriate long-term objective. In fact, your proposal is aligned with the direction of our overall PKI transition strategy.

Your proposal and the action plan described in this incident are closely related, as both form part of the broader evolution of our PKI. However, they address different aspects of the transition.

This incident concerns two subordinate CAs issued under "AC RAIZ FNMT-RCM" which, although not technically constrained, have never been used for publicly trusted TLS issuance. They have been operated to provide qualified trust services under the eIDAS framework and have undergone the corresponding conformity assessments and audits required under the applicable regulatory framework.

We are not suggesting that their intended use, nor their inclusion in the European Union Trusted List (EUTL), modifies our obligations under the Baseline Requirements or Mozilla's Root Store Policy. Our request is based on the operational consequences that immediate revocation would have on the continuity of essential public trust services.

One of these subordinate CAs issues qualified electronic signature certificates for public administrations and government employees. Under the regulatory framework governing qualified trust services, the replacement of these certificates generally requires the applicant to appear in person for identity verification. As a result, subscriber migration cannot be completed through automated renewal and requires coordination across multiple public administrations.

The second subordinate CA supports qualified time-stamping services. Although no additional TSA certificates are being issued from this hierarchy, previously issued qualified timestamps must remain verifiable throughout their required retention period. Migrating this service therefore requires a carefully managed transition.

Immediate revocation would interrupt these services before migration of all affected subscribers and time-stamping services could be completed.

Accordingly, migration of the services currently supported by these subordinate CAs is already underway. The action plan is to complete this migration in a controlled manner while requesting inclusion in OneCRL as an interim risk mitigation measure during the transition period.

In parallel, TLS issuance is being migrated to dedicated TLS hierarchies as part of our broader PKI modernization program. This work is being tracked separately in Bug 2031303 and will ultimately eliminate the remaining TLS dependency on "AC RAIZ FNMT-RCM".

Regarding "AC RAIZ FNMT-RCM SERVIDORES SEGUROS G2R", this is a transitional cross-certificate issued solely to maintain uninterrupted service for existing TLS subscribers while the new TLS Root CA becomes broadly distributed across root stores. For this reason, we have requested that the TLS trust bit remain enabled during this transition period in order to avoid disruption to existing TLS subscribers.

We hope this clarifies our approach.

We will continue to provide updates throughout this incident and will answer any additional questions that arise.

Comment 6

[Wayne]

I did make a mistake in finding the wrong Subordinate CA and it happened to be cross-chained to your new hierarchy. The entire root in question has one TLS-relevant Subordinate CA: AC Componentes Informáticos which has 1868 server_auth certs in active issuance today.

As you outlined in #2031303 your plan is to postpone the websites trust bit removal from 2027-04-15 to 2028-12-31. The websites trust bit removal is not an arbitrary choice, it is part of plans documented since January 2023 as a security precaution against old key material being used. New root inclusion requests should have been made at least 2 years in advance, and that request was published this April with 1 year notice.

The removal of the websites trust bit will not affect the rest of your hierarchy, and then revocation of the Subordinate CAs will be moot as the Root is no longer under the Mozilla program for WebPKI purposes. S/MIME is a different matter, but your primary concern has been electronic signatures and time-stamping services. I've yet to hear why that would be relevant here.

Your action items currently focus on "Complete the migration of all non-TLS trust services". My focus is on the TLS trust services, and handling those in a timely manner. I'm functionally stating that the website trust bit removal should happen as planned, or earlier, rather than moving any attempt at compliance off to 2029. Far from a long-term objective, I'm proposing what has been policy for years.

My question also was not answered on DN uniqueness: Does this reflect actual practice?

Comment 7

[Amaya Espinosa]

Thank you for the clarification. We understand that your comments relate to the proposed timeline for removal of the Websites trust bit from "AC RAIZ FNMT-RCM". The proposed timeline should be considered one element of the broader Transition Plan for Existing Roots, taking into account the guidance provided in Section 7.5.3 of the Mozilla Root Store Policy.

Our transition plan comprises a number of coordinated activities, including the deployment of dedicated single-purpose hierarchies with new CA key material and stronger cryptographic algorithms, the migration of existing services, and the phased retirement of the legacy hierarchy. This incident is intended to document one specific part of that transition: the remediation of the two non-TLS subordinate CAs, including their migration, interim risk mitigation through OneCRL, and their revocation once there are no remaining valid certificates issued under them. While both activities form part of our overall PKI transition, they address different objectives.

My question also was not answered on DN uniqueness: Does this reflect actual practice?

Thank you for pointing that out.
To clarify, our actual practice is as follows. We agree that the wording of sections 3.1.5 and 7.1.5 is ambiguous and may lead to different interpretations. That was not our intention, and we will review the wording in a future revision of the CPS to make the intended meaning clearer.

The intent of these sections is to describe the naming rules used when assigning the Subject Distinguished Name (DN). The information contained in the Subject DN is intended to uniquely identify the certificate subject for the corresponding type of certificate. The wording was not intended to imply that a Subject Distinguished Name (DN) is globally unique across all certificates issued under the CPS.

We also acknowledge that the term "Subject" is not explicitly defined in the CPS and that this may lead to ambiguities. In the context of these provisions, "Subject" refers to the entity identified in the Subject field of the certificate. This should not be confused with the Subscriber, which may be a different entity as defined in our CPS. We will revise the wording in a future revision of the CPS to make this distinction explicit and improve clarity.

Finally, regarding the relationship between the DGPC and the certificate-specific CPSs, your interpretation is correct. As stated in Section 1.2 of the DGPC, the certificate-specific CPSs take precedence where they define more specific provisions.

Comment 8

[Amaya Espinosa]

As part of the corrective actions described in this incident, we request the inclusion of the following intermediate CA certificates in OneCRL as an interim mitigation measure until the migration is completed.

These intermediate CAs are not intended to issue TLS certificates and have not been used for publicly trusted TLS issuance. The certificates have not been revoked.

https://crt.sh/?serial=348160C51F5EDBCB5DDF89CAB4573392
Subject: CN=AC Sector Público,2.5.4.97=VATES-Q2826004J,OU=Ceres,O=FNMT-RCM,C=ES
Issuer: OU=AC RAIZ FNMT-RCM,O=FNMT-RCM,C=ES
SHA-256 Fingerprint: 8265756DD5CD8A37EE61E40351288E4B16A89DD248C1EC4EBA25AAF161ABF498

https://crt.sh/?serial=2CED1A5E02805BBC5DDF8A3AECAA985A
Subject:CN=AC Unidades de Sellado de Tiempo,2.5.4.97=VATES-Q2826004J,OU=Ceres,O=FNMT-RCM,C=ES
Issuer: OU=AC RAIZ FNMT-RCM,O=FNMT-RCM,C=ES
SHA-256 Fingerprint: 9CE630B35F8AE2C6419E734AD9D2FA30476DD9E7394B1E93B27F83F776A024EA

Comment 9

[Amaya Espinosa]

We have no new updates to report at this time.

Comment 10

[Amaya Espinosa]

Weekly Update: No new developments to report at this time. FNMT continues to work on the measures related to this ticket. The request to include the affected intermediate CAs in OneCRL has been included in the incident for evaluation.