1623389 - Camerfirma: Invalid authorityKeyIdentifier - recurrent incident

Status: RESOLVED DUPLICATE of bug 1623384

(CA Program :: CA Certificate Compliance, defect)

Description

[Ana Lopes]

Attachment: List of affected certificates

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

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.
   We were first aware about the problem when Michel Le Bihan included that information in the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1586860#c15

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.
   Steps to solve the problem in the past (you can find the information in detail in the bug 1586860 - https://bugzilla.mozilla.org/show_bug.cgi?id=1586860)
   1º Development to change the affected profiles (October 8th, 2019)
   2º Pass of the changes to production (Oct 25th, 2019)
   After detecting the problem again we have performed and planned the following actions:
   1º Michael Le Bihan's detected the new errors and include a new comment in the previous bug https://bugzilla.mozilla.org/show_bug.cgi?id=1586860#c15 (March 11th)
   2º We gave response to the comment and the two certificates detected (both of them were pre-certificates) were revoked immediately (March 11th).
   3º We examined the versión of the zlint that we were using (March 11th)
   4º We investigated all the profiles to detect all the profiles with errors in use (March 11th)
   5º Install the new versión of zlint 2.0.0 (March 12th)
   4º Change the profiles with errors (March 13th)
   5º Test the new profiles (March 13th)
   6º Pass the new profiles to the production environment (March 16th)
   7º Incoporate as part of the procedure for the Operations department to check the profile with Zlint manually before issuing the first certificate of each kind of profile (March 16th)
   8º Revocation of all the affected certificates (by March 20th)
   9º Substitution of all the revoked certificates (by March 20th)
   10º Modification of the procedure for the correction of the profiles and establishment of an aditional automatic control to verify the AKI before the issuance of the certificates (by April 1st)
   11º Establishment of a procedure to detect all the new versions of the zlint deployed. We will receive a notification every time there is a new update of the zlint version and the department responsible of this tool will decide if the update must be pass to production.
   In parallel we are analysing the possibility of establishing an automatic procedure to detect all the new versions of the zlint deployed and update the version in the production environment every time a new version is available without manual intervention. (March 18th)

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 have stopped issuing certificates since we received the communication. The last certificate was issued on March 10th.
   We started to issue certificates again on March 16th after correcting all the affected profiles.

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.
   We have detected 37 active certificates affected by this problem. Three of them have already been revoked.
   The first certificate affected was issued on Dec 12th and the last one on March 10th.
   Regarding the profiles, we have detected 85 profiles with errors and we have already changed all the affected profiles.

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.
   Please, find the list of affected certificates attached.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   We took measures to solve the problems detected in the previous bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1586860)
   We had not been conscious about the repetition of the problem until the communication because the version of Zlint that we were using had not detected it.
   After reviewig the corrections and tests that we made in the past to correct the profiles detected in the previous bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1586860), we have noticed that the procedure that we conducted was not effective and we did not detect it before the comment of Michel Le Bihan.

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.
   1º Revocation of the detected certificates (March 11th)
   2º Analyses of the cause of the problem (March 12th)
   3º Updating of the version of zlint (March 12th)
   4º Elaboration of a list with all the affected certificates and communicated it to the Operations department to revoke all of them (March 13th)
   5º Correction of the problematic profiles (March 16th)
   6º Communication of the revocation and the susbtitution of the problematic certificates to all the clients
   7º Revocation of all the problematic certificates (by March 20th)
   8º Substitution of all the problematic certificates (by March 20th)
   9º Modification of the procedure for the correction of the profiles and establishment of an aditional automatic control to verify the AKI before the issuance of the certificates (by April 1st)
   11º Establishment of a procedure to detect all the new versions of the zlint deployed. We will receive a notification every time there is a new update of the zlint version and the department responsible of this tool will decide if the update must be pass to production.
   In parallel we are analysing the possibility of establishing an automatic procedure to detect all the new versions of the zlint deployed and update the version in the production environment every time a new version is available without manual intervention. (March 18th)