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