1528290 - Izenpe: OU > 64 characters

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

Izenpe reported the following misissuance to the mozilla.dev.security.policy list:

We have found that we've issued the following certificate with an OU > 64 characters.

https://crt.sh/?id=1202714390&opt=cablint

The certificate has been revoked some minutes later. We're retrieving all the information, we'll publish an incident report as soon as we have all the details.

Thanks
IZENPE

Comment 1

[Wayne Thayer]

Izenpe posted the following incident report to https://groups.google.com/d/msg/mozilla.dev.security.policy/FyZnXUbrsOI/gtMiRciVFgAJ:

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.
   

We have controls to detect any misissuance before and after the issuance of the certificate. The certificate was issued at 11:52, detected in the following minute, and revoked at 12:07

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.
   

Feb 14th 11:52 -> the certificate was issued
Feb 14th 11:53 -> the misissuance was detected
Feb 14th 12:07 -> the certificate was revoked
Feb 14th 13:28 -> reported the incident to our PKI software manufacturer
Feb 14th 15:24 -> received the answer from the manufacturer. They tell us that there’s a bug in the preventive filter with the OU, and that they have a hotfix to solve it.
Feb 14th 17:21 -> Izenpe reports to mozilla.dev.security.policy list

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.
   

We’ll do a dual manual check until we have the hotfix correctly applied

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.
   

There’s just one certificate affected

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.
   

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

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

It was a bug in the filter of the PKI software

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.
   

We hope to have the product hotfix applied by March 3rd

Comment 2

[Oscar Garcia]

My apologies for the delayed follow up response. First we must say that we don't see any benefit for the community of publishing the name and version of our PKI software, regardless of security issues.
As previously stated, we have two filters for each SSL certificate issuance. The "pre" one is integrated into the PKI software and it's obviously developed by the PKI manufacturer. The "post" one are really the three filters used in crt.sh, that is cablint, x509lint and zlint. Therefore we have different manufacturers for both filters. The previous one is supposed to review the TBS with the same conditions as the post one. In case of this misissued certificate it was immediately detected by the post filters.
After contacting the manufacturer we knew that the hotfix was available since last November. In this case we’ve already installed the hotfix in the development environment, and it’ll be in the production environment before next March 3rd. Meanwhile we’re reviewing manually with dual control all requests we receive.
We have defined some improvement actions, which could help other CAs to detect and fix these issues:

1. Apply cablint, x509lint and zlint also in the development environment, as the post-issuance filter
2. Request our manufacturer to categorize all patches and hotfixes they develop. At least there must be two categories: high if it applies to security issues or RFC/CABForum misissuances, and the rest. In case of patches classified as high, they must contact us immediately. We’re going to update our policy to require to put those patches in production in 15 days as a maximum. We’ll also suggest our manufacturer to communicate it also to all their customers.

All these actions will be applied in February.
Best regards

Comment 3

[Wayne Thayer]

Oscar: please update this bug when these actions are completed.

Comment 4

[Oscar Garcia]

We have already requested our manufacturer to categorize all patches they release. They have forwarded to their quality department, as a potential for improvement. It's still pending to apply the linters in the development environment.
Regards

Comment 5

[Oscar Garcia]

We have already put in the production environment the patch developed by the manufacturer to check that the OU is greater than 64 characters. We have also done the following tasks:

• Apply cablint, x509lint and zlint also in the development environment, as the post-issuance filter
• Generate a full test case kit, which we'll use to validate each patch we apply
• As previously reported we've requested our manufacturer to categorize all patches they release

With these tasks, we finish all improvement actions we'd planned.

Thanks

Comment 6

[Wayne Thayer]

It appears that all remediation actions are complete.