Open Bug 2069640 Opened 1 month ago Updated 1 hour ago

Sectigo: No revocation after CP/CPS language involving extendedKeyUsage found to be subject to multiple interpretations

Categories

(CA Program :: CA Certificate Compliance, task)

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

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: tim.callan, Assigned: tim.callan)

Details

(Whiteboard: [ca-compliance])

Attachments

(1 file)

Deliberate delayed revocation since 2024.csv
7.36 KB, text/csv
Details

Preliminary Incident Report

Summary

  • Incident description:

    Following the discussion in bug 2061902, Sectigo has opened bug 2069636.

    Sectigo decided not to revoke certificates in connection with bug 2069636. We are using this bug to track the remaining validity of the affected corpus of certificates. Our Full Incident Report on this bug will include the reasons behind this decision. Drafting of this Full Incident Report is underway.

  • Relevant policies:

    Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates – Version 2.2.9, Section 4.9.1.1 (12)

  • Source of incident disclosure: Self-Reported

Assignee: nobody → tim.callan
Status: NEW → ASSIGNED
Whiteboard: [ca-compliance]

Full Incident Report

Summary

  • CA Owner CCADB unique ID: A000016

  • Incident description:
    On 2026-09-05 we opened bug 2069636 to discuss language in our CPS that had proven subject to more than one interpretation. The same day we opened this bug to inform the community that we did not intend to perform any revocation associated with bug 2069636.
    Bug 2069636 explains the reasons we do not believe this is a case of certificate misissuance. In the absence of misissuance, there is no need for revocation. We have opened this bug to track the number of active, expired, and revoked certificates and create a place for commentary.

  • Timeline summary:

    • Non-compliance start date: 2026-09-08
    • Non-compliance identified date: 2026-09-03
    • Non-compliance end date: 2027-04-12, expected
      Note: We do not believe non-compliance occurred in this case. The dates given above start five days after creation of bug 2069636 and extend to the latest expiration date for any of the relevant leaf certificates.

  • Relevant policies:
    Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates – Version 2.2.9, Section 4.9.1.1 (12)

  • Source of incident disclosure: Self-reported

Impact

  • Total number of certificates: 118,251,207
  • Total number of "remaining valid" certificates: 108,871,887
  • Affected certificate types: TLS DV, OV, and EV
  • Incident heuristic: Certificates in scope of discussion for bug 2069636.
  • Was issuance stopped in response to this incident, and why or why not?:
    N/A
  • Analysis: N/A

Timeline

All times UTC

2026-09-03

  • 14:21 In bug 2061902 comment 14 we announce our intent to open a CA incident issue for discussion of the CPS language matter.

2026-09-05

  • 16:41 We open bug 2069636 as a CA incident issue for the CPS language matter.
  • 17:11 We open bug 2069640 stating no revocation will occur in connection with this bug, to track the numbers of active, expired, and revoked certificates, and to facilitate discussion.

Related Incidents

Bug Date Description
1978163 2025-07-18 In this bug the CA Owner claims there is no misissuance despite the presence of unambiguous BR language and widespread pushback from many thread participants. This pushback led the Chrome Root Program in bug 1978163 comment 68 to declare that “We agree with the view … that replacement of affected certificates would be seen as good hygiene and a good-faith effort…” Despite clear community consensus, the CA Owner continued to deny that misissuance had occurred. Because the CA Owner did not agree that misissuance had occurred, it did not revoke certificates and also did not open a bug for this non-revocation.

In 2024 and beyond we saw a flurry of CA Owners opting out of BR-mandated revocation timelines. These incident reports were highly consistent in contending that a CA Owner could elect to use an “exception” supposedly provided by one root program (Mozilla) to override hard requirements from others. These incidents are directly relevant to this bug as they deal with the degree to which a CA Owner’s judgement of governing language overrides or is overridden by that of community members.

Since the beginning of 2024 we have identified 33 individual “delrev” bugs on this topic and one Mozilla meta bug. For the sake of readability of this Incident Report, and with the blessing of the CCADB Steering Committee, we are including this list as attachment 9643277 [details].

Root Cause Analysis

Contributing Factor #1: Misissuance did not occur

  • Description:
    ca-infosharing bug 2061902 and bug 2069636 explain the reasons this is not a case of misissuance. We have opened this bug to track active, expired, and revoked certificates and to provide a place to discuss them. As there is no requirement for revocation of properly issued certificates, we will not perform revocation in connection with this matter.
  • Timeline:
    This applies to the lifespan of all active certificates in our corpus.
  • Detection:
    We came to this conclusion during investigation of the original CPR.
  • Interaction with other factors:
    This is a contributor to contributing factor 2.

Contributing Factor #2: Revocation of certificates would do more harm to Relying Parties than non-revocation would

  • Description:
    What is in debate here is the specific meaning of a single sentence where at least two alternative interpretations exist. No certificates were issued that did not meet CABF and root store requirements. Revoking a large number of certificates in a short time window has a significant negative impact on Relying Parties, as the services and technology they depend on becomes unavailable, possibly for significant periods of time. Even services that do not depend on certificates slated for revocation frequently experience downstream outages as the technology components they depend on become unavailable.
    In this case the harm such a revocation event would do to many people far outweighs any potential benefit of revocation. It would be irresponsible to bring this harm in this instance.

  • Timeline:
    This applies to the lifespan of all active certificates in our corpus.

  • Detection:
    We came to this conclusion during investigation of ca-informational bug 2061902.

  • Interaction with other factors: Contributing factors 1 and 3 play a role in this factor.

Contributing Factor #3: ARI on its own is not a viable option today

  • Description:
    There is widespread agreement that automated, push-based certificate replacement would be extremely valuable to the ecosystem. Unfortunately, ARI support applies to a miniscule percentage of active certificates and even a minority of certificates provisioned via ACME.
    More than 90% of certificate orders for Sectigo are placed through ACME; however, a recent investigation shows ARI use for only 5.4% of active certificates, of which Caddy as ACME client requested 90% of the requests that were completed.
  • Timeline:
    This has been the case for as long as ARI has existed.
  • Detection:
    We identified this contributing factor during investigation of bug 2069636.
  • Interaction with other factors:
    This is a contributor to contributing factor 2.

Contributing Factor #4: Governing guidelines and community tradition are ill suited to handle this case

  • Description:
    CA/Browser Forum documents and the other policies governing the WebPKI do not provide guidance on how to handle disputes regarding the meaning of terminology in governing documents. With this bug we are trying to navigate an undefined process.
    The absence of standard, consistent, well-understood principles and guidelines has introduced friction into this process.
  • Timeline:
    The WebPKI has never offered consistent and well-understood guidelines for a case like this one.
  • Detection:
    We came to this conclusion during research for this incident.
  • Interaction with other factors: None

Lessons Learned

  • What went well:
    Misissuance did not occur.

  • What didn’t go well:
    Existing guidelines and precedent are ill suited to handle this case.

  • Where we got lucky:
    N/A

Action Items

Action Item Kind Corresponding Root Cause(s) Evaluation Criteria Due Date Status
Lead a discussion on how the community should deal with incidents of this sort Mitigate Contributing factor 4 This is untrodden territory. We opened ca-infosharing bug 2061902 to drive conversation around the problem of multiple interpretations and then this bug to discuss this specific case. Mozilla created a discussion thread at https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/QECjs4bxNQw/m/ibl6lLlgCQAJ to drive further discussion. We will seek to add a discussion topic to the upcoming CA/Browser Forum Face-to-face meeting in February 2027, to begin work on how to deal with cases where multiple parties take away different meanings from the same governing language. 2027-02-24 Ongoing
Embed ARI into non-ACME clients Mitigate Contributing factor 3 We have a roadmap item to add ARI support into automated client agents we offer to customers. This will enable ACME RenewalInfo resources in those automated environments even if the Subscriber has elected not to use ACME. 2026-12-31 Ongoing
Commence 3% ARI test this calendar year Mitigate Contributing factor 3 A requirement of the Chrome Quantum-resistant Root Program will be that every quarter the CA Owner will test ARI responsiveness on 3% of ACME-supporting MTC certificates with term above 10 days. We will commence quarterly testing of 3% of all TLS certificates obtained via ACME, plus 3% of all TLS certificates obtained via other mechanisms, with term above 10 days,by the end of this calendar year, and we will make the results publicly available. 2026-12-31 Ongoing
Enable short certificate lifespans Mitigate Contributing factor 3 As certificate term continues to shorten, the negative consequences of misissuance, CPS misalignment, and other potential CA operational problems correspondingly decrease. This is to the point where at ten days term the current requirement for revocation mechanisms vanishes completely. Sectigo has been a strong champion of shortening certificate term for many years. Consequently 92% of our active TLS certificates have term 92 days or shorter. Our CLM and partner platforms allow issuance with term as short as one day. We will continue to champion shorter certificate term with our Subscribers in many forms across many circumstances. 2026-09-05 Complete

Appendix

Due to the file size limitations within Bugzilla, after conferring with the CCADB Steering Committee, we have agreed to host these files externally. Sectigo intends to keep these files available until at least 12 months after this bug has been closed.

Additionally, we have opted to compress the CSV file with gzip.

The full list of affected certificate fingerprints can be found on https://bzr2.sectigo.com/non-revocation.csv.gz.

In addition to this, we have made available a multi-part download of this file, split per 25 million lines. The multi part downloads are available here:

We will be using this format for regular updates on the number of active, revoked, and expired certificates. These are the definitions of what these categories describe.

Term Description
Total certificates The total number of active certificates at reporting time
Unexpired but revoked certificates The number of certificates included in the “Total” count that have not reached expiry date but have been revoked for any reason
Expired certificates The number of certificates included in the “Total” count that have reached expiry date, regardless of whether or not they were revoked prior to that date
Active certificates The number of certificates included in the “Total” count that remain unexpired and unrevoked at query time

As we have stated previously, no misissuance occurred in this case. These numbers cover the corpus of certificates issued during the time period specified in comment 2.

For this report the numbers follow.

Numbers reported as of 2026-09-21 at 13:01 UTC.
Total certificates: 118,251,207
Unexpired but revoked certificates: 743,310
Expired certificates: 20,906,639
Active certificates: 96,601,258

Numbers reported as of 2026-09-27 at 14:49 UTC.
Total certificates: 118,251,207
Unexpired but revoked certificates: 699,631
Expired certificates: 26,986,269
Active certificates: 90,565,307

As we have stated previously, no misissuance occurred in this case. These numbers cover the corpus of certificates issued during the time period specified in comment 2.

Numbers reported as of 2026-09-29 at 15:04 UTC.
Total certificates: 118,251,207
Unexpired but revoked certificates: 684,530
Expired certificates: 29,445,306
Active certificates: 88,121,371

As we have stated previously, no misissuance occurred in this case. These numbers cover the corpus of certificates issued during the time period specified in comment 2.

Numbers reported as of 2026-10-05 at 20:36 UTC.
Total certificates: 118,251,207
Unexpired but revoked certificates: 669,219
Expired certificates: 34,062,061
Active certificates: 83,519,927

As we have stated previously, no misissuance occurred in this case. These numbers cover the corpus of certificates issued during the time period specified in comment 2.

Numbers reported as of 2026-10-08 at 09:42 UTC.
Total certificates: 118,251,207
Unexpired but revoked certificates: 659,810
Expired certificates: 35,869,678
Active certificates: 81,721,719

As we have stated previously, no misissuance occurred in this case. These numbers cover the corpus of certificates issued during the time period specified in comment 2.

Numbers reported as of 2026-10-11 at 13:29 UTC.
Total certificates: 118,251,207
Unexpired but revoked certificates: 657,670
Expired certificates: 37,693,132
Active certificates: 79,900,405

As we have stated previously, no misissuance occurred in this case. These numbers cover the corpus of certificates issued during the time period specified in comment 2.

Numbers reported as of 2026-10-14 at 13:01 UTC.
Total certificates: 118,251,207
Unexpired but revoked certificates: 648,870
Expired certificates: 41,118,641
Active certificates: 76,483,696

As we have stated previously, no misissuance occurred in this case. These numbers cover the corpus of certificates issued during the time period specified in comment 2.

Numbers reported as of 2026-10-18 at 13:01 UTC.
Total certificates: 118,251,207
Unexpired but revoked certificates: 630,532
Expired certificates: 45,426,502
Active certificates: 72,194,173

As we have stated previously, no misissuance occurred in this case. These numbers cover the corpus of certificates issued during the time period specified in comment 2.

Numbers reported as of 2026-10-20 at 13:01 UTC.
Total certificates: 118,251,207
Unexpired but revoked certificates: 625,571
Expired certificates: 48,207,185
Active certificates: 69,418,451

As we have stated previously, no misissuance occurred in this case. These numbers cover the corpus of certificates issued during the time period specified in comment 2.

Numbers reported as of 2026-10-26 at 13:01 UTC.
Total certificates: 118,251,207
Unexpired but revoked certificates: 600,531
Expired certificates: 55,230,075
Active certificates: 62,420,601

As we have stated previously, no misissuance occurred in this case. These numbers cover the corpus of certificates issued during the time period specified in comment 2.

Numbers reported as of 2026-10-29 at 13:01 UTC.
Total certificates: 118,251,207
Unexpired but revoked certificates: 587,844
Expired certificates: 59,367,650
Active certificates: 58,295,713

As we have stated previously, no misissuance occurred in this case. These numbers cover the corpus of certificates issued during the time period specified in comment 2.

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

Attachment

General

Creator:
Created:
Updated:
Size: