How we became aware of the problem:
We received an email at firstname.lastname@example.org (2019-01-29 19:17) in wich Jonathan Rudenberg advice us that we have three unrevoked certificates containing dnsNames with underscores.
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.
- Stop issuing certificates:
Since we put this control, we don't have issued any certificate with underscore in the dnsNames.
- Summary of the problematic certificates:
- Complete certificate data for the problematic certificates:
- 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)
- 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.