1804587 - WISeKey: Bad ECDSA algorithm encoding in test certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Pedro Fuentes]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.1 Safari/605.1.15

Steps to reproduce:

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.

The miss-issuance was detected by our quality team while testing a configuration change. It was spotted right after the certificate issuance by checking it against the ZLint linter.

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.

Dec 7 16:37 2022 GMT: The migration from MS CA to EJBCA was completed for the CA “WISeKey CertifyID Advanced GC CA 1” and we proceeded to verify the final CA configuration and perform a series of positive and negative tests.
Dec 7 18:20 2022 GMT: During a negative test, it was tried to issue a malformed certificate to verify the linter configuration, but it wasn't stopped by the linters due to a misconfiguration.
Dec 7 18:34 2022 GMT: Linters configuration was corrected for the CA.
Dec 7 18:39 2022 GMT: The miss-issued 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 CA isn't in production yet, so it wasn’t required to stop it and the required linters were quickly enabled to prevent new miss-issuances.

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.

See 5.

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.

The only affected certificate is https://crt.sh/?id=8146111401

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

During the migration of a CA (“WISeKey CertifyID Advanced GC CA 1”) from MS CA to EJBCA, we performed a series of positive and negative tests. In particular we included in the process negative tests to prevent misissuances, which are controlled by automated pre-issuance listing that must stop any issue.
These tests include manual review of the certificates to verify the proper configuration of the automated checks.
During these tests we detected a problem in the linters configuration and a certificate was issued with an incorrect signature algorithm, ecdsa-with-SHA384, when ecdsa-with-SHA256 should have been used.

This was a violation of the section "7.1.3.2.2 ECDSA" of the Baseline Requirements:

If the signing key is P‐256, the signature MUST use ECDSA with SHA‐256. When
encoded, the AlgorithmIdentifier MUST be byte‐for‐byte identical with the
following hex‐encoded bytes: 300a06082a8648ce3d040302.

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.

The problem was immediately resolved by adjusting the CA configuration of the automated listing and revoking the miss-issued certificate.

Finally, to prevent this from happening in the future, we've updated our migration procedure to improve the process to verify the linters configuration before doing negative tests.

Comment 1

[Mathew Hodson]

I notice that the revoke reason shown at https://crt.sh/?id=8146111401 is "cessationOfOperation".

My understanding of Mozilla policy is that it should have been "superseded".

Unless the keyCompromise CRLReason is being used, the CRLReason superseded MUST be used when:

• the certificate subscriber has requested that their certificate be revoked for this reason; or
• the CA operator has revoked the certificate due to domain authorization or compliance issues other than those related to keyCompromise or privilegeWithdrawn.

Comment 2

[Pedro Fuentes]

In respect to comment #1, it must be understood that the certificate subscriber (i.e. engineer doing the tests) revoked the certificate specifying that reason in the CMS tool because it's our general policy to revoke certificates once the tests have been completed. Test certificates generally aren't replaced and in many cases aren't even deployed in web servers, so in general "cessationOfOperation" is more appropriate than "superseded".

The subscriber communicated the compliance issue after doing the revocation. If the CA compliance team should have revoked the certificate instead of being done by the subscriber, we'd have used certainly used "superseded", as it was a mis-issuance and that reason was more appropriate.

We have already taken the appropriate measures to ensure certificate subscribers are informed of the revocation reasons (written in the subscriber agreement and tooltips in the certificate management tool). In particular, we have made clear internally that test certificates should be revoked with "superseded" in the case that the test failed and a compliance issue was raised.

We continue monitoring this issue, in case there are further comments. No other activity is foreseen.

Comment 3

[Ben Wilson]

I will consider closing this on Friday, 3-Feb-2023, unless there are additional questions or concerns to discuss.