1624658 - Camerfirma: BR revocation period exceeded

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ana Lopes]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36

Steps to reproduce:

This bug is open as a requirement for the delay in the revocation of the certificates included in the Bug 1623384.

Actual results:

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.
   See initial bug https://bugzilla.mozilla.org/show_bug.cgi?id=1623384

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.
   1º https://bugzilla.mozilla.org/show_bug.cgi?id=1623384
   2º Posting of this incident report

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.
   See initial bug https://bugzilla.mozilla.org/show_bug.cgi?id=1623384

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 initial bug https://bugzilla.mozilla.org/show_bug.cgi?id=1623384

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.
   See initial bug https://bugzilla.mozilla.org/show_bug.cgi?id=1623384

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   As we advanced in the initial bug, the delay in the revocation has been caused because some of our clients are having problems to mantain their normal activity because of the COVID-19.

We notified the necessity to revoke the certificates and we proceeded normally with our revocation process, but those clients asked us for a extension so that they can install the new certificate before revoking the previous ones because they cannot afford the interruption of their critical services (energy and communications) right now.

Please, find below the affected domains, so that you can figure out the importance of the services that they provide:
1 doit.movistar.com.pe (Perú)
2 *.davicloud.com (Perú)
3 webgia.eredesdistribucion.es (Spain)
4 webgiapre.eredesdistribucion.es (Spain)
5 www.edpenergia.es (Spain)

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.
   To solve the situation as soon as possible, Camerfirma has completed all their tasks in time, so that the clients have their new certificates in time and they can install them as soon as they have the possibility.
   The action plan contains the following steps:

• Communication of the situation to the clients (the error in the certificates) (already done)
• Initialize the process to substitute all the problematic certificates (already done)
• Arrange a susbtitution, installation and revocation timeline with the clients (already done)
• Revocation of all the certificates (by March 30th)
• Incorporation of additional individual clauses for all our clients wherein they have to accept that we will revoke all the certificates with any errors in a period of 5 days to comply with the CABForum requirements even without their explicit acceptance at that time (April 15th)

Comment 1

[Ryan Sleevi]

(In reply to Ana Lopes from comment #0)

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   As we advanced in the initial bug, the delay in the revocation has been caused because some of our clients are having problems to mantain their normal activity because of the COVID-19.

We notified the necessity to revoke the certificates and we proceeded normally with our revocation process, but those clients asked us for a extension so that they can install the new certificate before revoking the previous ones because they cannot afford the interruption of their critical services (energy and communications) right now.

Please, find below the affected domains, so that you can figure out the importance of the services that they provide:
1 doit.movistar.com.pe (Perú)
2 *.davicloud.com (Perú)
3 webgia.eredesdistribucion.es (Spain)
4 webgiapre.eredesdistribucion.es (Spain)
5 www.edpenergia.es (Spain)

Thanks for sharing these details. Based on this, I've tagged this as [covid-19], indicating that it's a compliance issue associated with the Coronavirus pandemic.

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.
   To solve the situation as soon as possible, Camerfirma has completed all their tasks in time, so that the clients have their new certificates in time and they can install them as soon as they have the possibility.
   The action plan contains the following steps:

• Communication of the situation to the clients (the error in the certificates) (already done)
• Initialize the process to substitute all the problematic certificates (already done)
• Arrange a susbtitution, installation and revocation timeline with the clients (already done)
• Revocation of all the certificates (by March 30th)
• Incorporation of additional individual clauses for all our clients wherein they have to accept that we will revoke all the certificates with any errors in a period of 5 days to comply with the CABForum requirements even without their explicit acceptance at that time (April 15th)

Thanks for the clarity here. I'm setting the next update as 2020-03-30 based on this, as well as setting the need-info, to provide an update the revocation was performed then.

As you're not the first CA that has run into this regarding Subscriber Agreements, I've also filed https://github.com/cabforum/documents/issues/172 to track the possibility of making this a standard part of the Baseline Requirements-required Subscriber Agreements.

Comment 2

[Ana Lopes]

We want to inform you that all the pending certificates with errors have already been revoked as we have updated in the Bug 1623384 .

Comment 3

[Ryan Sleevi]

Thanks. I've updated the Next-update based on

Incorporation of additional individual clauses for all our clients wherein they have to accept that we will revoke all the certificates with any errors in a period of 5 days to comply with the CABForum requirements even without their explicit acceptance at that time (April 15th)

Comment 4

[Ana Lopes]

Regarding the last step that we defined “Incorporation of additional individual clauses for all our clients wherein they have to accept that we will revoke all the certificates with any errors in a period of 5 days to comply with the CABForum requirements even without their explicit acceptance at that time” that we planned for April 15th, we want to inform that we already incorporated extra information for all our new clients that they have to accept during the “user registration” process.

The clauses that we have introduced are the following:
“By ticking this checkbox, I assume to know the points 21 and 22 of the use conditions and accept its implications specifically, in particular:

• The possibility for CAMERFIRMA to revoke the certificate after the 24-hour period after the detection of a security incident or 5-calendar day period in case of a format or content problem in the certificate, without the possibility to claim any compensation.
• In those cases, CAMERFIRMA will contact the subscriber to substitute the certificate before its revocation and they will have to collaborate with CAMERFIRMA to carry on with that substitution within the deadlines without any additional cost for the user.
  By defect, the contact data will be the referred to the present form.
  In case that you want to communicate other data, you will have to communicate it to e-mail address [e-mail]. In case of impossibility to contact the subscriber within the given deadlines, CAMERFIRMA will revoke the certificate unilaterally.”

For old clients, we also sent the following reminder by e-mail related to the conditions that they accepted when they acquired the certificate:
“Dear user,
As you know, the activity of CAMERFIRMA as a provider that issues secure server certificates (SSL OV y EV), has a compromise with the compliance of CA/B Forum rules.
In that sense, in the points 21 and 22 of the use conditions, you accepted specifically the possibility for CAMERFIRMA to revoke your certificate 24 hours after detecting a security incident or after 5 calendar days after detecting a format o content problem, without the possibility to claim any compensation. That revoked certificate will be substituted by another one without any cost for the user.
In those cases, CAMERFIRMA will contact the certificate subscriber to substitute the certificate before its revocation, and they will have to collaborate with CAMERFIRMA to carry on with that substitution within the deadlines without any additional cost for the user.
In case of impossibility to contact the subscriber within the given deadlines, CAMERFIRMA will revoke the certificate unilaterally, following CA/B Forum specifications.
The purpose of this communication is to remind you that clause in order to:
i) Check the contact information indicated during the subscription process to verify if it is correct to comply with the necessity to revoke and, if desirable, provide new contact information to the e-mail address [e-mail]
ii) Take the opportunity measures to enforce the compliance of that obligation (Contingency Plan)

Our compromise with the security and the regulatory compliance is the value of our services and we really appreciate your full collaboration in reference to the object of this communication, so that we all together make them follow complying with the international standards.”

Comment 5

[Ryan Sleevi]

I think this represents the completion of all steps outlined, and all the questions asked.

Wayne, to you if you had further questions, as I understand you're still doing final review for Mozilla.

Comment 6

[Wayne Thayer]

It appears that all questions have been answered and remediation is complete.