Closed Bug 1265683 Opened 3 years ago Closed 8 months ago

Add [Certigna Root CA] root certificate(s)

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: j.allemandou, Assigned: kwilson, Mentored)

References

Details

(Whiteboard: In NSS 3.41, Firefox 65)

Attachments

(9 files, 13 obsolete files)

164.20 KB, application/pdf
Details
168.96 KB, application/pdf
Details
415.53 KB, application/pdf
Details
305.71 KB, application/pdf
Details
187.89 KB, application/pdf
Details
644.93 KB, application/pdf
Details
253.70 KB, application/pdf
Details
41.39 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
301.12 KB, application/pdf
Details
Attached file LSTI - Certification audit 2016.pdf (obsolete) —
CA Details
----------

CA Name: Certigna Root CA
Website: www.dhimyotis.com; www.certigna.fr
Organizational type: Private corporation. DHIMYOTIS is the name of the company and Certigna is the brand for their certificates.
Primary market / customer base: DHIMYOTIS is one of the biggest French CAs which issues qualified certificates for general public, public administrations and privates companies. The CA focus its activities in France and worldwilde.

Audit Type (WebTrust, ETSI etc.): ETSI TS 102 042 / 101 456
Auditor: LSTI
Auditor Website: http://www.lsti-certification.fr
Audit Document URL(s): Attachment + http://www.lsti-certification.fr/images/liste_entreprise/Liste%20PSCe

Certificate Details
-------------------
(To be completed once for each certificate; note that we only include root
certificates in the store, not intermediates.)

Certificate Name: Certigna Root CA
Certigna Root CA | Key CertSign (5) + CRL Sign (6) | ETSI TS 102 042

Identity CA 
Chiffrement | Key Encipherment (2) | ETSI TS 102 042 LCP
ID RGS* | Digital Signature (0) + Non Repudiation (1) | ETSI TS 102 042 NCP+

Identity Plus CA 
ID RGS** | Digital Signature (0) + Non Repudiation (1) | ETSI TS 102 042 NCP+
ID RGS*** | Non Repudiation (1) | ETSI TS 101 456 QCP+
Authentification RGS *** | Digital Signature (0) | ETSI TS 102 042 QCP+

Entity CA 
Cachet Serveur RGS * | Digital Signature (0) + Non Repudiation (1) | ETSI TS 102 042 LCP
Cachet Serveur RGS ** | Digital Signature (0) + Non Repudiation (1) | ETSI TS 102 042 NCP+

Entity Code Signing CA
Signature de code RGS* | Digital Signature (0) | ETSI TS 102 042 LCP
Signature de code RGS** | Digital Signature (0) | ETSI TS 102 042 NCP+

Services CA
SSL Serveur RGS* | Digital Signature (0) + Key Encipherment (2) | ETSI TS 102 042 LCP
SSL Client RGS* | Digital Signature (0) + Key Encipherment (2) | ETSI TS 102 042 LCP

Wild CA
SSL | Digital Signature (0) + Key Encipherment (2) | ETSI TS 102 042 LCP
SSL Wildcard | Digital Signature (0) + Key Encipherment (2) | ETSI TS 102 042 LCP

FR03
Cachet Serveur | Digital Signature (0) + Non Repudiation (1) | ETSI TS 102 042 LCP

Certificate download URL (on CA website): https://www.certigna.fr/autorites/index.xhtml
Version: Version 3
SHA1 Fingerprint: 2D 0D 52 14 FF 9E AD 99 24 01 74 20 47 6E 6C 85 27 27 F5 43
Public key length (for RSA, modulus length) in bits: RSA 4096 bits
Valid From (YYYY-MM-DD): 2013-10-01
Valid To (YYYY-MM-DD): 2033-10-01

CRL HTTP URL: https://www.certigna.fr/autorites/index.xhtml
CRL issuing frequency for subordinate end-entity certificates: 6 days but they are published every 24 hours or after a certificate’s revocation.
CRL issuing frequency for subordinate CA certificates: 1 year
OCSP URL: http://servicesca.ocsp.certigna.fr/

Class (domain-validated, identity/organizationally-validated or EV): OV
Certificate Policy URL: https://www.certigna.fr/autorites/index.xhtml
CPS URL: https://www.certigna.fr/autorites/index.xhtml
Requested Trust Indicators (email and/or SSL and/or code signing): email and SSL and code signing
URL of example website using certificate subordinate to this root
(if applying for SSL): https://test.dhimyotis.com

More details in attachment.
Depends on: 1266501
Aaron and Francis have started the Information Verification for this request.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Aaron and Francis have entered the information they have verified so far into Salesforce.

Please review the attached document to ensure it is complete and correct. Also, look for the word "NEED" to see what information still needs to be provided. Provide the requested information and any corrections by posting comments in this bug.
Whiteboard: Information incomplete
Another thing I should mention... In the discussion phase people have been asking CAs to provide translation into English of the entire (Services) CP. While you do not need to provide the full translation yet, keep in mind that it would be best to have the full document translated before the discussion starts. There will be a delay between completing the Information Verification phase (see Comment #3), and starting the public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
Thank you for these informations. The translation of our CP are in progress. You will find below the required informations.

CA's Response to Recommended Practices

4)	Document Handling of IDNs in CP/CPS: Yes but our CAs don’t allow the use of IDNs in certificates.
5)	Revocation of Compromised Certificates: Yes
9)	DNS names go in SAN: Yes
10)	Domain owned by a Natural Person: Yes
11)	OCSP: Yes
12)	Network Security Controls: Yes

CA's Response to Problematic Practices

1)	Long-lived DV certificates: No : Our CAs don’t issue Long-lived DV certificates
3)	Email Address Prefixes for DV Certs: No : Our CAs don’t issue DV certificates
7)	Distributing generated private keys in PKCS#12 files: 
        Only for Identity CA, Authentication and signature key pair are generated and stored in P12 file
        which is downloaded by the authentified subject through a secured HTTPS channel.
8)	Certificates referencing hostnames or private IP addresses : No : 
        The FQDN of SSL certificates are controled and have to be publicaly recognized, 
        but for our SSL Client certificates, it's allowed to use a CN with the syntax 
        <Identity of entity>-<Name of the service>.
9)	Issuing SSL Certificates for Internal Domains: No : 
        Our CAs didn’t issued this kind of certificates and the FQDN of SSL certificates 
        are controled and have to be publicaly recognized (Whois, Afnic)
13)	Lack of Communication With End Users: No : 
        The point of contact for general public is published on certigna website 
        and in the chapter 1.6.2 of CP/CPS. 
        Treatment of complaints is addressed in chapter 9.3 of our CP/CPS.
14)	Backdating the notBefore date: No : 
        The system hour, synchronized with many source of time, 
        is always used to complete the notBefore date.

Mozilla Applied Constraints

NEED: Mozilla has the ability to name constrain root certs; e.g. to *.gov or *.mil. 
CAs should consider if such constraints may be applied to their root certs.
https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/certdb/genname.c#1551

-> Not necessary / Not applicable

Revocation Tested
Resolve all errors https://certificate.revocationcheck.com/test.dhimyotis.com
error: OCSP signing certificate does not contain the OCSP No Check extension

-> All OCSP signing certificates signed by our Certigna root CA contain the OCSP No Check extension.
   We don't understand the reason of this error. Could you give us more information about the  
   certificate used for the test.

CA/Browser Forum Lint Test
NEED: resolve x509lint errors in crt.sh crt.sh Run cablint: no errors
Run x509lint: ERROR: Subject with organizationName but without stateOrProvince or localityName

-> Our SSL certificates include since january 2016 the field "LocalityName" in the subject's DN.
   We don't understand the reason of this error. Could you give us more information about the  
   certificate used for the test.


SSL Verification Procedures
NEED: Where in the Services and Wild CP documentation does it say *how* the domain name included in the certificate is verified to be owned/controlled by the certificate subscriber?
Need to have documentation in the CP/CPS that we can confirm meets the requirements of section 3.2.2.4
(Authorization by Domain Name Registrant) of the CA/Browser Forum's Baseline Requirements.
In other words, where in the Services CP and Wild CP can we find the following?
"WHOIS and AFNIC website are used by RA for checking ownership/control of the domain name for SSL certificate applications."
And *how* WHOIS and AFNIC are used.

-> Systematically, the operators of our RA are using the websites WHOIS and AFNIC (if applicable) 
   for checking ownership of the domain name for SSL certificate applications. 

   The screenshot of this control is always attached to the registration folder for 
   the certificate request. This operation is not been explicitly precised in our CP/CPS, 
   but that the case in our RA procedures which are audited by the LSTI assessment body. 
   The next version of our CP/CPS will include explicitly this operation. 


Email Address Verification Procedures
NEED: Where does it say in the Identity CP and Identity Plus CP that the email
address to be included in the certificate is *used* by Certigna RA to verify that the certificate subscriber owns/controls that email address?
i.e. where does the CP actually say the following?
Subject’s email is controlled during the registration phase, through the exchange of several emails in particular to create the customer account and manage his certificate. If the subject provide a wrong email he can not obtain his certificate. Furthermore the email used for registration is always the one inserted in the subject certificate.

-> This process is not been explicitly precised in our CP/CPS but some chapters explain that 
   the activation datas are send by email to the subject (e.g. : chapters 4.1.2 and 6.2.8).
   Our RA procedures, which are audited by the LSTI assessment body, explain this process. 
   The next versions of our CP/CPS will explicitly include this process to check the subject's email.
Thanks Josselin!

1) For SSL/Email Verification Procedures, you mentioned the next versions of your CP/CPS will explicitly include this process. Could we know the timeline? since we must be able to find the information in the CP/CPS for Information Verification Phase, as per https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

2) For Revocation Test and CA/Browser Lint Test, both are verified with no errors.

Thanks!

Regards,
Aaron & Francis
Hi,

I would like to inform you that our last versions of Certification policies have been published on our website. The english versions of the CPs are available at the following addresses :

http://politique.certigna.fr/en/PCfr03.pdf
http://politique.certigna.fr/en/PCcertignaentityca.pdf
http://politique.certigna.fr/en/PCcertignaentitycsca.pdf
http://politique.certigna.fr/en/PCcertignaservicesca.pdf
http://politique.certigna.fr/en/PCcertignawildca.pdf
http://politique.certigna.fr/en/PCcertignaidentityca.pdf
http://politique.certigna.fr/en/PCcertignaidentityplusca.pdf

Some precisions about email verification have been added in all CP at chapter 3.2, and about FQDN verification inside the CPs of "Services CA" and "Wild" at chapter 4.2.1.

We remain at your disposal for any further information.
Hi Josselin,

Thanks to provide updated documents! 

Only one thing need further info. regarding SSL verification, we do find the "WHOIS and AFNIC are used by RA for checking ownership/control of the domain name for SSL certificate applications in the Services CP and Wild CP 4.2.1, but could we know "HOW" the WHOIS and AFNIC are used?

Thanks,
Aaron & Francis
Hi Aaron & Francis,

During the registration, an operator of our Registration Authority checks the compliance between the informations of the Domain Name Registrant published on the AFNIC and WHOIS websites and the informations of the applicant. For reminder, the applicant must provide :
- an ID document of the entity which designates the legal representative,
- a copy of the ID cards of the legal representative of the entity and of the certificate manager, 
- a signed form by the both,

In the case, where the applicant has not the rights to use this domain name, a request is send to the Domain Name Registrant, by using the contact information published on the AFNIC and WHOIS websites, in order to request the providing of a domain authorization document, a copy of the entity legal representative's ID card and an ID document of the entity which designates the legal representative.

We remain at your disposal for any further information.

Best regards
Attached file IV completed.pdf
the information verification is completed.
Whiteboard: Information incomplete → ready for public discussion
This request has been added to the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
I will update this bug when I start the discussion.
I'm taking the liberty to contact you to know if the public discussion regarding our Certigna Root CA will begin shortly. Because it seems to take a long time for the others discussions.
 
Thank you in advance for your help and your reply.
(In reply to Josselin Allemandou from comment #12)
> I'm taking the liberty to contact you to know if the public discussion
> regarding our Certigna Root CA will begin shortly. Because it seems to take
> a long time for the others discussions.
>  
> Thank you in advance for your help and your reply.


As you pointed out, it depends on how quickly the other discussions go.

References:
https://groups.google.com/forum/#!forum/mozilla.dev.security.policy
https://wiki.mozilla.org/CA
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion
https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

I will update this bug when I start the discussion for this request.

In the meantime, please make sure that all of your documents are in order...
https://wiki.mozilla.org/CA:Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21
Whiteboard: ready for public discussion → [ca-ready-for-discussion 2016-08-19]
Attachment #8742753 - Attachment is obsolete: true
Josselin, Please perform the BR Self Assessment, and attach the resulting BR-self-assessment document to this bug.

Note:
Current version of the BRs: https://cabforum.org/baseline-requirements-documents/
Until a version of the BRs is published that describes all of the allowed methods of domain validation, use version 1.4.1 for section 3.2.2.4 (Domain validation): https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.1.pdf

= Background = 

We are adding a BR-self-assessment step to Mozilla's root inclusion/change process.

Description of this new step is here:
https://wiki.mozilla.org/CA:BRs-Self-Assessment

It includes a link to a template for CA's BR Self Assessment, which is a Google Doc:
https://docs.google.com/spreadsheets/d/1ni41Czial_mggcax8GuCBlInCt1mNOsqbEPzftuAuNQ/edit?usp=sharing

Phase-in plan is here:
https://groups.google.com/d/msg/mozilla.dev.security.policy/Y-PxWRCIcck/Fi9y6vOACQAJ
In particular, note:
+ For the CAs currently in the queue for discussion, I would ask them to perform this BR Self Assessment before I would start their discussion.
Whiteboard: [ca-ready-for-discussion 2016-08-19] → [ca-ready-for-discussion 2016-08-19] -- Need BR Self Assessment
Attached file LSTI - 2017 ETSI Attestation letter (obsolete) —
Attached file CERTIGNA - BR Self Assessment v1.2 (obsolete) —
Whiteboard: [ca-ready-for-discussion 2016-08-19] -- Need BR Self Assessment → [ca-ready-for-discussion 2016-08-19] -- BR Self Assessment Completed 2017-04-18
Hi Josselin,

According to your BR Self Assessment:
- URLs to test certificates:
o Valid certificate : valid.servicesca.certigna.fr 
o Expired certificate: expired.servicesca.certigna.fr
o Revoked certificate: revoked.servicesca.certigna.fr

Those test websites return as "Server not found", could you please double check the URLs? 

Thank you!
Hi Aaron,

Sorry. Its a mistake only in the BR self assessment, we are finaly using the suffix .dhimyotis.com and not certigna.fr.
  
The URLs to use are the following as declared at chapter 2.1 of our CPs :

Valid certificate : valid.servicesca.dhimyotis.com
Expired certificate: expired.servicesca.dhimyotis.com
Revoked certificate: revoked.servicesca.dhimyotis.com

Do you want that i replace the "BR assessment file" with this correction ?
Hi Josselin,

Thanks for your correction! These test websites you provided in Comment#19 just verified.

Yes, please replace the "BR assessment file" with this correction and attach the updated file in this bug.

Thank you!
Aaron
CERTIGNA - BR Self Assessment v1.3 
with a correction of URLs to test SSL certificates
Attachment #8859153 - Attachment is obsolete: true
Product: mozilla.org → NSS
I am now opening the public discussion period for this request from Dhimyotis to include their Certigna Root Certification Authority root certificate, and turn on the Websites and Email trust bits.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy forum.
https://www.mozilla.org/en-US/about/forums/#dev-security-policy

The discussion thread is called "Certigna Root Renewal Request".

Please actively review, respond, and contribute to the discussion.

A representative of this CA must promptly respond directly in the discussion thread to all questions that are posted.

Thanks,
Aaron
Whiteboard: [ca-ready-for-discussion 2016-08-19] -- BR Self Assessment Completed 2017-04-18 → [ca-in-discussion] - BR Self Assessment Completed
Attachment #8861810 - Attachment is obsolete: true
New version of our BR Self Assessment to integrate the updates relating to "DNS CAA" and "Certificate transparency".
Additional informations are available after Nick Lamb's analysis to complete the description of our practices : https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/Certigna%7Csort:relevance/mozilla.dev.security.policy/z7iDk9CdTFo/hCZGQRm4AQAJ
Attached file LSTI - 2018 ETSI Attestation letter (obsolete) —
New attestation letter including QCP-W/EV certificate.
Attachment #8856978 - Attachment is obsolete: true
New version of Initial Information Gathering Document including QCP-W/EVCG certificate linked to Certigna and Certigna Root CA.
Attachment #8742754 - Attachment is obsolete: true
Please find attached an update of the Audit attestation from the assessment body, that confirm that EVCP requirements have been audited for one certificate (Service CA / OID : 1.2.250.1.177.2.5.1.3.1) under this Root CA.

Best regards
Attachment #8946208 - Attachment is obsolete: true
Just to inform you that our latest updated versions of CP and CPS are available at: https://www.certigna.fr/autorites/index.xhtml 
For Services CA: 
- CP : http://politique.certigna.fr/en/PCcertignaservicesca.pdf 
- CPS : http://politique.certigna.fr/DPCcertignaservicesca.pdf 

For Wild CA: 
- CP : http://politique.certigna.fr/en/PCcertignawildca.pdf 
- CPS : http://politique.certigna.fr/en/DPCcertignawildca.pdf 

Note that we are currently working on complementary validation methods (BR 3.2.2.4) to meet the requirements expected before August 1st. Current practices will be maintained to ensure the compliance with national requirements and additional validation methods will be used.
Certificate of conformance 2018 - French version
Update of BR Self Assessment with the additionnal methods implemented by Certigna for the validation of domain control: 
- constructed email to domain contact or ;
- Agreed-Upon Change to Website or ;
- DNS change.

Practices will be operationnal and CP/CPS will be published the first of august or before.
Attachment #8905026 - Attachment is obsolete: true
Devon posted comments on this request to the mozilla.dev.policy.forum: https://groups.google.com/d/msg/mozilla.dev.security.policy/z7iDk9CdTFo/9zQpW1-bCwAJ

Josselin: There are a few questions waiting to be answered by Certigna. Will you please respond to them on the list?
Flags: needinfo?(j.allemandou)
Update after the comments of August 2, 2018 (see 4.3.1)
Attachment #8993651 - Attachment is obsolete: true
Flags: needinfo?(j.allemandou)
Thank you Wayne for your message. 

Sorry for the delay, I was on vacation. We have just replied on the forum.

We hope it meets expectations and remain at your disposal for any further information

Best regards
Certigna responded and Devon replied to the response in the public discussion (link in comment #33)

Certigna needs to make a few CP/CPS updates, and address the remaining open concern regarding CP section 4.3 (this could also be resolved by a CPS update). I will await notification that a new version has been published.
Flags: needinfo?(j.allemandou)
Whiteboard: [ca-in-discussion] - BR Self Assessment Completed → [ca-in-discussion] - Pending CP/CPS updates 30-Aug 2018
CERTIGNA - BR Self Assessment v1.7.xlsx

New update after the comments of August 2, 2018 (see 4.2.1 and 4.3.1)
Attachment #9003064 - Attachment is obsolete: true
Flags: needinfo?(j.allemandou)
Hello, 

Thanks Wayne and Devon for your reply. 

We took the time to respond because we wanted to verify through an audit that the SSL certificate requests processed since September 8th were in compliance with the CA/B Forum requirements for DNS CAA record checks. 

In general, this has been the case, because we have only one case, where the request was authorized by a Registration Officer, despite the alert that had been raised on this subject. 

We checked the logs of the controls carried out and re-rolled these controls on all the SSL certificates issued since September 8th and confirm that only this certificate was the object of a failure. We have created an incident as required (see URL: https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/mVD1QoGXBOQ) for this certificate which has not yet been deployed and used by the applicant. I confirm that we proceeded to the revocation of this certificate which is now included in our CRL with the following serial number: 476abeb2bc78d588ef4b8f27dbd25f6a (see http://crl.certigna.fr/servicesca.crl). 

Note that this incident will not be able to happen again by means of our new practices that automatically block and without possible bypass by the RA, any certificate request for which the DNS CAA record controls induce that the CA is not allowed to issue. These practices are described in the latest updated versions of our CP/CPS. 

We have updated our CPs and CPSs to address the different points reported by Devon: 
-        We clarified the roles and controls performed by the RA and the DRAs; 
-        We updated the practices implemented for the control of DNS CAA records; 
-        We have specified the conditions of generation and signature of certificates by the root CA. As a reminder, these certificates are exclusively reserved for the intermediary authorities of our organization and are handled through Key Ceremonies involving several trusted roles knowing that our root CAs are Offline, and are not intended for customers request. 

Could you tell us if you would like additional information and if these provided to CP/CPS are sufficient for you? 

Thanking you in advance for your help and your reply. 

Best regards
Update of chapter 3.2.2.8 about DNS CAA control
Attachment #9007984 - Attachment is obsolete: true
The discussion period for this request has ended, and I am recommending approval.

Link to the discussion: https://groups.google.com/d/msg/mozilla.dev.security.policy/z7iDk9CdTFo/hCZGQRm4AQAJ
QA Contact: kwilson
Whiteboard: [ca-in-discussion] - Pending CP/CPS updates 30-Aug 2018 → [ca-pending-approval]
This request is now in step #10 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview

The current information about this request is here:
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000079
As per Comment #40, and on behalf of Mozilla I approve this request from Dhimyotis / Certigna to include the following root certificate:

** 'Certigna Root CA' (Email, Websites)


I will file the NSS bug for the approved changes.
Whiteboard: [ca-pending-approval] → [ca-approved] - Pending NSS code changes
Depends on: 1505614
I have filed bug #1505614 against NSS for the actual changes.
Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - Pending NSS code changes → In NSS 3.41, Firefox 65

Attestation letter 2019

Attachment #8947405 - Attachment is obsolete: true
Attached file 23_1373_AT_V2_0.pdf (obsolete) —
Attachment #9041424 - Attachment is obsolete: true
Attachment #9042193 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.