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.

Issue B: Lack of Responsiveness (2018 - Present)

In a 2017 misissuance bug, Cartinomis 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.

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

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.