CA/Certinomis Issues

This page lists alleged issues involving the CA Certinomis (also known as Docapost). It may be further updated by Mozilla as more information becomes available. Please do not edit this page yourself; if you have proposed changes, send them to the mozilla.dev.security.policy list or email Wayne. Information here is correct to the best of Mozilla's knowledge and belief.

Certinomis currently has a single root certificate in the Mozilla program The “Certinomis - Root CA” was included in 2015 via bug #1169083 with only the websites trust bit set. The root is not EV-capable.

Issue A: StartCom Cross-signing (2017)

In 2017, Certinomis made the decision to sign two new intermediate CA certificates that were controlled by StartCom. This was at a time when StartCom had been recently distrusted and was misissuing test certificates from this new, replacement hierarchy. These cross-certificates were not disclosed until 111 days after being issued (the current one-week rule was not in force), and were issued prior to StartCom having completed new, successful audits that were required by their remediation plan before they could request reinclusion. The Certinomis cross-certificates were ultimately added to OneCRL and revoked by Certinomis.

[UPDATE 9-May in reply to the Certinomis Response]

Certinomis asked Mozilla to approve their plan to help Startcom, but when the cross-certificates were discovered, Gerv responded "This seems to be very different to the plan you implemented." By cross-signing Startcom's new roots, Certinomis assisted Startcom in circumventing the remediation plan, and by proposing one plan then implementing a different one, Certinomis did so without Mozilla's consent.

Startcom misissued a number of certificates (example) under that cross-signing relationship that Certinomis is responsible for as the Mozilla program member.

By cross-signing Startcom's roots, Certinomis also took responsibility for Startcom's qualified audit.

Issue B: Lack of Responsiveness (2018 - Present)

In a 2017 misissuance bug, Certinomis was called out for letting more than a month pass without providing a timeline for complying with the BRs.

In early 2018, Certinomis failed to respond to a Mozilla CA Communication. Certinomis was also late in responding to the prior November 2017 survey and had to be prompted, but no bug was filed. In both cases, the response stated that their representative was temporarily overloaded.

In November 2018, the primary representative of Certinomis in the Mozilla community and the CA/Browser Forum, Franck Leroy, left the company. Mozilla was informed of the change in representatives before it happened. The three representatives that have replaced Mr. Leroy have not previously been involved with the Mozilla program or the CAB Forum. Furthermore, the pattern of non-responsiveness continued under the new representatives: bug #1496088 (comments 12-17) ; bug #1495524 (comments 6 and 7) ; and bug #1503128 (comments 2 and 7).

Issue C: Audit Issues (2015-2018)

There are gaps in Certinomis’ audit coverage dating back to at least 2016. The 2015 assessment report is dated 28-April 2015, but the 2016 assessment report covers a period beginning on 13-May 2015 - a gap in audit coverage of 2 weeks. The 2016 report states that the next report is due before 13-May 2017. The 2017 assessment report states that is is valid from 24-July 2017, leaving a gap of almost 2 months of audit coverage.

The 2018 assessment report was due in October but not received until 23-November. There was originally a one week gap from the end of the previous audit to the beginning of the period covered by this latest report, but the auditor LSTI issued a new report that updated the start of the audit period. Certinomis stated that LSTI was at fault for the late audit statements, and while confirming the authenticity of the attestation statement, LSTI privately confirmed that they were the source of the delay.

Issue D: CP/CPS Non-conformities (Present)

The current version of the Certinomis CPS which was updated 25-November, 2018, does not comply with the Baseline Requirements:

• Section 1.5.2 doesn’t list problem reporting information, as required by section 4.9.3 of the BRs
• Section 3.2.3.3 states that Certinomis still uses banned domain validation methods 3.2.2.4.1 and 3.2.2.4.5, which have been forbidden since 1-August, 2018.
  • "Une preuve de possession par l'entité du nom de domaine correspondant au(x) FQDN pour les demandes de certificats d’authentification serveur. Les méthodes de validation des FQDN utilisable sont : BR3.2.2.4.1 (applicant identity), BR3.2.2.4.2 (email), BR3.2.2.4.3 (phone), BR3.2.2.4.5 (website change), BR3.2.2.4.7 (DNS change)."
• A thorough review of the current version of the CPS has not been completed because it is only published in French, in violation of a Mozilla required practice.

Issue E: Non-BR-Compliant OCSP Responders (2017)

Certinomis was one of a number of CAs whose OCSP responders were violating the BRs by returning “good” in response to a request for an unknown certificate. The effective date for this BR requirement in section 4.9.10 was August 2013.

Issue F: Non-BR-Compliant Certificate Issuance

Certinomis has accumulated a total of 13 misissuance bugs since 2017. Many are similar in nature, but I have attempted to categorize them below. As of 9-April, pre-issuance linting has not been implemented and Certinomis has stated that it is still some months away.

[CERTINOMIS RESPONSE] On 6-May, 2019, Certinomis stated that pre-issuance linting is now operational.

Issue F.1: SANs

In August 2017, Certinomis’ first CA compliance bug was filed. The errors were:

• Email address in DNSName in SAN
• Spaces in DNSName in SAN
• Serial numbers longer than 20 octets

On 29-November, 2017, the CA indicated that these problems had all been corrected and resolved in their production system.

On 1-October, 2018, a precertificate with a SAN containing only “www” was reported. This bug is still open (as of 9-April 2019) pending remediation including pre-issuance linting.

On 29-October, 2018, two new precertificates containing email addresses in DNSName SANs were reported. This was blamed on human error. On 3-April, 2019, Certinomis reported in comment 13 of the bug that one of their remediation action items was completed, and in the process disclosed two newly misissued certificates containing an invalid TLD in a SAN. The subsequent incident report disclosed three more misissued certificates and stated that the problem had been fixed. However, on the same day another certificate was misissued, this one containing an empty SAN value. The incident report for that issue disclosed one more nearly identical certificate issued 3 days later.

Another similar set of misissued certificates was reported on 27-March, 2019. These 10 certificates contain spaces in SAN values. Certinomis stated that the domains for those certs had been verified, but "This error happens only on sub domain validation with a long argument, only few iteration are done."

On 16-April, 2019, a set of 14 pre-certificates containing an unregistered domain name was reported. Certinomis explained this as human error and implied that a "new function for registration" would prevent this when deployed in June.

On 17-April, 2019, another pre-certificate having been issued on 17-April with a space character in the SAN was reported.

Issue F.2: Subject Organization

On 30-January, 2019, it was reported that Certinomis issued 4 certificates containing invalid State or Locality information. On 1-February, 2019, another misissuance in which the StateorProvinceName field contains “Direction des systèmes d'informations” was reported and that certificate was issued after the incident report had been filed claiming that Certinomis had stopped issuing certificates containing these errors.

Issue F.3: Inadequate Controls on Production Testing

On 31-January, 2019, bug #1524448 reported that Certinomis had issued 4 certificates that asserted the CAB Forum DV policy OID but contained forbidden organization information in the Subject. The explanation in the incident report is: “The guy in charge of testing the new CTlog function was not aware that test certificates shall be as true as real ones and he did not check the PKI configuration before issuing these certificates for testing the new function.”

Bug #1524112 filed on 30-January, 2019, reported that in January Certinomis also issued two certificates containing “O=POUR TEST” in the Subject. The initial response from Certinomis stated that this was “NOT A MISTAKE BUT A FEATURE” and went on to describe this as an acceptable method of testing.

A very similar problem had originally been brought to Certinomis’ attention back on 3-October, 2018. That problem had also been blamed on human error. A total of 7 certificates were revoked in that incident, including one with a SAN of “www.pourtest.com”. On 31-November, 2018, Certinomis reported that they would complete a remediation action item by the end of the year, to “implement domain validation in this workflow”, referring to the process used to issue certificates for testing. As of 9-April we do not have confirmation that this functionality has been implemented, although it was reported to be “running on pre-production platform” in February.

On 17-April, 2019, another certificate was reported. This one contains "O=Entreprise TEST" and was issued in January, after Certinomis stated that such issuance had been stopped.

CERTINOMIS RESPONSE (Summary): In November, certs requested from the "Front Office" system for "O-Entreprise test" were moved to non-PTC, but requests were still possible via the "Back Office" system, which is how this new certificate was requested. As of 25-April, the ability to request certificates via the "Back Office" system was disabled. The certificate was revoked and Certinomis confirmed that all other "test" certificates have been revoked or are expired. (full response)

Issue F.4: Validity > 825 Days

On June 26, 2018, Certinomis issued a certificate with a 3-year validity period, even though the BR effective date was 1-March, 2018, for not issuing certificates with a validity period greater than 825 days. The certificate was revoked 2 days later, but was not reported until bug #1524449 was filed in January. Part of the resulting incident report explained “one RA area has been forgotten and remain with a possibility of three years SSL certificates (this is the maximum duration for all our non-SSL certificates).”

Issue F.5: Invalid CDP Extension

On 31-January, 2019, it was reported that Certinomis issued two certificates in July of 2018 containing invalid CRL references in the CDP extension. One is https:// and the other is not a URI. One of these certificates was revoked on 22-February, 2019, and the other has not been revoked as of 9-April.

Issue G: Use of BR Domain Validation Method 3.2.2.4.5 After Deadline

The BRs set a deadline of 1-August, 2018 for CAs to stop using this method due to serious vulnerabilities that were identified. This concern was communicated in Mozilla's January 2018 and September 2018 CA Communications. In a bug that was recently filed describing the issuance of a certificate containing an unregistered domain name, Certinomis implied that BR method 3.2.2.4.5 was used to validate that certificate. Upon further questioning, Certinomis stated that BR method 3.2.2.4.5 was still in use.

[CERTINOMIS RESPONSE] Certinomis confirmed that the following comment form a former employee, is correct:

I think there is a misunderstanding; the validation process described by François is only applicable to French RGS server certificates with "clientAuth" key usage (so not under BR rules).

For PTC (i.e. with "serverAuth" key usage) on 1st August 2018 the only validation methods that shall be applied by RA operators are the well-known phone call process and the email validation to the addresses defined in the BR (webmaster@ admin@...).

Theses two validation methods were manual ones so subject to human errors. Before I left there was some developpement to allow the applicant to validate the domains before filling any application forms.

This new automated validation feature were to be available by the end of 2018.

I understand that this new feature has been developped and not yet used in production, and that a human validation error has been made by an RA operator confused by the fact that the organisation was "COMMUNE LE CANNET" and by the fact that the applicant made also an error in the CSR containing a '-' instead of a '.' to separate the domain name in the FQDN (mediatheque-lecannet.fr instead of mediatheque.lecannet.fr).

Certinomis later provided a detailed description of their domain validation processes.

Certinomis Response

The following response to all of the issues listed herein was posted to the mozilla.dev.security.policy discussion list on May 9:

Dear All,

Before detailing my answer, I would like to refute opinions that Certinomis does not take these subjects seriously: since February the management of Certinomis was directly involved in the exchanges with the Mozilla community, decisions were made and are implemented.

I acknowledge that I was surprised by the multiple topics that were grouped by Wayne THAYER on the CA/Certinomis issues page. I would also like to thank Wayne THAYER for his analysis of a technical point of view that distinguished different categories of problems.

For my part, my role is above all to advance the practice of Certinomis, and for this I must classify the problems according to their cause, because the best way to solve a problem is to correct its cause. And I will allow myself to structure my answer according to this classification that I made of problems, reserving for the end the Issue A (Startcom Signing) that I really did not expect to hear about.

- First cause of problems: An organization of the technical direction not adapted to the plan of charge in 2018

In 2018, Certinomis carried out several projects to renew its technical capabilities (new production site, new PKI software, adaptation to BR 1.6.5, among others). Franck as our Technical Director led all this work. And at the same time, Frank was Mozilla’s only point of contact. Inevitably there has been errors in settings (e.g. Issue F4 & F5) or incomplete corrections (Bug 1496088 comment#20 and answer that are part of Issue F3) and low reactivity (Issue B until November 2018) and perhaps editorial errors when updating PCs and DPCs (for example Issue D, rule 3.2.2.4.5 is mentioned in figures, but the description, in English, is that of rule 3.2.2.4.6)

-->Response to Cause 1:

- Action 1:

Franck’s departure was an opportunity to restructure Certinomis’ technical management with three roles for caring of SSL activity. - an internal audit team independent of the project management is in place; the structure that ensures it has implemented a daily linting post-issuance control since April 1st, to allow us to detect without delay any possible mistake. - An employee of the quality team of Certinomis will be designated as the main contact of the CA/B Forum and Mozilla (but not the only point of contact). To be complete on this topic the transition between Franck and another person had been prepared during the three months following his decision to leave. But it soon became clear that the person chosen was not fitted to the role. It is for this reason that I have resumed the discussion with Mozilla personally, and I intend to remain engaged on the subject until the situation is stabilized. -- PKI’s project management will carry out changes, settings and corrections.

The idea is to separate those who propose the evolutions, those who realize them and those who control them. In this way each one carries out his task without being inhibited by the constraints of the other.

- Second cause of problem: insufficient syntax control for certificate request processed by Enterprise RAs.

Several problems have been reported for certificates issued for the domains "laposte.fr" and "labanquepostale.fr". La Poste and La Banque Postale belong to the La Poste group, as well as Certinomis. For each of these two companies an external RA was set up by Certinomis, to facilitate the issuance of certificates on the two domains controlled by these two companies. The ownership of domain names and the authorisation of operators have been established beforehand. In this context, it has recently happened that CSRs generated by technicians on their servers are inserted by the operators in the AE software and that the syntax errors they contained are not highlighted by the RA software neither detected by operators (a space in a domain name, truncated domain names, empty SANs, function names instead of geographical indications etc. (Issues F1 & F2). Under no circumstances could these errors lead, or could lead, to the supply to an illegitimate person for this purpose of a certificate containing a real domain name.

-->Responses to Cause 2:

- Action 2: Entreprise RAs have been temporarily deactivated to allow us to correct this situation.

- Action no. 3: The action carried out as a priority was to install the pre-issuance linting. It is now operational as we committed to.

- Action 4: The next action will be to strengthen control on the locality field in these external RAs.

- Third cause of problem: human-based registration.

Several certificates were issued in good faith for testing by operators of Certinomis (Issue F3). To understand, it is necessary to know that for our other ranges of certificates, it is sometimes necessary to provide a test certificate from the production CAs, for the purpose of testing complex applications from end to end. Well, in those cases, the operator must display the word "TEST" in the significant fields; and in order that the invalidity of these certificates be even more evident to third parties who rely, we have, voluntarily, created fictitious organizations whose name is intended to make evident this fictitious character, and above all, also a fictitious organization identifier. The objective is that no one can be misled with any of these certificates.

This practice is forbidden by the CA/B Forum, I do not discuss it, and simply I explain why the operators of Certinomis could have made these errors.

Another error related to human control occurred in February 2019: the town hall of Le Cannet, client of Certinomis for several years, was mistaken in writing its application form and requested a domain name "mediatheque-lecannet.fr" instead of "mediatheque.lecannet.fr". And the Certinomis RA operator did not notice that instead of a dot there was a dash. The employee who validated this request made an indisputable error, even though I am convinced that his vigilance would have been stronger for an unknown client.

--> Responses to cause 3:

- Action no. 5: for test certificates, the solution was to isolate the test organizations in a registration area where PTC SSL certificates are not available. This solution is now fully in place.

- Action no. 6: Certinomis has developed a function for sending e-mails in accordance with BR 1.6.5 method 3.2.2.4.4 This function will be in production by May 15, and then it will no longer be possible for a human operator to add or validate a domain name without a positive response according to 3.2.2.4.4

On these three main causes of problem, Certinomis has already started to act, certain actions have been completed (action n°2, action n°3, action n°5) one is partially completed (action n°1) and the others will be completed within a maximum of one month (action n°6) or two months (action n°4). And our efforts will not stop, other improvements are already in the works and will have to be added to our road map (implementation of method 3.2.2.4.6 for example).

I don’t want to finish this answer without going back to the A issue, the Startcom cross-sign. I will not repeat all the history, Franck LEROY had detailed it in his e-mail of 07/08/2017 at 11.21:46 (UTC+2), but simply summarize my point of view: at no time did we in this case violate an existing rule, nor did we assist or seek to assist Startcom in circumventing the remediation plan proposed by Mozilla; on the contrary, we asked the Mozilla staff beforehand if what we wanted to do was acceptable, we clearly made it a condition for Iñigo to follow the plan and waited to be convinced that he had done so, and when, after all these precautions, we were told that we had not understood this remedial plan, we revoked both CAs without discussion. I hadn’t heard anything about it in those two years. So what is the factual criticism that is being made now, two years later? I don’t know about that. And what is the link with our difficulties of this year? None!

In conclusion, I would like to remind you that Certinomis, although a modest player in the SSL business, is a respectably well-known company in France, qualified for several ranges of certificates, and which provides personal signature certificates for many organizations, large companies, ministries and local communities.

This good reputation does not justify the errors that are currently highlighted.

But this fame was not obtained by chance, and on the contrary, it is a testament to our know-how, our work and the rigour we put into it.

And I believe that considering this is likely to reassure the Mozilla community and restore its confidence: It’s true that we have been initially destabilized by the barrage of questions and bug notifications that started just after the departure of our former technical director Franck LEROY. But the attention paid to this issue over the past three months and especially the rapid progress of our action plan show that we are taking these matters seriously and that we are able to play our role as a CA as well in the rules of the CA/B Forum than in the other rules to which we are subject.

Kind Regards,

François CHASSERY CEO Certinomis