Closed Bug 1614290 Opened 2 years ago Closed 2 years ago

WISeKey: Unofficial DBA in Organization field


(NSS :: CA Certificate Compliance, task)

Not set


(Not tracked)



(Reporter: pfuentes, Assigned: pfuentes)


(Whiteboard: [ca-compliance])

  1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in, a Bugzilla bug, or internal self-audit), and the time and date.
    7.2.2020 - 21:40 CET: We received a mail sent to our notifications address
    This mail made us aware of a possible misissuance in a certificate issued with the Organization name "".

  2. 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.
    7.2.2020 - 21:40 CET: The notification is sent, making reference to two fingerprints
    7.2.2020 - 21:50 CET: We identify the two fingerprints, being the precertificate and the leaf certificate of the same issuance
    7.2.2020 - 22:00 CET: We launch the internal investigation, to clarify the possible misissuance in the case that the value in the Organization field was not an official trademark of the customer. During this investigation we find two additional certificates issued to the same customer that have the same problem.
    10.2.2020 - 10:00 CET: We check the documentation managed during the issuance and we confirm that the Organization values aren't matching exactly the registered DBAs or Trademarks of the customer. See Item #6 for details
    10.2.2020 - 10:30 CET: New certificates have been issued and sent to the customer to be replaced ASAP and agreeing to revoke the wrong certificates within the permitted delay of 5 days for this type of problem

  3. 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.
    This problem is not recurrent and we checked that it didn't happen beyond the detected cases, not having found a similar issue.
    The necessary steps to avoid similar issues have been defined. See item #7 for details.

  4. 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 three certificates issued for the same customer in a short period of time that included a DNS name in the Organization field. This DNS name is not an official trademark, as we could verify.

  5. 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 IDs, either in the report or as an attached spreadsheet, with one list per distinct problem. (organizationName = (organizationName = (organizationName =

  6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
    The customer is known as Gonet Private Bank and they have several registered companies (i.e. Gonet et Cie SA, Gonet Conseils SA). This customer has valid and registered DBA names as "Gonet", "Gonet Conseils", among others. The customer seems to be using often its domain names as DBA (Doing Business As) names, and they included these values in the certificate requests, but he has not registered officially the domain names as trademarks in Switzerland.
    The registration officer did the domain and organization validations, but wrongly assumed that the Organization names in the certificate requests like "" "" and "" were acceptable as DBA without doing all the necessary verifications, but just assuming that the ".ch" was not important if the rest was a valid DBA.
    In summary: Our procedures establish the need for such verifications of DBA names, but the Registration Officer was negligent by not doing proper validations.

  7. 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.
    In order to avoid similar issues in the non-automated tasks of the issuance process (domain checking is automated), we have already enforced dual validation of all OV SSL certificates, as we have to do for EV SSL certificates. This means that a registration officer won't be able to approve a certificate request without having a second person double-checking the details in the RA system. We will maintain this approach until we can find ways to automate more the process that remove the need to rely on a single person to validate an OV certificate.

Please note that we had recently an incident due to a typo in the organization filed in some certificates. That incident occurred due to a misconfiguration of manual settings in the MPKI platform accessed by some pre-validated customers. The incident we are disclosing now occurred during the issuance of standalone certificates, not using the same MPKI platform but the RA system used by the registration officers. In both cases we have opted by the same mitigation measure (dual-person checks).

Assignee: wthayer → pfuentes
Ever confirmed: true
Whiteboard: [ca-compliance]

Pedro: Thanks for filing this report.

I think it's a bit ambiguous which portion of the Baseline Requirements you're considering as having been violated.

For example, Section of the Baseline Requirements, v.1.6.7 states:

CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute
except as specified in Section or Section

Alternatively, it's possible that you're reporting a quality issue with respect to (b), that:

If present, the subject:organizationName field MUST contain either the Subject’s
name or DBA as verified under Section The CA may include information in this field
that differs slightly from the verified name, such as common variations or abbreviations,
provided that the CA documents the difference and any abbreviations used are locally
accepted abbreviations; e.g., if the official record shows “Company Name Incorporated”, the
CA MAY use “Company Name Inc.” or “Company Name”. Because Subject name attributes for
individuals (e.g. givenName ( and surname ( are not broadly supported by
application software, the CA MAY use the subject:organizationName field to convey a natural
person Subject’s name or DBA.

Could you clarify?

Flags: needinfo?(pfuentes)

Hello Ryan,
we consider this a violation of the second case (quality issue with respect to (b)), as the registration officer didn't validated properly the DBA appearing the the organization name of the subject.

Flags: needinfo?(pfuentes)
Flags: needinfo?(wthayer)

It appears that all questions have been answered and remediation is complete.

Closed: 2 years ago
Flags: needinfo?(wthayer)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.