1782356 - Sectigo: Misspelled city name in localityName field

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Tim Callan]

1. How your CA first became aware of the problem

Internal audit revealed a replacement certificate containing the misspelled localityName “Las Angeles” as opposed to the correct spelling “Los Angeles.”

2. Timeline

July 14, 2022, 20:31 UTC – Our internal audit reveals a certificate issued containing the subject:localityName attribute with a value of “Las Angeles”. We start an internal investigation.

July 14, 2022, 21:04 UTC – We confirm the included localityName value is indeed incorrect and determine that the certificate is indeed misissued.

July 15, 2022, 00:45 UTC – We send a notification to the subscriber informing them of the fact their certificate was misissued and is scheduled for revocation.

July 19, 2022, 17:04 UTC – The affected certificate is revoked.

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

We are in the process of phasing out the localityName subject attribute in public certificates due to the difficulty in otherwise protecting against the kind of human error seen here. Once we complete this process, this error will not be able to be replicated. We are not aware of any other example of this error in an active certificate.

4 & 5. Affected certificates

One certificate issued Mar. 16, 2022.

Serial Number	Certificate	Precertificate
04D5DF464F942F9EE8B535E12177049C	Certificate	Precertificate

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

As discussed previously in earlier bugs including bug 1715024, the localityName field is an open text field without programmatic checks on its contents. A human rep mistyped “Las” instead of “Los” and didn’t notice the discrepancy. As the vast majority of our active certificates no longer contain a localityName field, this type of error can only occur for a small minority of certificates.

Note that it is prohibitively difficult to programmatically check the localityName field because of the vague definition of “locality” and the near-limitless contents that it might reasonably contain.

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

As discussed extensively in bug 1715024, bug 1724476 comment 3, and bug 1720744 comment 8, among other places, we are going to pains to remove localityName as a field included in any of our public certificates. This lengthy process is underway. Once localityName is entirely stricken as a possibility from our public issuance, this error will be rendered impossible. This is part of our larger initiative to replace human work and judgement with programmatic logic wherever possible. Each such replacement eliminates the opportunity for human error in that circumstance.

Comment 1

[Martijn Katerbarg]

Our initial report concludes our investigation into this incident.

We are monitoring this bug for any questions and/or comments.

Comment 2

[Ben Wilson]

Thanks, Martijn
I'm a little unclear about Sectigo's "next actions" specific to this matter, or whether you are suggesting that remediation should be tracked somewhere else. Could you please clarify 7, the steps and the timeline related to this bug/incident, so that I can either set a "next update" in the whiteboard or await final action needed to close this matter?
Thanks again, Ben

Comment 3

[Martijn Katerbarg]

Our process to remove the localityName field from new certificates is well under way, which is the direct remediation of this incident. When comparing our issuance last year versus this year, we’ve dropped the inclusion of this field by more than 95%.

This incident uncovered another method for us to speed up the deprecation of this field, by stripping it out of certificates upon a replacement request, something we previously did not do. Had we done so initially, this incident would not have occurred.

This change to our replacement process, is currently being scoped for development. We are awaiting confirmation of a deployment date. We should have our target date by the end of next week.

Once that is completed, we should no longer issue certificates which include the localityName field, apart from a handful of subscribers that currently require this due to software limitations on their end. All these requests will pass by both our validation and compliance team before any such issuance will occur, ensuring a multi-person approval. The ultimate goal is to remove this completely during 2023.

Comment 4

[Martijn Katerbarg]

We are targeting to deploy the changes described in comment 3 by the end of September.

Ben, could we set a next-update of September 30th?

Comment 5

[Martijn Katerbarg]

On September 25th, we deployed the changes described in comment 3.

At this point, only a very limited number of pre-approved subscribers have the ability to issue certificates that include the subject:localityName attribute. These subscribers have been notified of the complete deprecation in 2023.

Ben, I believe with this deployment, we are ready to close this bug.

Comment 6

[Ben Wilson]

I'll probably close this tomorrow, 10/5/2022, unless there are additional issues or questions.