1524103 - Certinomis: invalid state and locality fields in subject

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

Certinomis has issued the following precertificate with the values "C=FR, ST=Direction Commerciale, L=Directeur Commercial et Marketing" in the subject:

https://crt.sh/?sha256=B50351E8ED25A6F170AB5DAFE7DD16EE1070984EF8BE4D393D449A171D5FF6BA

Certinomis has also issued numerous precertificates with "C=FR, ST=DPI-EXM-UP3, L=Administrateur Sécurité", such as:

https://crt.sh/?sha256=1B67BDC580695952D4BC65B049F47C2B49617718659C5884E210713B416F7DDB
https://crt.sh/?sha256=CCD7E781896B0167420D0657EBC87B58A342E0EB529B800C5786DF7EAE047309
https://crt.sh/?sha256=09D1E634369B5B2C19ACB6DE77C9350723E88B9ECD0A21CF898A59A7DAB048F7

These are clearly not real places and thus could not possibly have been verified per section 3.2.2.1 of the BRs.

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.
BUGZILLA FOR « TESTSCT.CERTINOMIS.COM »

HUMAN RA OPERATOR FOR :
«ppo-authent.contacts-neo.worldline.extranet.sf.intra.laposte.fr»
«ppo-ws.contacts-neo.worldline.extranet.sf.intra.laposte.fr»
«ppo-ws.contacts-neo.worldline.extranet.sf.intra.laposte.fr»

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

2019-01-08 09:24:10 UTC CREATION OF TEST CERTIFICATE FOR “TESTSCT.CERTINOMIS.COM”
2019-01-03 09:51:21 UTC CREATION OF PRE-CERTIFICATE FOR “ppo-ws.contacts-neo.worldline.extranet.sf.intra.laposte.fr “
2019-01-03 09:53:58 UTC CREATION OF PRE-CERTIFICATE FOR “ppo-ws.contacts-neo.worldline.extranet.sf.intra.laposte.fr “
2019-01-08 15:30:04 UTC CREATION OF PRE-CERTIFICATE FOR “ppo-authent.contacts-neo.worldline.extranet.sf.intra.laposte.fr”
2019-01-10 09:03:30 UTC CREATION OF CERTIFICATE FOR “ppo-authent.contacts-neo.worldline.extranet.sf.intra.laposte.fr”
2019-01-30 13:56:32 UTC CREATION OF CERTIFICATE FOR “ppo-ws.contacts-neo.worldline.extranet.sf.intra.laposte.fr”
2019-01-30 15:28 PST bugzilla openned by Andrew Ayer
2019-01-31 06:54 PST bugzilla assigned by Ryan Sleevi
2019-01-31 14:55 UTC notification from Bugzilla Bugzilla-daemon received in [e-mail] mailbox.
2019-01-31 14:55 UTC notification from Bugzilla Ryan Sleevi received in [e-mail] mailbox.
2019-02-01 09:39 UTC REVOCATION OF “TESTSCT.CERTINOMIS.COM”
2019-02-01 10:00 UTC REMIND THAT TEST CERTIFICATES SHALL FULLY APPLY THE ENROLLMENT PROCEDURE

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

Yes

4/ A summary of the problematic certificates.
«TESTSCT.CERTINOMIS.COM»
NO CERTIFICATE ISSUED «ppo-authent.contacts-neo.worldline.extranet.sf.intra.laposte.fr»
NO CERTIFICATE ISSUED «ppo-ws.contacts-neo.worldline.extranet.sf.intra.laposte.fr»
NO CERTIFICATE ISSUED «ppo-ws.contacts-neo.worldline.extranet.sf.intra.laposte.fr»

5/ The complete certificate data for the problematic certificates.

https://crt.sh/?id=1091522623
https://crt.sh/?id=1077338655
https://crt.sh/?id=1092681303
https://crt.sh/?id=1077342861

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

There is two different problems

For « testSCT.certinomis.com » a developer has issued a test certificates and he made a mistake when typing the request. Indeed, the fields in our request formula to enter “state” and “locality” are at the same place in the web page as the fields for “service” and “function” in personal certificate request formula. And it happened that the fellow entering the request was in a hurry and filled the zone as he use to do for personal certificates.
For this request the company name was constraint by the operator’s personal certificate and there is no link with a possible misapplication of 3.2.2.1 of BRs

For the 3 others certificates, the operator made also a mistake, perhaps for the same reason, but cancelled the request and eventually no certificates has been issued, and this the reason why this certificates cannot be revoked.
For these three requests the company name was constraint by the operator’s personal certificate and there is no link with a possible misapplication of 3.2.2.1 of BRs

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

1.   Remind to Certinomis’ operators to check carefully every request done for test 
   

2.   Plan training session with company RA operators 
   

For general purpose information, the existence and identification data of every company registered on our RA service has been controlled either by an automatic interrogation of French national database or by human interrogation of other EU countries national database. And no certificate, either SSL or personal certificate, can be issued before Certinomis has approved the registration of the company by one of these two methods.

Best regards
Marc MAITRE

Comment 3

[Wayne Thayer]

Given the reference to "test" certificates, this incident may be related to bug #1524112.

Marc: Why does Certinomis leave validation of the ST and L fields up to one individual operator? Regardless of the amount of training provided, your CA is still open to misissuance caused by human error. Why isn't ST restricted to a predefined list? I suspect that L could also be programmatically verified, but if not, why isn't there a second verification prior to issuance? Given the complete lack of controls over this process, how can Certinomis state in response to question #3 that issuance of certificates containing these errors has stopped?

Comment 4

[Andrew Ayer]

5/ The complete certificate data for the problematic certificates.

https://crt.sh/?id=1091522623
https://crt.sh/?id=1077338655
https://crt.sh/?id=1092681303
https://crt.sh/?id=1077342861

These are not the only problematic certificates. Here's another one, for example: https://crt.sh/?sha256=1AFD2996D6B3EE249AE1506ECA7E53CB1710471A27B6A020A29521E9FD9A0682 (note that this one is revoked)

For the 3 others certificates, the operator made also a mistake, perhaps for the same reason, but cancelled the request and eventually no certificates has been issued, and this the reason why this certificates cannot be revoked.

Per RFC6962 section 3.1, "The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate)". Your assertion that no certificates were issued carries no force and therefore you are required to revoke.

Comment 5

[Jonathan Rudenberg]

And here’s another: https://crt.sh/?id=405372511

In general there appears to be a lot of varying capitalization and no standardization (for example https://crt.sh/?id=2737480600) which makes it pretty obvious that this is unfiltered human input with no controls applied.

Comment 6

[Jonathan Rudenberg]

The second link should be https://crt.sh/?id=273748060 in comment 5.

Comment 7

[Andrew Ayer]

And here’s another: https://crt.sh/?id=405372511

This certificate is still unrevoked even though it has been three months since Jonathan reported it in Comment 5.

In addition, Certinomis is still issuing certificates with invalid states as recently as last week:

https://crt.sh/?sha256=F76B54B5E965CFD36A009E66DEFBAE4522688AA2D8F886542233DC2A44CB6323
https://crt.sh/?sha256=99B6C6726FA6E5E87B671E6EFDB6877C847359707B2BACDB83276335DEC40499

These two certificates have a postal code (92130) in the state field instead of just the department number (92).

Comment 8

[François CHASSERY]

Dear Andrew,

Thank you for the remind of https://crt.sh/?id=405372511.

This action was waiting for the customer’s response (the certificate was already in production when the bug was opened)
We insisted today on getting this agreement.
We got it.
I gave a derogation from my instruction yesterday, so that the certificate is produced (the configuration has been tested beforehand for this product).
The certificate will be issued this afternoon.
We will revoke the old certificate when the client will confirm us he installed the new one (we asked that this be done within the week)

Kind Regards,

François

Comment 9

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

Comment 10

[paul.leo.steinberg]

(In reply to Wayne Thayer [:wayne] from comment #9)

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.

It has been almost three months now and the certificate https://crt.sh/?id=405372511 from comment #8 is still not revoked.

If Certinomis were ever to reapply for inclusion in the Mozilla root store, extreme caution should be exercised regarding any promises given by them.