1551371 - T-Systems: "Some-State" in stateOrProvinceName

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Four T-Systems certificates containing a stateOrProvinceName of "Some-State" were published at https://misissued.com/batch/53/ This is apparently the default placed in OpenSSL CSRs, indicating that this field was not validated. BR section 7.1.4.2.2(f) states: If present, the subject:stateOrProvinceName field MUST contain the Subject’s state or province information as verified under Section 3.2.2.1. The EVGLs reference the BRs.

Please provide an incident report, as described at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

Comment 1

[Arnold Essing]

1. How your CA first became aware of the problem, and the time and date.
   2019-05-13 04:55 UTC: We became aware of the problem while performing the daily check of the mozilla.dev-security-policy mailing list.

2. A timeline of the actions your CA took in response.
   2019-05-13 04:55 UTC: We became aware of the problem.
   2019-05-13 07:00 UTC: Start of the investigation (first problem related conference call). The analysis revealed that in accordance with BR 4.9.1.1, the certificates must be revoked within 5 days.
   2019-05-13 08:25 UTC: Feedback in mozilla.dev-security-policy mailing list: “Thank you for reporting this issue. The certificates will be revoked in accordance with BR 4.9.1.1. We will provide an incident report after the internal investigation is finished.”
   2019-05-13 10:20 UTC: The technical analysis revealed that no additional valid certificates were affected.
   2019-05-13 11:10 UTC: The affected customers were informed to revoke the erroneous certificates immediately. If the customer does not revoke the certificates, we as the CA will revoke the certificates in accordance to BR 4.9.1.1 on 2019-05-16 13:00 UTC.
   2019-05-16 13:15 UTC: The last affected certificate was revoked.

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.
   The last affected certificate was issued on May 24, 2017.

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.
   5 valid certificates were affected. The first certificate was issued on Nov. 17, 2016, the last on May 24, 2017.

5. The complete certificate data for the problematic certificates.
   https://crt.sh/?q=55474507
   https://crt.sh/?q=307462522
   https://crt.sh/?q=307782108
   https://crt.sh/?q=188608182
   https://crt.sh/?q=307458513

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   Our RA team works hard to avoid making any mistakes. Each application is reviewed in detail.
   As of May 2017, quality measures regarding validation processes took place as part of Incident 1391074. The focus then was on metadata and invalid characters, not on possible erroneous entries due to default settings. Since then, no additional certificates of this error type were issued due to the intensified sensitivity.
   Before the quality measures, the application field "stateOrProvinceName" in very few individual instances were not assigned the necessary importance. During this time, the error was subsequently not revealed, because it was not detected by the linter or the internal test tool and was thus not noticeable.

7. List of steps CA is taking to resolve the situation and ensure it will not be repeated.
   The RAs have been trained to ensure better reviewing of the applications. We are diligently at work to prevent mistakes from happening when issuing new certificates.
   In order to avoid such problems in the future, we have detailed our specification and increased the entire RA team's awareness in regard to this topic. In this specific case, the existing work instructions have been revised and expanded.
   The RA team was now provided with a lookup list of all allowed terms for the field "stateOrProvinceName".
   Our blacklist will be extended until July 03, 2019 to block CSRs with invalid default values in the field "stateOrProvinceName". With this release from July 03, 2019 our validation process for OV-certificates will be extended by a 4-eye check of the SubjectDN.

Comment 2

[Ryan Sleevi]

Regarding the proposed steps for mitigation:

• To confirm, you rely on human verification to check the allowlist/blocklist, rather than automating it?
• Can you explain why you will not be able to require 4-eyes until 2019-07-03? That is, what makes this process take 6 weeks to implement? It may be appropriate to consider disabling all OV issuance until such controls are implemented.

Comment 3

[Arnold Essing]

We rely on both, the human as well as the automated verification. The dynamic blacklist will automatically block incorrect entries. Successfully entered values by the customer are checked by the RA team on the basis of a whitelist in the 4-eyes principle.
Our RA teams are already now actively practicing the 4-eye-principle in the SubjectDN fields. With the new release on 2019-07-03 the 4-eye-principle will be technically enforced, therefore we have mentioned this date here.

Comment 4

[Arnold Essing]

The new software release was implemented in the production environment today and therefore the 4-eye-principle is also technical enforced now.

Comment 5

[Wayne Thayer]

It appears that remediation has been completed.