1983955 - Certigna: Subscriber certificate with EKU clientAuth only

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[r.delval]

Preliminary Incident Report

Summary

Incident description: Certificate with EKU clientAuth only
We are opening this Preliminary Report following a concern raised by Sectigo regarding certificate profiles issued under our historical intermediate CA Certigna Services CA.

This intermediate CA historically supported two profiles:
• Server Certificate: with EKU serverAuth only and including a policy OID referencing the CA/Browser Forum Reserved Policy Identifier (2.23.140.1.2.2 for OVCP).
• Client Certificate: with EKU clientAuth only, without inclusion of a CA/Browser Forum Reserved Policy Identifier.

From our interpretation, client authentication certificates were not subject to TLS Baseline Requirements (BRs), which explicitly target server certificates containing EKU serverAuth and referencing CABF policy OID.

Relevant policies: TLS Baseline Requirements v2.1.6
Source of incident disclosure: Contact from Sectigo

Background

• Until 19 August 2025, the intermediate CA Certigna Services CA issued certificates with EKU clientAuth only
• In March 2024, following an incident declared by another CA, discussions were initiated within the community regarding the issuance of client certificates and the use of CA/Browser Forum Reserved Policy Identifier. While our client-only certificates attempted to align with TLS BR requirements applicable to server certificates, they did not explicitly include such identifier.

Actions Already Taken

• Aware that our historical CAs no longer fully match current expectations (dedicated usage hierarchies), in 2024 and 2025 we initiated the creation of new dedicated CAs specifically for client authentication certificate issuance. Audit reports were received recently, and we originally planned to transition usage to these new hierarchies before the end of 2025.
• On 19 August 2025, after consultation with Sectigo, the compliance of issuing such clientAuth-only certificates under the historical CA was questioned.
• We immediately stopped issuance of such certificates under the historical Certigna Services CA.
• We will now transition earlier than planned to the new dedicated hierarchy linked to a dedicated root "Certigna Client authentication EU Root CA".
• As a precautionary measure, we will contact each subscriber certificate to replace valid certificate with a new certificate issued by this new client dedicated hierarchy with a revocation within 5 days,

Request for Community Input

Given the specific context of these client authentication certificates, we would appreciate input from the community regarding whether such clientAuth-only certificates, which do not explicitly declare CA/B Forum policy reserved identifier, should indeed be considered non-compliant with TLS BRs (which focus on serverAuth) and shall be revoked

We will publish a full incident report with a detailed timeline within the next 72 hours

Comment 1

[chrome-root-program]

After studying the publicly-visible certificate corpus related to Certigna Services CA, we have two concerns.

(1) Certigna Services CA is the subject of two certificates (1 and 2). Both of these certificates assert specific certificatePolicies extension policy OID values (1.2.250.1.177.1.0.1.2 and 1.2.250.1.177.2.0.1.1, respectively). The corresponding CP/CPS states compliance with the TLS BRs.

If we further consider the policy chaining expectations by RFC 5280, a TLS BR certificate policy OID (like 2.23.140.1.2.2 - and as observed in this certificate) would not validate to either of the issuer certificates and should not be considered appropriate.

The other certificate policy OID included in the leaf (1.2.250.1.177.2.5.1.1.1) also does not validate to either issuing CA certificate.

It’s our understanding that under a strict reading of RFC 5280, a certificate path that includes these distinct and unmapped certificate policy OIDs should not validate, which undermines the integrity of the certificate's policy assertions.

Looking more broadly at the certificates issued by the Certigna Services CA, all of them appear to share the above characteristics (i.e., leaf certificatePolicies extension policy OIDs do not intersect the issuer’s). Can Certigna help us interpret this observation?

(2) The “clientAuth-only” topic was discussed by the Server Certificate Working Group in May 2025. Our conclusion from that discussion was that the consensus is: a subordinate CA capable of issuing BR-compliant TLS certificates must ensure all certificates it issues conform to one of the profiles in the TLS BRs. A clientAuth-only certificate does not match any of the allowed profiles, and its issuance is therefore a violation.

Given the Certigna Services CA has issued leafs that contain a TLS BR certificate policy OID, we interpret that the Certigna Services CA is asserting compliance with the TLS BRs (in addition to the statements made in the corresponding CP/CPS).

As always, we’re open to other opinions, but we feel that the recent SCWG discussion clarified community expectations on the clientAuth-only topic.

Comment 2

[r.delval]

To provide further details in the organization of the OIDs for this historical authority. The OIDs in the leaf certificates have a common prefix that defines the issuing certification authority, and the link to the CP/CPS in the certificate confirms that this profile is authorized by the issuing CA, although, according to a strict interpretation of RFC 5280, this approach does not guarantee a direct technical intersection between the certificates.

With regard to discussions on clientAuth certificates, we have reached the same conclusion. We are making progress in implementing corrective measures and will keep this Bugzilla entry up to date with the status of certificate replacement and revocation (see full report in next comment).

In addition for information, this historical certification authority, “Certigna Services CA" (1), is expiring and we are no longer issuing any certificates under this authority.

Comment 3

[r.delval]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A000011

• Incident description:
  We are opening this report following a concern raised by Sectigo regarding certificate profiles issued under our historical intermediate CA Certigna Services CA.
  This intermediate CA historically supported two profiles:

  • Server Certificate: with EKU serverAuth only and including a policy OID referencing the CA/Browser Forum Reserved Policy Identifier (2.23.140.1.2.2 for OVCP).
  • Client Certificate: with EKU clientAuth only, without inclusion of a CA/Browser Forum Reserved Policy Identifier.
    From our interpretation, client authentication certificates were not subject to TLS Baseline Requirements (BRs), which explicitly target server certificates containing EKU serverAuth and referencing CABF policy OID. In fact, with the CA capability to issue server or client certificat seems to be subject to the TLS BRs for all issued certificate. All profiles must assert compliance to the TLS BR.

• Timeline summary:

  • Non-compliance start date: 2015-11-25
  • Non-compliance identified date: 2025-08-19
  • Non-compliance end date: 2025-08-19

• Relevant policies: TLS Baseline Requirements v2.1.6

• Source of incident disclosure: Contact from Sectigo

Impact

• Total number of certificates: 3438
• Total number of "remaining valid" certificates: 692
• Affected certificate types: clientAuth certificates
• Incident heuristic: Impact on all certificates issues from « Certigna Services CA » with clientAuth-only profile
• Was issuance stopped in response to this incident, and why or why not?:
  Yes. The issuance of new clientAuth certificates under Certigna Services CA was suspended as soon as the incident was identified.
• Analysis:
  No direct security risk (certificates do not include serverAuth, so they cannot be exploited for TLS server).
• Additional considerations:
  Certificates are mainly used in an RGS (France) regulatory context, which already required a separation between serverAuth-only and clientAuth-only certificates, but their use in Root Stores requires alignment with TLS BRs.

Timeline

All times are UTC
[2025-08-19]

• 13h00 : Notification by Sectigo regarding the issuance of clientAuth certificates that do not comply with TLS BR during a meeting (absence of the “serverAuth” EKU)
• 13h20 : Notification to Certigna teams about the suspension of Auth client certificates
• 13h20 : Suspension of certificate issuance by the CA
• 13h35 : Inventory of valid certificates affected: 692
• 14h22 : Inventory of all known contacts linked to these certificates
• 15h00 : Migration to the new authority dedicated to clientAuth certificates in our internal tools
• 20h49 : Creation of a preliminary incident ticket in BUGZILLA

[2025-08-20]

• 09h01 : Set up outgoing calls to certificate subscribers, prioritizing customers based on certificates volume and business criticality (hospitals, emergency services, etc.).
• 10h15 : Notification of the incident to LSTI (assessment body) and ANSSI (supervisory body)
• 12h16 : Sending an email campaign to all subscribers of affected certificates
• 14h10 : Issuing first subscriber certificate on the new client authentication CA

Related Incidents

Bug	Date	Description
1887705	March 2024	Incident Entrust: clientAuth TLS Certificates without serverAuth EKU

Root Cause Analysis

Contributing Factor #1: Incorrect analysis of TLS BR and other incidents

• Description: Certigna misinterpreted that client authentication certificates were not subject to TLS Baseline Requirements (BR) because they do not contain the serverAuth EKU and the CA/Browser Forum reserved policy identifier (2.23.140.1.2.2 for OVCP).
  The bug related to Entrust on clientAuth-only certificates was initially analyzed in comparison with our clientAuth-only certificates by the compliance team, and this difference in the CA/Browser Forum Reserved Policy Identifier (2.23.140. 1.2.2 for OVCP) seemed to indicate that this profile was not subject to TLS BR (out of scope).
  In fact, the certification authority's ability to issue serverAuth certificates compliant with TLS BR implies that all leaf (profiles) certificates must be compliant with TLS BR. This certification authority should not have been used for clientAuth-only certificates.
• Timeline: -
• Detection: Contact from sectigo
• Interaction with other factors: Multiple overlapping requirements (RGS, ETSI, TLS BRs, Root Program policies) created complexity in policy interpretation.
• Root Cause Analysis methodology used: Internal policy review + Comparison with similar incidents

Contributing Factor #2: Differences between French standards and TLS BRs

• Description: The Certigna Services CA authority is certified according to European (ETSI 319 411-1) and French (RGS*) standards. For many years, the RGS has required a strict separation between clientAuth and serverAuth uses (no cumulative uses). For this reason, this authority had two different profiles for final certificates.

  • Server Certificate: with EKU serverAuth only and including a policy OID referencing the CA/Browser Forum Reserved Policy Identifier (2.23.140.1.2.2 for OVCP).
  • Client Certificate: with EKU clientAuth only, without inclusion of a CA/Browser Forum Reserved Policy Identifier.
    When these profiles were released, recognition of the root CA by browsers was a key expectation of services that relied on this type of certificate (using trusted certificates from root stores is always a reassuring factor for end users).

• Timeline: -

• Detection: This contributing factor was identified during the review of the incident, when comparing the requirements of the TLS BRs with the historical implementation of the French RGS. The difference in approach (strict separation of serverAuth vs. clientAuth in RGS, versus combined or optional EKUs in the BRs) only became evident when the incident was raised and a deeper alignment analysis was conducted.

• Interaction with other factors: Specific context of the French RGS, where clientAuth certificates have national legal use, not covered by BRs.

• Root Cause Analysis methodology used: Internal policy review / 5-why

Lessons Learned

• What went well:

  • Responsiveness in identifying and suspending the issuance for this certificate profile.
  • Transition to a dedicated clientAuth hierarchy was already planned, which means remediation is aligned with our long-term strategy and only needs to be accelerated.

• What didn’t go well:

  • clientAuth profile is not flagged with CPS CAB Forum, linter parse this profile as a non-TLS certificate (no error or warning)
  • The internal understanding that TLS BR did not apply to clientAuth-only certificates was correct, but only for CAs that do not issue other types of profiles that must comply with these requirements.

• Where we got lucky:

  • Limited number of certificates concerned (692).
  • No direct security risk (certificates do not include serverAuth, so they cannot be exploited for TLS server).

• Additional:

  • Need to continue to align the requirements of the various standards as closely as possible: RGS, ETSI, BRs, and root store programs.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Immediate suspension of the clientAuth issuance under Certigna Services CA	Mitigate	RC#1	No new non-compliant certificates issued	2025-08-19	Done
Deployment of a dedicated clientAuth CA called “Certigna Client Authentication Legal Person EU CA”	Prevent	RC#1	Effective in production	2025-08-20	Done
Revocation of valid clientAuth certificates	Corrective	RC#1	All certificates are revoked (or expired)	before 2025-08-25	Planned

Appendix

• List of 692 affected certificates

Comment 4

[r.delval]

Attachment: affected_certs.csv

Comment 5

[r.delval]

The mass revocation script was executed today at 1:05 p.m. All clientAuth certificates affected by this incident have expired or been revoked

• 6 certificates expired between August 19, 2025, and August 24, 2025
• 5 certificates revoked by the subscribers
• 681 certificates revoked by the mass revocation script

All certificates have been revoked.
Link to Certigna Services CA CRL : https://crl.certigna.fr/servicesca.crl

In attachment, affected_certs_revoked.csv with revocation dates updated

Comment 6

[r.delval]

Attachment: afected_certs_revoked.csv

Comment 7

[r.delval]

Please find below action items updated

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Immediate suspension of the clientAuth issuance under Certigna Services CA	Mitigate	RC#1	No new non-compliant certificates issued	2025-08-19	Done
Deployment of a dedicated clientAuth CA called “Certigna Client Authentication Legal Person EU CA”	Prevent	RC#1	Effective in production	2025-08-20	Done
Revocation of valid certificates	Corrective	RC#1	All certificates are revoked (or expired)	2025-08-24	Done

Comment 8

[chrome-root-program]

[In response to Comment 2.]

Thank you for responding to the questions in Comment 1.

(Q1): Can you help us understand, from Certigna’s perspective, whether the policy chaining issue described in Question 1 should be considered misissuance? Offering justification for such a conclusion would be helpful.

(Q2): Regardless of the answer to Q1, we’re curious to understand why Certigna issues leaf certificates where policy chaining to its issuer is not possible. Can you please explain the rationale behind this design choice?

(Q3): Given some relying party software implementations might not process paths in the absence of valid policy chaining, is Certigna intending on changing its current behavior? If so, can you please add Action Items appropriately for long-term tracking? If not, can you please explain why not?

Note: If on subsequent reports you could modify the tool used to generate the attachment to address the following, it’d be appreciated.

• Remove the colons included in serialNumber (e.g., from “AA:06:07:BD:0E:0C:7F:09:06:11:3C:59:52:1D:C0:0C:CC:64:10:2D:06:60:C1:FF:DF:FF:A6:79:36:E8:68:86” -> “AA0607BD0E0C7F0906113C59521DC00CCC64102D0660C1FFDFFFA67936E86886”
• Remove the “subject=” and “issuer=” prefix from the content in the Subject and Issuer columns (e.g., from "subject=C = FR, L = PARIS, O = DILA, OU = 0002 13000918600011, CN = DILA - DXSS-FRONTENDCLIENT-Q, serialNumber = C317170627" -> "C = FR, L = PARIS, O = DILA, OU = 0002 13000918600011, CN = DILA - DXSS-FRONTENDCLIENT-Q, serialNumber = C317170627")

Comment 9

[r.delval]

Thank you for sharing your concern. We are always open to suggestions for improving the webpki community.

Certigna’s historical profiles were designed in compliance with European (ETSI) and French (RGS*) standards, which required separation of usages (e.g., TLS serverAuth, clientAuth, emailProtection, document signing).
In this context, the certificate chain validation was never intended to rely solely on policy chaining. Instead, chaining is based on multiple technical elements defined by :

• Issuer/Subject Name matching between parent and child certificates
• Signature validation of each certificate by its issuer
• KeyUsage and ExtendedKeyUsage consistency with the intended purpose
• BasicConstraints and pathLenConstraint to restrict delegation
• CertificatePolicies to describe usage context, but not as a mandatory link in the path building

For more than 20 years of operation, Certigna has never received any report from subscribers, relying parties, or software vendors indicating operational issues due to absence of policy chaining.
This long history suggests that policy chaining is rarely, if ever, enforced in practice by our client software (browsers, OS, or middleware), regardless of the usage type (TLS server, TLS client, S/MIME, document signing, etc.).

On 19 August 2025, prior to this incident and for unrelated reasons, Certigna migrated TLS server certificates to a new intermediate CA, for RGS serverAuth certificate : "Certigna Server Authentication OVCP EU CA G1" (crt.sh).
This new CA profile includes in both the intermediate and the leaf the CA/Browser Forum reserved OIDs (2.23.140.1.2.2 + crt.sh), ensuring proper policy chaining for all TLS certificates.

For other profiles (including those not directly subject to CA/B Forum requirements, such as clientAuth), after Google comment, we have updated CP/CPS to include the issuer’s OID in the leaf certificates.
For example, the updated CP/CPS for multipurpose CA (where clientAuth is defined), section 7.1.4.5.2 for CERTIGNA CLIENT AUTHENTICATION LEGAL PERSON EU CA, certificate policies in subscriber certificates have a reference to issuer CA OID " 1.2.250.1.177.15.0.1.1"
This chain of policies is even available in certificates that are not yet in production (i.e., certified authorities that will go into production in the coming months, to continue our dedicated hierarchy campaign for each use).

Certificate path validation does not rely solely on policy chaining, there is no evidence of operational impact wich suggests that policy chaining is not enforced in practice by client implementations and no security impact was identified
Certigna certification authorities are managed solely by Certigna, from root certificates to subscriber certificates (no external certification sub-authorities). It is not possible to issue leaf certificates with a profile that is not authorized by the issuing certification authority through the CP/CPS. From Certigna’s perspective, the absence of explicit policy chaining in this historical profiles should not be considered a misissuance.

Comment 10

[r.delval]

Incident Closure Summary

Incident description

A clientAuth certificate profile issued by Certigna Services CA only included the clientAuth EKU without the required serverAuth and CAB Forum OID, raising questions about compliance with the CAB Forum TLS Baseline Requirements.

Incident Root Cause(s)

Certigna initially misinterpreted that client authentication certificates were not subject to the TLS Baseline Requirements because they did not contain the serverAuth EKU nor the CA/Browser Forum reserved policy identifier (2.23.140.1.2.2 for OVCP).
These certificate profiles were designed to comply with multiple standards (French RGS, European ETSI, and international CABF), which led to confusion regarding the applicability of each set of requirements.

Remediation description

Upon notification of the incident, certificate issuance from the affected profile was immediately stopped.
All impacted subscribers were contacted to inform them of the revocation deadline and the certificate replacement process.
The affected certificates were revoked within the required timeline.

Commitment summary

• We will strengthen the review of certificate profiles in coordination with the compliance team.
• We will continue the transition to dedicated usage hierarchies for CAs in line with current and upcoming industry requirements.

All action items have been completed within the intended timeline. We respectfully request that this incident be closed.

Comment 11

[incident-reporting]

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

Otherwise, it will be closed on approximately 2025-09-11.