1551357 - Certinomis: certificates with invalid DNS SAN

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

Certinomis has misissued the following precertificates with an invalid DNS SAN (and common name) of "lrcopro.". Their OCSP responder is returning "unknown" for each one.

https://crt.sh/?sha256=54B392745B50D50F33FC06437831A3F9AE798E986F56E37FDB79E30D9D5093DA&opt=ocsp
https://crt.sh/?sha256=0A4A7E7ED97F6069772323DADB742C3053C7A55C856080D235DCD3AE92987052&opt=ocsp
https://crt.sh/?sha256=8E59E015A1603F681B51D201981813B2D7AE435BD7598D6618459BEFC4E14915&opt=ocsp
https://crt.sh/?sha256=15CF9B2BE5D6CCFD8DD37ABECC97512A0E2A9D5AC312EBA5B9AA1F3EFEEB04BB&opt=ocsp

Comment 1

[Wayne Thayer]

Please provide an incident report for this problem, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 2

[Ryan Sleevi]

Wayne: In light of this issue, should Bug 1539531 or Bug 1542793 be re-opened, both of which were closed on the basis of pre-issuance linting? I note that this bears remarkable similarity to the issue Andrew reported in Bug 1544933, which is still open.

In that issue, it was noted that "test and integration of it is suspended until we have successed in our main priority (pre-issuance linting)". So it would appear this was a previously known issue, and one which was supposed to be mitigated by linting.

Comment 3

[François CHASSERY]

Here is an incident report align the mozilla template :

1/ How your CA first became aware of the problem.
After opening of bug by Andrew AYER

2/ A timeline of the actions your CA took in response.

13/05/2019 15:35 : issuance of 4 pre-certifcate whithout the TLD
14/05/2019 : modification of certificate profile in the RA application to adress WEB CA instead of EASY CA

3/ Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.
Yes the problem is now corrected, it was a wrong settint in a certificate profile in the registration area "Maileva"

4/ A summary of the problematic certificates.
4 pre-certificates "lrcopro."

5/ The complete certificate data for the problematic certificates.
https://crt.sh/?sha256=54B392745B50D50F33FC06437831A3F9AE798E986F56E37FDB79E30D9D5093DA&opt=ocsp
https://crt.sh/?sha256=0A4A7E7ED97F6069772323DADB742C3053C7A55C856080D235DCD3AE92987052&opt=ocsp
https://crt.sh/?sha256=8E59E015A1603F681B51D201981813B2D7AE435BD7598D6618459BEFC4E14915&opt=ocsp
https://crt.sh/?sha256=15CF9B2BE5D6CCFD8DD37ABECC97512A0E2A9D5AC312EBA5B9AA1F3EFEEB04BB&opt=ocsp

6/ Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Pre-issuance linting is operational for issuance by Certinomis WEB CA et Certinomis SAFE CA
Certinomis EASY CA shall not issue certificates anymore.
In this registration area the setting for this certificate profile has been "forgotten" and remained on EASY CA

7/ List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future.
We stop any SSL certificate issuance for some days and will restart after a unit testing of every product in the RA application that none will adress EASY CA anymore.
For revocation of these pre-certificate just like all those of bug1551390 we have a meeting with EJBCA this afternoon to discover how to revoke a non-issued certificate

Comment 4

[Ryan Sleevi]

I don't believe the answers to Question 6 or 7 provide any meaningful assurance that the issue has been accurately described or the steps taken meaningfully fix it. This can be seen most obviously by the answer to Question 3, which describes details not at all present in Question 6, nor have any steps been taken in Question 7.

I do want to provide an opportunity to provide a thorough, detailed, and thoughtful analysis of the issue. Similarly, you may wish to update Question 2, which through its elision of the remaining text, omits all of the date and timestamps that understand when and how this issue was introduced, which is key to understanding Questions 3, 6, and 7.

Similarly, Question 4 doesn't provide the detail actually expected of the incident report, nor does Question 1 provide the "time and date", as required.

Thus, functionally, I think the only answers that meet the bare minimum requirements are those to Question 5, and that's because they were provided in the report. If the reporter should find other example certificates, I think we should take this as evidence of inability to handle incident response.

Comment 5

[Andrew Ayer]

Thus, functionally, I think the only answers that meet the bare minimum requirements are those to Question 5, and that's because they were provided in the report. If the reporter should find other example certificates, I think we should take this as evidence of inability to handle incident response.

I think the inability to handle incident response has already been well established by Bug 1551390 Comment 4, Bug 1524103 Comment 4, and Bug 1496088 Comment 9.

Comment 6

[François CHASSERY]

Dear Ryan,

Yes you are right, my answer is difficult to understand for somebody external to Certinomis because not enough detailed.

First, I explain background :

We have two separate PKI for operating our CA. The "oldest"one runs CA EASY, CA PRIME, CA AA&Agents that can issue SSL Certificate, plus some others that cannot. The "newest" runs CA WEB and CA SAFE that can issue SSL Certificate, plus some other CAs that cannot.

There is also an isolated RA Application which allows customer to make their certificate request, and RA operators to control and validate.
Customers as well as RA operators know only products. And it’s the configuration by the RA administrator that associates a product with a certificate template on a CA of one PKI. And the RA application is partitioned in logically separated area, one per delegated RA (External RA and Certinomis RA).
And settings of products shall be done area per area.

And now a new writing of the bug report aligned on Mozilla template :

1/ How your CA first became aware of the problem.
After opening of bug by Andrew AYER

2/ A timeline of the actions your CA took in response.

13/05/2019 15:35 : issuance of 4 pre-certifcate whithout the TLD
14/05/2019 : modification of the configuration of one product in the registration area "Maileva" of the RA application to adress a certificate template on WEB CA instead of adressing a certificate template on EASY CA
14/05/2019 : stop issuance on SSL certificates
14/05/2019 : begin of extensive check of SSL product configuration on the RA

3/ Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem.
Yes, the problem is now corrected in the registration area "Maileva" where it happenned, and no SSL certificate will be issued before every SSL product configuration will have been checked.

4/ A summary of the problematic certificates.
4 pre-certificates with domain name "lrcopro."

5/ The complete certificate data for the problematic certificates.
https://crt.sh/?sha256=54B392745B50D50F33FC06437831A3F9AE798E986F56E37FDB79E30D9D5093DA&opt=ocsp
https://crt.sh/?sha256=0A4A7E7ED97F6069772323DADB742C3053C7A55C856080D235DCD3AE92987052&opt=ocsp
https://crt.sh/?sha256=8E59E015A1603F681B51D201981813B2D7AE435BD7598D6618459BEFC4E14915&opt=ocsp
https://crt.sh/?sha256=15CF9B2BE5D6CCFD8DD37ABECC97512A0E2A9D5AC312EBA5B9AA1F3EFEEB04BB&opt=ocsp

6/ Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The decision was made to install pre-issuance linting in two actions : action 1 was installing pre-issuance linting on "newest" PKI, the one running WEB CA and SAFE CA; and action 2 was reconfiguration of all products in every RA area to adress certificate templates on WEB CA and SAFE CA.
Two considerations lead to that decision : fastening the implementation of linting and working around an issue encountered on EASY CA and AA&Agents CA for receiving CT Log answers.
The technical team had strong pressure to complete the installation of the linter by May 1st (this date was important because announced, and also because first fortnight of May is a period of low activity in France).
They realized the two actions as requested, and finished on time.
But at least one product in one RA area (Maileva) remained linked to EASY CA.
And the first certificate request on this External RA was by using a CSR, and the domain name was troncated at validation.

7/ List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future.
We stop any SSL certificate issuance for some days.
An extensive check of the RA configuration is in progress to be sure that none will adress EASY CA nor AA&Agents CA nor PRIME CA anymore.
Certinomis will not issue an SSL certificate before the end of that check (mid of next week).
For revocation of these pre-certificate just like all those of bug1551390 we had a meeting with EJBCA on tuesday; but the answer does not seem to be immediate on how to revoke a non-issued certificate. We are keeping investigating on this subject with them.

Kind Regards,

François

Comment 7

[Wayne Thayer]

The Certinomis Root CA is being removed from the Mozilla root store in bug 1552374, so I am resolving this bug. Additional comments that may be useful when considering any future application by Certinomis are welcome.