Camerfirma: failure to revoke underscores

ASSIGNED
Assigned to

Status

task
ASSIGNED
7 months ago
3 days ago

People

(Reporter: jonathan, Assigned: eusebio.herrera, NeedInfo)

Tracking

trunk

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ca-compliance] - 22-August 2019)

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

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

Assignee: wthayer → eusebio.herrera
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(eusebio.herrera)
QA Contact: kwilson → wthayer
Whiteboard: [ca-compliance]

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

Best regards

Flags: needinfo?(eusebio.herrera)
  1. How we became aware of the problem:
    We received an email at incidentes@camerfirma.com (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.

  1. Stop issuing certificates:

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

  1. 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

  1. 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

  1. 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)

  1. 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.

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

Flags: needinfo?(eusebio.herrera)

Any updates, or a concrete timeline to updates?

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

(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.

Whiteboard: [ca-compliance] → [ca-compliance] - 15-August 2019

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

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

Whiteboard: [ca-compliance] - 15-August 2019 → [ca-compliance] - 22-August 2019
You need to log in before you can comment on or make changes to this bug.