Sectigo have been inserting our brand or product names as well as those of certain of our sales partners and/or other descriptive text into the subject:OU fields of end entity certificates.
We regarded these OU values as static, i.e. not relating to the subject of the certificate.
These are Product Names, “Hosted by” statements, “Issued through” statements, “Provided by” statements, etc.
OU=Hosted by <WebHost name>
OU=Provided by <Reseller name>
OU=Issued through <Customer name> E-PKI Manager
OU=Domain Control Validated
Section 126.96.36.199.2.i of the BRs attempts to describe what is permissible to be included in OU field values.
It has been brought to our attention in this bug and the referenced mdsp thread that the wider interpretation of the Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates does not support this practice and therefore we have agreed that we will cease putting any text in an OU field which is not supplied by the certificate applicant.
- How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.
2019-11-01 We read a post on the mozilla.dev.security.policy mailing list that pointed out "that a lot of leaf certificates have organizationalUnitName specified without other organizational information such as organizationName. Many times this field is used for branding purposes, e.g. "issued through <someone's kpi manager>" or "SomeBrand SSL"."
- A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.
(Times/dates in UTC)
2012 The BR language now in 188.8.131.52.2.i around OUs (apart from the givenName and surname) was proposed.
At an intervening date the requirement for givenName and surname were added to the OU language.
2019-11-01 We read the above-referenced post on m.d.s.p. and responded on that thread.
2019-11-04 Matthias opened this bug.
2019-11-13 We made our initial response on this bug.
2019-11-18 We created a development ticket for our CA to discontinue the use of OU fields other than for OU values provided by the applicant and pertaining to the subject.
2019-12-02 We prepared customer messaging around the change of our certificate profile.
2019-12-05 We sent email notifications to customers messaging around the change of our certificate profile.
2019-12-15 00:00 (Scheduled) We will release our code modification to discontinue the use of OU fields other than for OU values provided by the applicant and pertaining to the subject.
- Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
We have not yet stopped adding these additional OU fields. We will stop doing so on 2019-12-15 00:00 (UTC).
- A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
There are many.
The first such certificates would have been issued in 2002.
The last such certificates will be issued on 2019-12-14.
I will provide a count of the affected unexpired certificates in a followup.
- The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
Many may be found
I will provide a list of the affected unexpired certificates in a followup.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
We originally read the BR language as saying that where information pertaining to the subject organization was included in an OU field:
a) That information must be validated per 184.108.40.206, and
b) It must only be included in an OV or EV certificate, i.e. it could not be included in DV.
That interpretation was reasonable if (and only if) the phrase "refers to a specific natural person or Legal Entity" means the same as "refers to the subject". That is how we read it, but I can now see it was not how others read it and can accept that our reading was not the intended reading.
- List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
We have planned and coded for a change to our end entity certificate profiles to remove the extra OU fields.
We have communicated that change to our affected customer base.
The profile change will take effect 2019-12-15 00:00.
We do not propose to revoke the affected end entity certificates at this time.
These certificates will be left to expire.
The latest expiry of any affected certificate will be 2022-02-16.
In this case we believe that the harm caused by following the requirements of BR section 4.9.1 (Circumstances for Revocation) outweighs the risks that are passed on to individuals who rely on the web PKI.
While we appreciate Mozilla's guidance in https://wiki.mozilla.org/CA/Responding_To_An_Incident that <<Responses similar to “we deem this misissuance not to be a security risk” are not acceptable.>>, we do not believe that any security risk is presented by this non-compliance and we consider that there will be a large amount of effort required if we were to try and have the subscribers replace all of the affected certificates and that thousands of websites would likely be taken down because those maintaining them will not respond to the customer communication we send out concerning the affected certificates.
We think that the language of 220.127.116.11.2.i of the BRs is regrettably unclear in its wording and as written arguably forbids the presence of any OU field value at all in any issued certificate, contrary to what we now believe to be the intent of that section.
We will propose a ballot in the CA/B forum to restate 18.104.22.168.2.i in a form of words whose meaning is clear and which allows some sensible use of the OU attribute.
This incident and other high visibility incidents in 2019 have illustrated how a single, codified level of response for all certificates containing BR violations can lead to outcomes that are suboptimal for both relying parties and subscribers. Sectigo plans to drive dialog around establishing categories of BR violation, with appropriate codified responses for each. Our ultimate goal will be to advance a ballot to put these categories into effect.