1401211 - NetLock: Non-BR-Compliant Certificate Issuance -- * in not the leftmost position in dnsName

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Varga Viktor]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce:

I would like to report our mis-issuance of cert  https://crt.sh/?id=201784770 which has an internal asterix in one of the dnsNames.

1) How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.

1. On 2nd Sept. we got an email about the mis issuance of this certificate:
https://crt.sh/?id=201784770

2) Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.

I can confirm, we stopped. 

3) Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.

https://crt.sh/?id=201784770

4) Summary of the problematic certificates. For each problem listed below: number of certs, date first and last certs with that problem were issued.

One cert, issued on 16th Aug.

5) Explanation about how and why the mistakes were made, and not caught and fixed earlier.

1. On 16th Aug we issued a certificate * in not the leftmost position in the SAN.
2. The mistake was a human error, when our collegue edited the request to match the corporate data exactly as in the corporate registry, unfortunately removed a separator. 
3. This mistake was not cought when the second person check the request data.
4. On 2nd September we got an email about the mis issuance of this certificate:
https://crt.sh/?id=201784770
5. We confirmed the reporter that he had right, and satrted conversation with the customer about the replacement.
6. They requested us to not revoke immediately the certificate, because they need to time to rollover the new certificate on servers, they depends heavily on the certificate. 
(You can check the domain, the customer is a governmental entity) 
7. After the customer reported back the replacement of certificate, we revoked the certificate on 12nd Sept.

6) 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.

However we implement some changes in the validation until 20 July, the fault show us, that some check need to redone right before the issuance SSL certificates.
So we added a second domain name validation check before the issuance of certificate on Sept 

7) Regular updates to confirm when those steps have been completed.

It's already implemented.

- We expect that your forthcoming audit statements will indicate the findings of these problems. If your CA will not be revoking the certificates within 24 hours in accordance with the BRs, then that will also need to be listed as a finding in your CA’s BR audit statement.

It will includes.

- We expect that your CA will work with your auditor (and supervisory body, as appropriate) and the Root Store(s) that your CA participates in to ensure your analysis of the risk and plan of remediation is acceptable. If your CA will not be revoking the problematic certificates as required by the BRs, then we recommend that you also contact the other root programs that your CA participates in to acknowledge this non-compliance and discuss what expectations their Root Programs have with respect to these certificates.

We will shortly contact those programs afte the filling of this bug.

Comment 1

[Gervase Markham [:gerv]]

Hi Viktor,

It seems like your current process allows validation personnel to alter the list of domains in a certificate request simply using a text editor. That seems error-prone. Do you have any plans to change that? Is that true of other fields? If so, adding a domain name validation check might not be sufficient. Have you considered implementing cablint/certlint as part of your pre-issuance flow, as many other CAs are now doing?

Gerv

Comment 2

[Varga Viktor]

Hi Gerv,
The validation personnel can edit in our CA software the request subject fields only, all other properties are managed trough configurations, so it's not possible to edit anything other than subject data. Each subject field edited separately on an edit screen you need to click into a field, edit its data.
We have a few cases when we need to edit the subject data:
-correct the O field, because the request doesn't includes the company name in its official form,
-correct the name of person/entity in the CN field, to its official form
-move part of the names between givenName and surName, because it was not split correctly,
-user does not knows how to generate SAN request with openssl (needs to edit the openssl.cfg), so puts a lot of domain names in the CN,
-user forgots to add all the needed dnsNames, and asks to add it later.
Because of these cases the edit of subject data needed, we allow it. I think to correct these user errors is common practice.
In this case if we have a second run of checks it will catch the bug, so the process flow needs modification.
Of-course we considered the certlint implementation to integrate into the process (I personally prefer too), just till testing the implementations. We prefer the C based x509lint but it lacks the leftmost * check so cannot implement unchanged.
Also we checking the ruby and go implementations too.

Yours, Viktor

Comment 3

[Ryan Sleevi]

Below is my summary of the issues and remediation plan:

1) Wildcard not in the left-most label of the domain name
- See Comment #0
- Existing Mitigations:
  - Two-person review of domain data
- Root Cause
  - Human error in transcribing domain data from registry authorization (3.2.2.4.1 of the BRs)
  - Human error in reviewing domain data
- Remediation
  - 2017-09-19 - Implementation of technical controls to validate domain data is properly formed

Is the above summary correct?

It seems as if the root cause may be related to the use of method 3.2.2.4.1, which necessitates the use of human entry in the validation of domains. Using methods which can be automated/rely on technical measures (3.2.2.4.2 - 3.2.2.4.4, 3.2.2.4.6 - 3.2.2.4.10) may offer substantial more root cause mitigations.

While that would address the domain validation, it doesn't address other forms of validation (e.g. organization information vetting). While a two-person system of review is an important mitigation, it may be useful to increase the independent sampling review to proactively detect issues.

That said, on the basis of the information provided, I believe we will call this issue resolved.

Comment 4

[Varga Viktor]

Dear Ryan,
Its correct.

Yours, Viktor Varga