1692533 - Camerfirma: Old CAs with an RSA modulus size of 2047 bits

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ana Lopes]

Attachment: fingerprints_CA_2047.txt

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.146 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 became aware of the situation because we received an email from Michael Lettona informed us about it on February 5th.
   Affected CAs:
   AC Camerfirma and RACER (which is the CA that issues final entity certificates)

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.
   2.1. After receiving the information, we studied the affected certificates and gave all our clients a link to issue the new certificates from now on using a not affected CAs. (February 5-12th).
   2.2. We informed Michael about the current situation of Camerfirma regarding the affected CAs. (February 5th).
   2.3. We decided the strategy to solve the situation the best way possible. In this case, we will open another bug because the affected CAs will not be recognized by Mozilla after March 1st (find more information at https://groups.google.com/g/mozilla.dev.security.policy/c/PnAAWnxyosM) and we are immerse in a substitution process that will end by the end of the year, as we mention in the point 7. Action plan. (February 5-12th).

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.
   The CA stopped issuing certificates today.
   We provided the clients with a new link to issue certificates using another CA as soon as we knew the problem and we thought that nobody has used the old one again, but someone made a mistake, used it and issued the last certificate with problems this morning.
   After knowing the situation, we deactivated the affected profiles to avoid future errors and no we can assure that no certificates with this problem will be issued anymore.

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 40.510 problematic certificates issued.
   The first certificate with that problem was issued on 2014-01-02 at 12:44:31
   The last certificate with that problem was issued on 2021-02-12 at 10:59:11 because one of the clients used an old link to issue a new certificate by mistake.

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.
   Find the file attached.

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
   The bug was not detected because apparentely everything was correct. If you open the certificates with Microsoft Windows you can see a 2048 bits key.

7. List of steps your CA is taking to resolve the situation
   7.1. Enable another CA to issue all the new certificates. (already done)
   7.2. Give the clients a link to issue the new certificates from now on, using a not affected CA. (already done)
   7.3. We will open another bug for the delay because of the situation of Mozilla communicated the "Distrust for S/MIME After Date" to March 1, 2021, for the following older root certificates and request that Camerfirma send us the number of valid certificates in their hierarchies and when they expire:

• Chambers of Commerce Root - https://crt.sh/?id=1251
• Global Chambersign Root - https://crt.sh/?id=10249844
  Due to the fact that we have a plan to substitute all those certificates with our clients, we do not want to burden their operations for these next weeks.
  7.4. We will prioritize the substitution of the problematic certificates in the substitution process that we have established. We will give more details about the revocation deadlines as soon as possible.

Comment 1

[Eusebio Herrera]

To perform the susbtitution and revocation process in a organized way, we have divided the total amount of certificates in different batches .
We began the process on February 23rd by notifying this substitution process to the first batch of customers and we gave them one month to replace their certificates issued by this CA. After this month every certificate of that batch will be revoked.
So, the first 13.877 certificates will be revoked on March 23rd, .

According to our predictions, the last batch of certificates will be revoked by September 15th at latest.

We will update this bug with the revocation progress every time that any certificate batch will be revoked.

Comment 2

[Eusebio Herrera]

We updated the information about the revocation process in the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1692535. From now on, you will be able to find there all the new updates.

Comment 3

[Eusebio Herrera]

We do not have more updates for this bug. The revocation process is available at https://bugzilla.mozilla.org/show_bug.cgi?id=1692535.

Comment 4

[Eusebio Herrera]

We do not have more updates for this bug.