1524871 - Camerfirma: failure to revoke underscores

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Jonathan Rudenberg]

Camerfirma failed to revoke the following certificates containing dnsNames with underscores that were required to be revoked by 2019-01-15 (CABF ballot SC12). I notified them via an email to their problem reporting address at 2019-01-29 18:17 UTC and received confirmation that my report had been received at 2019-01-30 09:27 UTC. Two were revoked over the next two days, one is still not revoked.

https://crt.sh/?opt=zlint&id=235049941
https://crt.sh/?opt=zlint&id=362345047 (not revoked)
https://crt.sh/?opt=zlint&id=892949039

Comment 1

[Ryan Sleevi]

Please provide an incident report, as per https://wiki.mozilla.org/CA/Responding_To_An_Incident

Comment 2

[Eusebio Herrera]

We are finishing the incident report and we will post it the next week.

Best regards

Comment 3

[Eusebio Herrera]

1. How we became aware of the problem:
   We received an email at [e-mail] (2019-01-29 19:17) in wich Jonathan Rudenberg advice us that we have three unrevoked certificates containing dnsNames with underscores.

2. Actions and Timeline to resolve:

a) Stop issuing certificates with dnsNames with underscores.
We deployed a control (11 January 2018) to avoid to receive certificate request with underscores in dnsNames.

b) Revoke the certificates issued prior to BR 1.6.2 publication that have dnsNames with underscores.
We revoked the three certificates.

3. Stop issuing certificates:

Since we put this control, we don't have issued any certificate with underscore in the dnsNames.

4. Summary of the problematic certificates:

https://crt.sh/?opt=zlint&id=235049941
https://crt.sh/?opt=zlint&id=892949039
https://crt.sh/?opt=zlint&id=362345047

5. Complete certificate data for the problematic certificates:

https://crt.sh/?opt=zlint&id=235049941
https://crt.sh/?opt=zlint&id=892949039
https://crt.sh/?opt=zlint&id=362345047

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

After the 1.6.2 version of BR was published(November 9, 2018), we made a report with the certificates issued with an underscore in their dnsNames. For making this report we execute queries to our database.

We detected 15 certificates, and we proceeded to revoke all of them before the deadline (2019-01-15).
On 29th of January Jonathan Rudenbert notified us at 19:17 about 3 certificates that we didn't revoked.
We read the advice from Jonathan and answer the next morning, the 30th of January)
We checked the report queries and found a human error in one of them. We’ve found a lack of two certificates (the third one is issued by one of our subCAs. Please read two lines below.
We spoke with our customers and we revoked the last of then the 4th of February at 2019-02-04 12:40:49 UTC.

One of the 3 certificates( https://crt.sh/?opt=zlint&id=892949039 ) is a certificate issued by one of our subCAs. So this is the incident report for this certificate mississued by our subCA Intesa Sanpaolo:
1) The CA was notified about the misissuance by email from Camerfirma, the 30th of January 2019
2) The certificate was revoked the 1st of February 2019
3) The CA software was modified and the Development team introduced an application control to verify that none of the DNS names included in the SAN contains prohibited characters (in this case the ' _ ' character).
In addition, the development team is integrating in the certificate generation procedure the invocation of a service provided by "AC Camerfirma, SA" that executes the checks of the precertificate with X509lint and CABLint, before sending the precertificate to the CT logs.
4) This is the only certificate generated with such problems: “Underscore should not appear in DNS names” and “DNSName should not have an underscore in labels left of the ETLD+1”
5) crt.sh ID: 892949039; SHA-256(Certificate): 80D5D9FCC8E22213E12645A4D025579571F1695705F8DD1565847788BB62FCCD https://crt.sh/?opt=zlint&id=892949039
6) When the certificate was generated there was no application control that avoided the presence of prohibited characters (In the specific case the underscore character)
7) See item 3)

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:

The next time that we must check the certificates issued to verify the certificates issued (i.e a BR update), we will make two reports made by different teams to avoid this human errors. We also have requested to our subCAs to improve the strengh of their reports.

In adition, procedures for notifying and accepting future BR and EV's requirements have been laid down.

Comment 4

[Wayne Thayer]

Thank you for this incident report. Please update this bug when the precertificate linting described in comment 3 has been implemented.

Comment 5

[Ryan Sleevi]

Any updates, or a concrete timeline to updates?

Comment 6

[Ryan Sleevi]

Emailed POCs on 2019-07-04 regarding this issue, highlighting https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed

Comment 7

[Juan Angel Martin]

(In reply to Wayne Thayer [:wayne] from comment #4)

Thank you for this incident report. Please update this bug when the precertificate linting described in comment 3 has been implemented.

It's expected that the linting described will be available in the second week of August.

Comment 8

[Juan Angel Martin]

The lint described is expected to be available by August 15.

Comment 9

[Juan Angel Martin]

The availability of this service has been delayed until August 22nd.

Comment 10

[Juan Angel Martin]

Camerfirma's lint service is available from 19 August at 7:10 UTC

Comment 11

[Wayne Thayer]

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