1800756 - Sectigo: Failure to revoke ECC certificates with non-DER encoded keyUsage within 5 days

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Martijn Katerbarg]

1. How your CA first became aware of the problem

During our internal discussion of bug 1796803 we came to the decision not to revoke the affected certificates.

2. Timeline

October 21, 2022 – 15:24 UTC
Bug 1796803 is created by Rob Stradling. For the timeline leading up to the events discussed in this bug, we refer to bug 1796803 comment 6.

November 10, 2022 – 23:00 UTC
The script mentioned in bug 1796803 comment 0 is done. Rob Stradling posts a summary along with the affected certificates in bug 1796803.

November 11, 2022 – 15:00 UTC
During our twice weekly WebPKI Incident Response (WIR) call we discuss the progress of the incident and final results of the script that is determining how many and which certificates issued by us are affected.

Based on the results, we determine that the majority of the affected certificates are issued by a single Sub-CA, which is used by one of our reseller partners.

While this reseller partner does rely heavily on the use of automation, we are unable to determine if its customers and our Subscribers do as well.

Due in part to the sheer number of affected Subscribers and Relying Parties that would be affected by a mass revocation of this scale, we decide to not revoke the affected certificates.

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.

See bug 1796803 comment 6.

4. Summary of the problematic certificates

There are a total of 322,161 unique certificate serial numbers affected by the incident described in bug 1796803 that we do not intend to revoke within the usual 5-day window. The last of these certificates will naturally expire on 2023-11-19.

5. Affected certificates

See bug 1796803 comment 12.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now

All information related to the actual misissuance is available in bug 1796803.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future

As part of determining the impact of a non-revocation event and the expectations of Sectigo, we have looked at other bugs where the affected CA chose to not revoke all affected certificates within 5 days.

It is our belief that causing a mass revocation based on the details described in bug 1796803 would neither aid nor benefit the WebPKI or Relying Parties.

Although we do believe that the certificates affected by this incident do not pose a security risk, this belief does not form part of our rationale for not revoking.

We consider this incident to be an exceptional case, for the following reasons:

• Compatibility: Our systems issued affected certificates for over 8 years. In that time, our CA system bug went undetected and we did not see any negative impact on Subscribers or Relying Parties due to the incorrect number of unused bits in the keyUsage BITSTRINGs. It seems clear that this obscure DER encoding bug has not caused any compatibility problems in the WebPKI in practice.
• Scale: Considering the very large number of unexpired certificates and the potential damage (e.g. critical systems down on short notice) and security risks (e.g. site visitors blindly creating exceptions in order to access websites) that a mass revocation of this scale could potentially cause, we feel that not revoking is the best path forward for the ecosystem as a whole in this particular case.
• Validation: There is no suggestion that Sectigo fell short in its duties to validate either domain control or Subject Identity Information for the affected certificates.

Note that we do not have a pre-defined set threshold for the number of affected certificates that will or will not be revoked for any given incident. We have successfully performed large scale revocations in the past. These decisions must be made on a case-by-case basis.

While most of the direct partners affected by this bug are using automation in the form of APIs for ordering and collecting certificates, we do not have the required visibility to determine which of their direct customers (who often are the actual Subscribers) are also doing so.

We are actively working with the affected reseller partners to move them from provisioning 1-year certificates to 90-day certificates, to increase agility going forward. Meanwhile we are watching the development of the ACME Renewal Information Extension and plan on implementing this once it has been finalized in order to (among other purposes) aid our partners and subscribers in cases of unexpected revocations. We intend our ARI implementation to not be limited to only supporting certificates obtained via ACME.

We continue to take every opportunity to encourage our customers to use ACME and/or our other proprietary automation mechanisms for certificate management. Note, however, that we cannot force customers to use automation, and (in line with sentiments expressed previously by Mozilla) we do not wish to discriminate against customers that do not use automation.

We intend to highlight this non-revocation incident to our WebTrust auditor for inclusion in our next BR audit.

Comment 1

[Martijn Katerbarg]

Our initial writeup in comment 0 concludes the remediation and disclosure of this incident. We are watching this bug for any questions and/or comments.

Comment 2

[Martijn Katerbarg]

Ben, we have nothing further to add to this bug. It appears there are no further questions or comments. With that, we believe this bug is ready to be closed.

Comment 3

[Ben Wilson]

I'll close this on or about Friday 2-Dec-2022 unless additional issues or questions are raised.