Sectigo: OV reuse data applied for wrong organization
Sectigo reported an incident in which, due to human error, it applied OV reuse data for the wrong organization to a single OV TLS certificate. The incident began when a validation agent entered an incorrect existing order ID while using an OV data-reuse mechanism, resulting in the certificate being issued with incorrect organization details. Sectigo said it halted issuance of certificates using the affected reuse method until further notice, and it issued a replacement certificate and revoked the affected certificate at the subscriber’s request. Sectigo also created action items for technical controls to prevent recurrence, including a visual side-by-side comparison with string-matching indicators and a technical control that prevents assigning an organization whose name differs by more than 10% (using Levenshtein distance). In later comments, Sectigo stated that the action items were completed and requested closure of the incident report. The bug is marked RESOLVED with resolution FIXED.
- Sectigo issued one OV TLS certificate containing incorrect organization details due to human error during OV data reuse.
- Sectigo identified the incident and opened the Mozilla CA Program bug after internal compliance review.
- Sectigo issued a replacement certificate and revoked the affected certificate at the subscriber’s request.
- Sectigo reported completion of the disclosed remediation action items and requested report closure.
- Sectigo — Filed a preliminary incident report stating that human error led to OV reuse data being applied to the wrong organization, and that Sectigo revoked the certificate, fixed the OV reuse data, and created a ticket for technical controls.
- Sectigo — Posted a full incident report attachment listing affected certificates.
- Sectigo — Provided a full incident report including the timeline, impact (one certificate), and description of the OV data-reuse mechanism and root cause.
- Google representative — Asked two questions about the new preventative control’s minimum string-matching percentage and how the threshold was determined.
- Sectigo — Answered that the threshold was set at 90% initially and described the analysis method used to choose it.
- Community commenter — Questioned whether Sectigo violated the 72-hour requirement for the preliminary incident report and asked whether a separate incident bug should be opened.
- Sectigo — Responded that Sectigo did not agree with the assessment, explaining how it interpreted “becoming aware” and reporting expectations.
- Sectigo — Reported that both pending action items were completed and requested closure, describing the remediation controls added.
- CCADB representative — Issued a final call for comments and stated the incident report would be closed approximately 2025-09-11.