Sectigo: SC45 DCV Reuse Error
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: tim.callan, Assigned: martijn.katerbarg)
Details
(Whiteboard: [ca-compliance] [ov-misissuance])
Through continuous QA testing of our systems, we recently became aware of occurrences of incorrect DCV reuse resulting from a bug in the new code we implemented for SC45 compliance with specific regard to BR 3.2.2.4.18:
For Certificates issued on or after 2021‐12‐01, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method.
We have deployed a code fix. At present we have identified 40 affected certificates and revoked them within 24 hours of identification. We are continuing that investigation to ensure we’ve discovered all affected certificates.
We are working on a full writeup and will follow up shortly.
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
Assignee | |
Comment 1•3 years ago
|
||
1. How your CA first became aware of the problem
Due to continuous QA testing on our systems, we discovered a bug that could lead to the issuance of certificates relying on DCV methods not compliant with SC45 via a DCV reuse mechanism we call Sticky DCV. Sticky DCV, which we mentioned previously in bug 1718771 comment 2, allows the reuse of DCV information for the same Subscriber for 365 days. When done correctly this is perfectly appropriate. Due to this bug, however, it was possible for our Sectigo Certificate Manager (SCM) platform to create a Sticky DCV record that did not fully enforce the new restrictions on HTTP DCV checks that were introduced by SC45.
2. Timeline
June 23, 2021 - 15:10 UTC - A ticket is created to start and track updates to become compliant with the recently passed SC45 CA/B Forum ballot.
November 22, 2021 - 09:30 UTC - We deploy and activate our updates for SC45 compliance.
February 1, 2022 - 8:54 UTC - Continuous testing reveals a possible bug in our SC45 implementation. We create a ticket.
February 2, 2022 - 21:43 UTC - We deploy a hotfix to resolve the bug.
February 3, 2022 - 11:34 UTC - A script is run to identify all the problematic Sticky DCV entries in our system.
February 3, 2022 - 11:47 UTC - We analyze the results and identify 404 problematic Sticky DCV records that could have potentially led to misissuance.
February 3, 2022 - 12:30 UTC - Those 404 Sticky DCV records are deleted, stopping any possibility of further misissuance.
February 4, 2022 - 13:22 UTC - Post-Deployment testing starts on the hotfix code.
February 7, 2022 - 20:58 UTC - Post-Deployment testing complete.
February 8, 2022 - 16:58 UTC – We generate reports of possible misissued certificates. A review of these reports starts to eliminate false positives and confirm the results.
February 9, 2022 - 14:20 UTC - We complete the review and identify 40 certificates confirmed to have been misissued.
February 10, 2022 - 14:14 UTC - All 40 certificates are revoked.
3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.
We have deployed a fix and stopped issuing certificates with this problem.
4. Summary of the problematic certificates
40 certificates issued between 2021-12-01 and 2021-12-29.
5. Affected certificates
6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now
In June 2021 ballot SC45 passed within the CA/B Forum. We started investigating the impact on our systems and the required updates. We identified the requirement to disallow the “Agreed-upon change to website v2” Domain Control Validation method for wildcard SAN values as well as to stop treating as valid subordinate FQDNs of a previously or newly validated FQDN with this method. In November 2021 we deployed the changes required for SC45. “Sticky DCV” flags orders for a specific domain from a specific source for reuse for the limited time of 365 days.
Sectigo Certificate Manager (SCM) includes a feature that allows the creation of Sticky DCV records. This feature, using an API to our backend that manages the Sticky DCV records, incorrectly allowed the creation of an automatically approved Sticky DCV record when the Subscriber’s account already had an approved Sticky DCV record for a parent FQDN for which “Agreed-upon change to website v2” was the DCV method. Prior to SC45 this behavior would have been compliant, but since SC45 it is no longer acceptable. This bug was newly introduced to our codebase in November 2021 when we implemented the changes required for SC45 compliance.
Since SCM is the only application to use this specific Sticky DCV backend API, only certificates requested via that system were affected.
At the highest level, this error owes itself to process complexity. SC45 imposed varying requirements based on the nature of the DCV performed and the set of domains for which it occurred. In a specific set of circumstances our code failed to capture that logic correctly.
7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future
This specific error is eliminated.
This was a software bug that occurred where our business logic of necessity was complex. This possibility is the reason why we conduct continuous QA testing on our systems, which in this case limited the number of affected certificates and the amount of time this bug affected issuance.
|
|
Assignee | |
Comment 2•3 years ago
|
||
We believe we have included all necessary information in comment 1. Remediation has been completed. We are monitoring this bug for any questions and/or comments.
|
|
Assignee | |
Comment 3•3 years ago
|
||
Ben, since there appear to be no questions or comments, I’d like to request closure of this bug.
|
|
||
Comment 4•3 years ago
|
||
I will take a look at closing this on Wed. 23-Mar-2022, unless there are objections.
|
|
||
Updated•3 years ago
|
|
||
Updated•3 years ago
|
|
||
Updated•2 years ago
|
Description
•