1647468 - D-TRUST: Wrong key usage (Key Encipherment)

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Enrico Entschew]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

This is a preliminary incident report.

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 mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

On 2020-06-22, 08:14 UTC one certificate with TLS attributes was wrongly issued by the SSL intermediate CA D-TRUST SSL CA 2 2020. The certificate wrongly contains the key usage “keyEncipherment” instead of “keyAgreement“. The responsible product manager gave the order to revoke the certificate shortly after issuance. The certificate has been revoked at 10:18 UTC. The case came to our attention through our internal quality checks on 2020-06-22, 09:55 UTC.

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.

2020-06-22, 08:14 UTC: First issuance of a certificate by the SSL intermediate CA D-TRUST SSL CA 2 2020 (https://crt.sh/?id=2989267087)
2020-06-22, 09:35 UTC: Start of internal quality checks of the certificate
2020-06-22, 10:15 UTC: Decision to revoke the certificate
2020-01-22, 10:15 UTC: Stop of production for the TLS intermediate CA D-TRUST SSL CA 2 2020 and begin of investigation of the error
2020-06-22, 10:18 UTC: Revocation of the certificate by the CA

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.

D-TRUST stopped the issuance of certificates by the CA D-TRUST SSL CA 2 2020 until further notice.

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.

Number of affected certificates: 1
Issuing date of first certificate: 2020-06-22
Issuing date of last certificate: 2020-06-22

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

All affected certificates can be found here:
https://crt.sh/?id=2989267087

6.) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

We started a thorough analysis and will publish our findings as soon as we finish it.

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.

D-TRUST stopped all issuance of certificates by the CA D-TRUST SSL CA 2 2020 until further notice. No further certificates with a similar error will be produced.
We will publish a list of steps with the final incident report.

Comment 1

[Enrico Entschew]

This is the final incident report.

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 mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

On 2020-06-22, 08:14 UTC one certificate with TLS attributes was wrongly issued by the SSL intermediate CA D-TRUST SSL CA 2 2020. The certificate wrongly contains the key usage “keyEncipherment” instead of “keyAgreement“. The responsible product manager gave the order to revoke the certificate shortly after issuance. The certificate has been revoked at 10:18 UTC. The case came to our attention through our internal quality checks on 2020-06-22, 09:55 UTC.

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.

2020-06-22, 08:14 UTC: First issuance of a certificate by the SSL intermediate CA D-TRUST SSL CA 2 2020 (https://crt.sh/?id=2989267087)
2020-06-22, 09:35 UTC: Start of internal quality checks of the certificate
2020-06-22, 10:15 UTC: Decision to revoke the certificate
2020-01-22, 10:15 UTC: Stop of production for the TLS intermediate CA D-TRUST SSL CA 2 2020 and beginning of investigation of the error
2020-06-22, 10:18 UTC: Revocation of the certificate by the CA
2020-06-23, 13:09 UTC: Informing Conformity Assessment Body about the issue
2020-06-24, 16:20 UTC: End of thorough analysis and release of an action plan
2020-06-25, 18:10 UTC: Correction and verification of configuration, production still on hold
2020-06-29, 08:50 UTC: Restart of production line
2020-06-29, 09:27 UTC: Production of first certificate

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.

D-TRUST stopped the issuance of certificates by the CA D-TRUST SSL CA 2 2020 and corrected the configuration.

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.

Number of affected certificates: 1
Issuing date of first certificate: 2020-06-22
Issuing date of last certificate: 2020-06-22

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

All affected certificates can be found here:
https://crt.sh/?id=2989267087

6.) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Because of a misconfiguration it was possible to issue non-conformant certificates for a short period. The incorrect key usage was inadvertently assigned. This was not previously detected in the dual control procedure.

The CA is a new CA that was used for the first time. At no time could customers apply for and receive certificates from this CA. The first certificate was issued for the certificate status demo websites of the CA.

Linting is part of our pre- and post-production process. We use the linting tool ZLINT. If the outcome of the linting process is an error, no certificate will be produced. If the outcome is a warning, an operator or product manager will investigate the reason but the certificate will be produced anyway.

In our case no error had been confirmed and the certificate was produced. But we got a warning and the certificate was subjected to an additional and more detailed manual check after being issued. The incorrectly used key usage was detected and the certificate was revoked. The production process was stopped immediately. Our internal quality assurance processes functioned well.

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.

D-TRUST stopped all issuance of certificates by the CA D-TRUST SSL CA 2 2020. D-TRUST corrected the configuration. No further certificates with a similar error can be produced.

We coordinated with our CAB and agreed on the following actions. The actions will be part of audits in the future:

• We carried out additional training of all members of the definition and configuration team.
• We will inform the ZLint-Team about this issue.
• We classified this error in our implementation as an “Error” instead of an “Warning” to prevent the production of certificates with the same error.

Comment 2

[Enrico Entschew]

Weekly Update: The same as last week.

Comment 3

[Ryan Sleevi]

We will inform the ZLint-Team about this issue.

I haven't seen this done. Did I miss it? If not, can you provide details?

Comment 4

[Enrico Entschew]

Ryan: On July 13, I contacted the ZLint team and explained our case. The case can be found here: https://github.com/zmap/zlint/issues/454

Comment 5

[Enrico Entschew]

Weekly Update: There is nothing new to report.

Comment 6

[Enrico Entschew]

Weekly Update: There is nothing new to report.

Comment 7

[Enrico Entschew]

Quick Update: There is nothing new to report. We are still waiting for an update from ZLint. Until then, our adjustment of the ZLint implementation at D-TRUST remains active.

Comment 8

[Enrico Entschew]

Weekly Update: There is nothing new to report.

Comment 9

[Ben Wilson]

Can this case be closed, or are there pending items that need to be addressed?

Comment 10

[Ryan Sleevi]

I'm not sure what "waiting for an update from ZLint" is supposed to mean. Are there plans to contribute anything? Or is the plan for remediation just "tell someone else, and hope they'll do something for free"?

Comment #4 links to the bug, which appears to lay the action at the ZLint maintainers, but D-TRUST is free to submit a pull request, especially given:

We classified this error in our implementation as an “Error” instead of an “Warning” to prevent the production of certificates with the same error.

Now, D-TRUST doesn't have to open-source. We're not requiring that. But I think a clearer understanding about the intended actions here, other than just saying "we opened a bug" would be appreciated.

Comment 11

[Enrico Entschew]

Ryan: That makes sense, of course. We will submit a pull request to ZLint next week, which should solve the problem described in this bug report for third parties.

Comment 12

[Ben Wilson]

I will close this case on Friday, 23-April-2021, unless there are items still to be resolved.