1793692 - WISeKey: Issuance of certificate with non-DER encoded keyUsage

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[John Schanck [:jschanck]]

This certificate has a keyUsage extension that is not encoded using DER. The encoded bit string 03 02 01 81 has a non-zero padding bit and should instead have been encoded as 03 02 07 80.

It appears that a replacement has been issued https://crt.sh/?id=6946639612 but the malformed certificate has not been revoked.

Comment 1

[Pedro Fuentes]

We acknowledge this incident and we will be publishing ASAP the preliminary report
Thanks.

Comment 2

[Pedro Fuentes]

1. How your CA first became aware of the problem.

WISeKey was aware of this incident when this bug was assigned to us (04/Oct/22 22:47 UTC)

2. A timeline of the actions your CA took in response.

The investigation of this incident is related to activities happening in June'22, which are included in this timeline

15/June/22 23:40 UTC – Mozilla’s representative notifies an issue while checking the test certificates of our root, as part of the annual audit case review
15/June/22 07:00 UTC - WISeKey identifies the reason of the issue as a problem in the encoding of the keyUsage of the certificate of the OCSP responder. The generation script is modified and a new OCSP certificate is published
16/June/22 - WISeKey documented the issue and established actions to limit further occurrence. The resolution of the incident was communicated to the Mozilla’s representative, and it was taken as solved.
4/Oct/22 22:47 UTC - This bug is assigned to us
5/Oct/22 8:12 UTC - The reported certificate is revoked

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.

WISeKey took already action to avoid this problem. See point 7.

4 (includes 5). Affected certificates

Reported certificate: https://crt.sh/?id=6946639612 - Revoked
It must be noted that this certificate is under a Root not anymore trusted by the root programs for serverAuth, and not subject to the CABF Baseline Requirements.

Additional affected certificate: https://crt.sh/?id=6221458302 - Revoked

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

The issuance of OCSP certificates from a Microsoft CA involves to use of a policy script which includes a low-level encoding of the KeyUsage. The operator generating the certificate used a script including incorrect encoding, which was not noticed. As part of the process, we run validation tests on the OCSP responders using openssl, we also test with one or more browsers (not Firefox in this case, unfortunately). None of the tests detected the issue with the encoding, so the tests were taken as successful.
Once the issue was later detected, we determined the cause and corrected the script, generating a new certificate.
At that point we didn’t consider relevant the revocation of the certificate, as these certificates are used during OCSP checking and they have the “OCSP No revocation Check” extension. WISeKey neither includes the CDP in the OCSP certificates.
The fact of this revocation not considered being relevant made that a mis-issuance incident, typically linked to a revocation incident, was not raised internally, so further actions weren’t taken.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future

WISeKey modified the generation script and process to generate OCSP-Responder certificates from the legacy Microsoft CAs in June'22 to avoid further occurrence of this issue. The process now includes the manual linting of the OCSP certificates in crt.sh.
After this incident report, we also modified our internal incident reporting process to ensure that we are also covering this and similar cases, so adequate treatment of a mis-issuance incident is performed even if there’s not a revocation incident associated. In this particular case there was already a communication with Mozilla, and it wasn’t identified the need to further action, but we think that even in that case it would have been adequate an incident report.
It must be also noted that the legacy infrastructure based on Microsoft Certificate Services is not used now for TLS certificates, and the current systems already implement automated pre-issuance linting.

Comment 3

[Ben Wilson]

I don't have any questions. Unless there are questions from others, I intend to close this on Friday, 4-Nov-2022.

Comment 4

[Mathew Hodson]

(In reply to Pedro Fuentes from comment #2)

4 (includes 5). Affected certificates

Reported certificate: https://crt.sh/?id=6946639612 - Revoked
It must be noted that this certificate is under a Root not anymore trusted by the root programs for serverAuth, and not subject to the CABF Baseline Requirements.

Additional affected certificate: https://crt.sh/?id=6221458302 - Revoked

I want to point out that you haven't included the correct link here. Your list doesn't include the originally reported certificate. https://crt.sh/?id=6946639612 isn't revoked. Accuracy and completeness is important for these reports.

Comment 5

[Pedro Fuentes]

(In reply to Mathew Hodson from comment #4)

I want to point out that you haven't included the correct link here. Your list doesn't include the originally reported certificate. https://crt.sh/?id=6946639612 isn't revoked. Accuracy and completeness is important for these reports.

Hi Mathew, thanks for making us note this .

You're totally right. Instead of listing the reported certificate https://crt.sh/?id=6039677462 (bad, revoked), I made a mistake and pasted the link to its replacement https://crt.sh/?id=6946639612 (good, non revoked).

Comment 6

[Ben Wilson]

Are there any other questions, comments, issues, or other items that still need to be resolved?