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)
NSS
CA Certificate Root Program
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 |
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.
Reporter | ||
Comment 1•5 years ago
|
||
Assignee | ||
Comment 2•5 years ago
|
||
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
Assignee | ||
Comment 3•5 years ago
|
||
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.
Assignee | ||
Updated•5 years ago
|
Whiteboard: Information incomplete
Assignee | ||
Comment 4•5 years ago
|
||
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
Reporter | ||
Comment 5•5 years ago
|
||
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
Reporter | ||
Comment 7•5 years ago
|
||
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
Reporter | ||
Comment 9•5 years ago
|
||
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
Comment 10•5 years ago
|
||
the information verification is completed.
Updated•5 years ago
|
Whiteboard: Information incomplete → ready for public discussion
Assignee | ||
Comment 11•5 years ago
|
||
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.
Reporter | ||
Comment 12•4 years ago
|
||
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.
Assignee | ||
Comment 13•4 years ago
|
||
(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]
Reporter | ||
Comment 14•4 years ago
|
||
Attachment #8742753 -
Attachment is obsolete: true
Assignee | ||
Comment 15•4 years ago
|
||
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
Reporter | ||
Comment 16•4 years ago
|
||
Reporter | ||
Comment 17•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
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
Comment 18•4 years ago
|
||
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!
Reporter | ||
Comment 19•4 years ago
|
||
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 ?
Comment 20•4 years ago
|
||
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
Reporter | ||
Comment 21•4 years ago
|
||
CERTIGNA - BR Self Assessment v1.3 with a correction of URLs to test SSL certificates
Attachment #8859153 -
Attachment is obsolete: true
Comment 22•4 years ago
|
||
Updated•4 years ago
|
Product: mozilla.org → NSS
Comment 23•4 years ago
|
||
Comment 24•4 years ago
|
||
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
Description
•