Open Bug 1589047 Opened 2 months ago Updated 7 days ago

QuoVadis: Incorrect EV jurisdiction of incorporation information

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

REOPENED

People

(Reporter: corey.j.bonnell, Assigned: s.davidson)

Details

(Whiteboard: [ca-compliance] Next Update - 15-Dec 2019)

On September 19, 2019, I sent a Certificate Problem Report to QuoVadis about incorrect jurisdiction of incorporation information in https://crt.sh/?id=1443925771&opt=ocsp. The certificate was revoked and the replacement (https://crt.sh/?id=1916867185) was issued on September 24.

I did not see an Incident Report created for this mis-issuance, so I'm creating that here.

Assignee: wthayer → s.davidson
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance]

Requesting that this be combined with https://bugzilla.mozilla.org/show_bug.cgi?id=1581234 which deals with this issue.

Status: ASSIGNED → RESOLVED
Closed: 2 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1581234
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Please do not close bugs directly until they've been reviewed.

The statement in Comment #0 of Bug 1581234 stated that, as of 2019-09-13, the issue had been fixed, and as of 2019-09-12, the revocations had been completed. This certificate was detected and revoked after the fact, as it had a relevant subdivision - but that was incorrect for the jurisidction of incorporation.

It also appears to be a different underlying root cause than the bug identified. At minimum, understanding this particular issue, and how it relates to the separate root cause called out in that bug, is, I think, crucial for understanding here. As it stands, the related certificate is not a valid jurisdiction of incorporation, even if it's a valid subdivision, and that seems fundamentally different.

Flags: needinfo?(s.davidson)

I don't think the jurisdiction issues of Quovadis are completely remediated. For example, I don't think they've scanned their OV certs. Nor have they looked at their registration numbers. I was hoping they'd used the registration number patterns we're working on the scan their database of certs to identify any mis-isssuances.

I'm also interested in hearing what the root cause on this certificate was. Looks like the difference is that the jurisdiction was verified at the state/province level, not the locality level? Does this mean the root cause is bad source information where the jurisdiction is being pulled from?

I agree that it's unclear the root cause.

I will highlight the underlying issue though, so it may help in furthering a root cause analysis, and why I think it's different:

To the best of my knowledge, the source of authorities in Switzerland that can meet the definition of the EVGs are not operated at the locality level, thus the inclusion of jurisdictionLocalityName is not correct.

The serialNumber included ( CHE-200.595.965 ) matches against the Handelsregister of Basel-Stadt canton. However, even then, there's a legitimate question about whether the replacement certificate is correct. In Switzerland, the Unique Business Identification Number (UID) is maintained at the Federal level by the Federal Statistical Office, which is the form used here for the serialNumber.

This is why, for example, GLEIF - amusingly to whom this certificate was issued - recognizes Swiss registration at a jurisdictionCountryName level, rather than per Canton.

Bug 1581234 analyzes the use of different (localized) jurisdiction names, but Basel is a valid locality within Switzerland, and so that does not seem to be related. However, at issue here is the underlying data source used to validate the registration, and whether/how it complies with the EV guidelines. So there's definitely a question of "bad source information", which seems orthogonal to Bug 1581234 and is more in line with the set of issues DigiCert is working through.

Historically QuoVadis has operated its own certificate management system (“Trustlink”) and PKI from datacenters located in Bermuda, Switzerland, and the Netherlands. In addition to managing the issuance of TLS certificates, Trustlink is used to manage other digital certificate types such as SMIME, Qualified, authentication, and private trust certificates.

The Trustlink system has checks that enforce technical standards such as the Baseline Requirements; however, QuoVadis has experienced some quality issues when trying to scale TLS validation using processes that are largely manual.

As with other acquisitions, such as the Symantec brands, DigiCert’s intent is to consolidate issuance platforms to its CertCentral platform. QuoVadis will benefit from DigiCert’s significant investment in validation tools, which include guided validation paths, automated checks, and pre-issuance linting. However, we are second in priority queue for consolidation, pending shut-down of all the legacy Symantec systems. DigiCert has told us this will happen in Apr 2020, and they will commence migration of Trustlink shortly after. Planning has already begun for this transfer with the migration paths for TLS being identified.

Like the Symantec migration, the full integration will be done in multiple phases focusing on different customer segments. In its earliest phases, the migration will focus on large enterprise customers or consortia which are not geographically sensitive. In its later stages, DigiCert’s roadmap is to provide a regional version of CertCentral, such that validation data and certain PKI operations can be operated in-region such as in the EU or Switzerland, which is respectful of the needs of customers who are geographically sensitive. This geographic sensitivity is the largest hurdle in migration as DigiCert data is currently stored only in the US. Figuring out the date when that can be accomplished is the primary obstacle to provide a shut-down date for the Trustlink system for TLS.

We have already started consolidating into a single validation team operating under DigiCert’s Dublin based validation group, and are adopting DigiCert’s validation training, standards, and methodologies. Although QuoVadis is still treated separately by DigiCert, we are trying to implement their practices and procedures, including their requirements around incident disclosure and revocation, well before the integration.

As TLS accounts transition from Trustlink to CertCentral, we will check existing organizational details and certificate profiles against DigiCert’s validation platform and revalidate when necessary.

Flags: needinfo?(s.davidson)

I may be missing things, but I don't see an explanation as to root cause, captured in Comment #4, which was requested in Comment #2.

Flags: needinfo?(s.davidson)

Ryan: The root cause has several aspects:

  • The reliance on people to put the correct information in the appropriate fields. In this case, a small number of validation staff in the QuoVadis EU operating centers did not properly interpret what is required for the JOI fields.
  • Much of the validation process was manual, concluding in data entry of the JOI fields by validation agents into the certificate management system, with limited technical enforcement in the JOI fields. Due to this gap, the system did not block issuance when there were errors entered in the JOI fields by a small number of validation staff in these offices.
  • There was insufficient focus on the outcome of certificate structure such as the JOI fields with the internal audits, which explains a bit of why these were not detected earlier.

Hi Ryan: We are conducting a review of the Subject DN settings used in QuoVadis EV certificates including JOI. We will provide an update on our progress by Dec 15.

Flags: needinfo?(s.davidson)
Whiteboard: [ca-compliance] → [ca-compliance] Next Update - 15-Dec 2019
You need to log in before you can comment on or make changes to this bug.