1455147 - Camerfirma: Missing audit for Intermediate certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

The November 2017 Mozilla CA Communication included the following statement:

By April 15, 2018, all intermediate certificates (that chain up to root certificates included in Mozilla's program) that are capable of issuing S/MIME certificates but are not name constrained must be either audited and disclosed in the Common CA Database, or be revoked.

Camerfirma has failed to disclose audit information for the following intermediate CA certificate in CCADB as required by section 5.3 of the Mozilla root store policy:

https://crt.sh/?sha256=9ab25c1e795c85a321419d3062f84b52132baa8f718843a83e31fbf99fedc3d7&opt=mozilladisclosure

Please either add the required audit information to CCADB, or revoke the certificate if it has not been audited. Also please provide an incident report, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report
The incident report should be posted to the mozilla.dev.security.policy forum and added to this bug.

Comment 1

[Juan Angel Martin]

Attachment: Cert. eIDAS_QTSP DigitalSign VIC 2017.pdf

Comment 2

[Juan Angel Martin]

Hello Wayne,

I've updated the information required.

Best Regards
Juan Angel

Comment 3

[Wayne Thayer]

Thank you Juan. You have provided the audit certificate, but we ask for the audit report containing the information listed in section 3.1.4 of the Mozilla root store policy. Can you provide the audit report for this CA certificate?

Comment 4

[Juan Angel Martin]

Attachment: CAR

Hello Wayne,

I've updated the information required.

Best Regards
Juan Angel

Comment 5

[Wayne Thayer]

Thank you Juan. I have examined this audit statement and it appears to comply with Mozilla policy.

Unfortunately, two new intermediate certificates with CN="MULTICERT SSL Certification Authority 001" were recently issued, but they have not been disclosed within 7 days as required by Mozilla policy section 5.3.2:

https://crt.sh/?sha256=06a57d1cd5879fba2135610dd8d725cc268d2a6de8a463d424c4b9da89848696&opt=mozilladisclosure
https://crt.sh/?sha256=1defd59846cc2049ba1f1a74d3a8329d1357a2d47c1e1b0c15c27a8c60295455&opt=mozilladisclosure

Even though the second one has been revoked, it must still be disclosed.

Please add these certificates to CCADB and respond to this bug with an incident report explaining why these certificates were not properly disclosed, confirming that Camerfirma has checked and found no other intermediates certificates requiring disclosure, and explaining how this issue will be prevented in the future.

Comment 6

[Wayne Thayer]

Camerfirma posted the following incident report in response to my request in comment #5:

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 receive a communication via Buzilla from Wayne Thayer (https://bugzilla.mozilla.org/show_bug.cgi?id=1455147) on 2018-07-30 16:31:25 PDT). Wayne, thanks once again.

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.

The task about disclose the first CA certificate (https://crt.sh/?sha256=1defd59846cc2049ba1f1a74d3a8329d1357a2d47c1e1b0c15c27a8c60295455&opt=mozilladisclosure) was identified and planned prevouisly and it must be done once the certificate was issued on Jun 29 10:27:17 2018 GMT   

The second CA certificate (https://crt.sh/?sha256=06a57d1cd5879fba2135610dd8d725cc268d2a6de8a463d424c4b9da89848696&opt=mozilladisclosure) was issued on Jul 3 12:01:18 2018 GMT.

We’ve failed to perform the task about disclose the CAs into CCADB.

We've disclosed these certificates on July the 31th.

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

The procedure established to publish the CAs into CCADB wasn't correct cause it didn’t foresee the contingency of the person in charge of disclosing CA’s certificates into CCADB and the person acting as a backup weren’t available.

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're adding a third person as a point of contact into CCADB. We've already done the request and the person already has the necessary knowledge to manage this task.

Comment 7

[Juan Angel Martin]

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're adding a third person as a point of contact into CCADB. We've already done the request and the person already has the necessary knowledge to manage this task.

+++ We've modified our procedure to not deliver the intermediate CA certificate until it's disclosed in the CCADB.

Comment 8

[Wayne Thayer]

(In reply to Juan Angel Martin from comment #7)
> 
> +++ We've modified our procedure to not deliver the intermediate CA
> certificate until it's disclosed in the CCADB.

This doesn't really help you to comply - the policy requires a new intermediate to be disclosed within a week of creation and says nothing about when it is delivered to the customer or used to sign certificates.