Closed Bug 1265683 Opened 3 years ago Closed 8 months ago
Add [Certigna Root CA] root certificate(s)
164.20 KB, application/pdf
168.96 KB, application/pdf
415.53 KB, application/pdf
305.71 KB, application/pdf
187.89 KB, application/pdf
644.93 KB, application/pdf
253.70 KB, application/pdf
41.39 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
301.12 KB, application/pdf
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.
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.
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 184.108.40.206 (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
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]
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 220.127.116.11 (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
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
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
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 : 18.104.22.168.22.214.171.124.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 126.96.36.199) 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?
Update after the comments of August 2, 2018 (see 4.3.1)
Attachment #8993651 - Attachment is obsolete: true
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.
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
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 188.8.131.52 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
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
You need to log in before you can comment on or make changes to this bug.