1524112 - Certinomis: test certificates, O=POUR TEST in subject

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

Certinomis has issued the following two precertificates with O=POUR TEST in the subject. I assume this is not an actual organization.

https://crt.sh/?sha256=D8BB79921F071E79DF4AF149D81A85394BFAD39BE0EEF9A61478CB882D0D8833
https://crt.sh/?sha256=5C2BA9567CBE61587218BE7E7A69B54290553B2585332578F26444271C28E5DD

Comment 1

[Ryan Sleevi]

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

Comment 2

[Marc MAITRE]

Hello,

1/ How your CA first became aware of the problem.

I've been aware by this bug opened by Andrew Ayer and affected to me by Ryan Sleevi.

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

2018-11-20 14:01:11 UTC CREATION OF A TEST CERTIFICATE FOR “TEST2011.CERTINOMIS.COM”
2019-01-08 09:24:10 UTC CREATION OF TEST CERTIFICATE FOR “TESTSCT.CERTINOMIS.COM”
2019-01-30 15:59 PST bugzilla openned by Andrew Ayer
2019-01-31 06:53 PST bugzilla assigned by Ryan Sleevi
2019-01-31 06:54 PST bugzilla status change from UNCONFIRMED to ASSIGNED by Ryan Sleevi
2019-01-31 14:54 UTC notification from Bugzilla Bugzilla-daemon received in [e-mail] mailbox.
2019-01-31 14:54 UTC notification from Bugzilla Ryan Sleevi received in [e-mail] mailbox.
2019-02-01 10:39:31 UTC Revocation of “testSCT.certinomis.com”
2019-02-01 16:42:23 UTC Revocation of “test2011.certinomis.com”

3/ Whether your CA has stopped, or has not yet stopped,

Yes

4/ A summary of the problematic certificates.

« TEST2011.CERTINOMIS.COM »
« TESTSCT.CERTINOMIS.COM»

5/ The complete certificate data for the problematic certificates.

https://crt.sh/?id=962044175
https://crt.sh/?id=1091522623

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

NOT A MISTAKE BUT A FEATURE

The access to our RA service is conditioned by the use of a personal digital certificate on smart card.
We have some delegated RA for big companies and to oblige their operator to issue only certificates for their company, the RA software has been coded so that it introduce in the SSL certificate request the identity (NAME and ID number) of the operator’s certificate.
When they need to perform a test, our employees has personal certificates issued for a fictive company name (“POUR TEST” which means “FOR TESTING”) BUT a real Company ID Number, that is derived of ours (433998903) so that (1) the developer cannot engage a real company with its certificate and (2) a link with Certinomis remain for any use if this certificate.
When requiring a test certificate “test2011.certinomis.com” the company information of the operator certificate are forced into the SSL certificate request

7/ List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future.

From Certinomis point of view there is no security issue :(1) nobody would have given any trust to these certificate clearly identified as TEST certificates and (2) these certificates has of course not been used for production services exposed publicly
If necessary we can forbid the developer to test and ask for an executive to test with a real personal certificate, but this way of doing does not seem appropriated in such a situation.

Best regards
Marc MAITRE

Comment 3

[Ryan Sleevi]

Marc, could you provide insight into how Docapost/Certinomis has evaluated the above description to be compliant with the Baseline Requirements?

That is, the Baseline Requirements do not provide distinction based on "look like test certificates" or "can't be used for production services", and as such, these are violations of the Baseline Requirements.

I cannot stress more the level of concern with the present response, in combination with Bug 1524094 and Bug 1524103.

Please also review Certinomis/Docapost's reply to Mozilla's March 2016 communication ( https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00009 ), which y'all stated:

"I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates."

Comment 4

[Wayne Thayer]

In addition, how does "the company information of the operator certificate are forced into the SSL certificate" meet the BR requirements for validating Subject information when the operator certificate lists a real company?

Assuming that there is no valid explanation for issuing a publicly-trusted (pre-)certificate containing known false information, please focus your response on how and why Certinomis assumed that this was permitted and what Certinomis will due to ensure that BRs are followed rigorously going forward.

Also, have you notified your auditor of this (and the other recently discovered) issue?

Comment 5

[François CHASSERY]

Hello,

First I want to explain how our registration system works presently:

1. There are two ways for an SSL certificate application in our RA system:

• Common workflow :
  o At first application for a legal person (we don’t provide natural persons with SSL certificates) the existence of it is verified by interrogation of a public data base.
  o At first application by a new representative its e-mail is controlled by sending an e-mail to the applicant representative, that includes a clickable url.
  o At first application of the company a proof of incorporation is required (https://www.infogreffe.fr/documents-officiels/demande-kbis.html)
  o Then the applicant’s representative enters its request specifying the DNS that have to be included in the certificates.
  o Double human control with method 1,2,4,5 of §3.2.2.4 of BR for domain name control, and for the “extrait Kbis”
  o Passed a period of three years, the first request demand the supply of a new “extrait Kbis”.
• Enterprise RA workflow :
  o Control of existence of the company as above;
  o Registration of the RA operator with (i) a signed request from an accredited representative and (ii) a copy of one official ID document (ID national card or passport or resident card);
  o Registration of authorised domain names for this RA, by using methods 1,2,4,5 for BR domain name control;
  o Supply of a personal certificate on smart card valid three years to the operator;
  o Passed a period of three years, the first request demand the supply of a new extrait Kbis.
  In these two SSL workflows, the RA software check that required DNS are FQDN.

2. It is also possible through a distinct and different workflow to request internal server certificates, whose DNS may not be FQDN. This workflow is named “Corporate”, it is linked to a certificate profile named “Corporate” which is linked to our “Corporate CA”, non-publicly trusted.

And now I am going to answer separately to the three bug discussions, because these are three different events, who calls for three distinct answers:
Bug 1524103 : we do not have an automatic control on “state” and “locality” and relies on human controls.
 It is possible in a short term perspective to add a dropdown list of the 18 French “region” (the first subdivision of our country, as are States in the USA) and to suppress the “Locality Field”.
Bug 1524112: we rely on controls made before the issuance of the operator’s certificate to control company information, by replicating these information in the SL certificates of an Entreprise RA. So it was a mistake to register as an operator a certificate with only the company identifier true.
 It is possible in a short term perspective to force only the name of the organisation owning the RA in the SSL certificates.
Bug 1524094 is related to the departure of our former CTO who had a complete knowledge on BR rules.

• We have been asked by an important customer to implement a VENAFI connector, which is supposed to pilot all certificates request for an Enterprise RA.
• The specification for this development focused on the protocol with VENAFI but don’t mention that a check must be done to guaranty that DNS are FQDN;
• the developer then started from an existing workflow, the “Corporate one” without these controls;
• Once ready, the new workflow has been tested as conform to the specification (ability to create and revoke a certificate through VENAFI protocol);
• Once receipt pronounced it has been installed in production to demonstrate the result to VENAFI fellows;
• For testing the operator entered only his name in place of a FQDN;
• As no control had been included in the specification it worked;
• And as we use to issue test certificates on real CA for purposes other than the SSL, the PM did not pay enough attention to the wrong DNS problem, because they were test certificates already revoked.

 Immediate decision : the VENAFI development is frozen and wil restart from its beginning.
 second answer is organisational: We must treat the BR conformity in a different way than the conformity to other frameworks.
 I have read today the BR policy. I will designate someone in our organisation that will follow this subject, and from now on, no change will occur in SSL certificates services, including CPs, certificates profile or workflows, prior acceptance by the quality control and validation by myself.

and last point, I have informed today our auditor of these three bug discussions.

Remaining at your disposal,

Kind regards,

François CHASSERY
CEO
Certinomis

Comment 6

[Wayne Thayer]

Francois: thank you for this additional information.

You have indicated that Organization validation is valid for 3 years. How does this meet the BR requirement that all information placed in a certificate be revalidated at least every 825 days?

You have not addressed the issue that Certinomis was performing testing using a publicly-trusted certificate hierarchy. Please be aware that there is no such thing as a "test" certificate that chains to a publicly-trusted root. How do you plan to solve this problem?

Also, please update this bug when a person in the organization has been designated to follow and ensure compliance with the BRs.

Comment 7

[François CHASSERY]

Dear Wayne,

I understand your first question comes from "Passed a period of three years, the first request demand the supply of a new “extrait Kbis”.
I need to explain and give more details : our registration application software generates every three years a registration file that include an additional form sheet "Enregistrement de l'Organisme". And this form sheet describe the organisation and ask for an evidence, that is an "extrait Kbis" for companies, and an "avis de situation sirene" for non commercial organisations.
But for SSL PTC we have to care about a different time frame. That's why we added in the procedure that our operators shall control the organisation existence and location in a public external database for any request, and one per year for enterprise RA.

The second problem, creating SSL "test" certificates is now prevented as follow : all our "test" organisations has been grouped in a specific RA that cannot ask for SSL PTC certificates. In this RA (DEMO ZONE), only personal certificates are available under the publicly trusted root and SSL certificates are available only under a non-publicly trusted root.

Kind Regards,

François

Comment 8

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