Closed Bug 1265683 Opened 5 years ago Closed 2 years ago

Add [Certigna Root CA] root certificate(s)

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

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

References

Details

(Whiteboard: In NSS 3.41, Firefox 65)

Attachments

(11 files, 14 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
327.02 KB, application/pdf
Details
344.62 KB, application/pdf
Details
319.33 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