Closed Bug 1233645 Opened 9 years ago Closed 7 years ago

Add TunRootCA2 root certificate(s)

Categories

(CA Program :: CA Certificate Root Program, task)

Product:
CA Program
Component:
CA Certificate Root Program
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: ndca.pki, Assigned: kathleen.a.wilson)

Details

(Whiteboard: [ca-denied] Comment #43)

Attachments

(13 files)

CA-Informations.docx
35.33 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document
Details
TunRootCA2.crt
1.44 KB, application/x-x509-ca-cert
Details
1233645-CAInformation.pdf
142.00 KB, application/pdf
Details
Response to 1233645-CAInformation
130.01 KB, application/pdf
Details
Explanation of mozilla check errors
265.27 KB, application/pdf
Details
OCSP certificate
2.07 KB, application/x-x509-ca-cert
Details
1233645-CAInformation-Complete.pdf
150.98 KB, application/pdf
Details
BR Self Assessment
36.21 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
CAInformation_TunRootCA_Complete_20170522.pdf
186.13 KB, application/pdf
Details
Attestation Letter ANCE 2016.pdf
476.18 KB, application/pdf
Details
CAInfomation_TunRootCA2_20170709.pdf
185.99 KB, application/pdf
Details
ANCE - TunTrust - Webtrust for CA Point In Time Audit - 30 April 2019.pdf
197.26 KB, application/pdf
Details
ANCE - TunTrust - Webtrust for CA BR SSL and Network Security Point in Time Audit - 30 April 2019.pdf
187.89 KB, application/pdf
Details
Attached file CA-Informations.docx —
CA Details ---------- CA Name: Tunisian Root Certificate Authority - TunRootCA2 Website: www.certification.tn One Paragraph Summary of CA, including the following: The NDCA is a governmental agency. It is the tunisian national certification authority. NDCA operates under Tunisia’s Electronic Signature Law 83-2000 (http://www.certification.tn/sites/default/files/documents/loi_2000-83_fr.pdf). All Mozilla users that would like to access Tunisian websites are likely to encounter the root certificate of the NDCA while web browsing, sending/receiving email to their own MTA, sending/receiving S/MIME email, etc. Audit Type (WebTrust, ETSI etc.): ETSI Auditor: LSTI Auditor Website: http://www.lsti-certification.fr/ Audit Document URL(s): http://www.certification.tn/11140VA1_ANCE_AF_S.pdf Certificate Details ------------------- (To be completed once for each certificate; note that we only include root certificates in the store, not intermediates.) Certificate Name: Tunisian Root Certificate Authority – TunRootCA2 Summary Paragraph, including the following: - End entity certificate issuance policy : This root issue SSL certificates. (i.e. what you plan to do with the root) - Number and type of subordinate CAs: 01 - Diagram and/or description of certificate hierarchy: The root certificate is Tunisian Root Certificate Authority. It has one subordinate CA: Tunisian Server Certificate Authority – TunServerCA2. The TunServerCA2 is an internally operated Subordinate CA. It issues OV SSL certificates. Certificate download URL (on CA website): http://www.certification.tn/pub/TunRootCA2.crt Version: V3 SHA1 Fingerprint: 96:38:63:3C:90:56:AE:88:14:A0:65:D2:3B:DC:60:A0:EE:70:2F:A7 Public key length (for RSA, modulus length) in bits: 4096 Valid From (YYYY-MM-DD): 2015-05-05 Valid To (YYYY-MM-DD): 2027-05-05 CRL HTTP URL: http://www.certification.tn/pub/TunRootCA2.crl CRL issuing frequency for subordinate end-entity certificates: 24 hours CRL issuing frequency for subordinate CA certificates: 455 days OCSP URL: http://ocsp.certification.tn Class (domain-validated, identity/organizationally-validated or EV): oragnizationnally-validated Certificate Policy URL: http://www.certification.tn/sites/default/files/documents/politiqueRACINE-NG-01.pdf CPS URL: http://www.certification.tn/sites/default/files/documents/politiqueRACINE-NG-01.pdf Requested Trust Indicators (email and/or SSL and/or code signing): email, SSL, code signing URL of example website using certificate subordinate to this root (if applying for SSL): https://webmail.ance.tn
Attached file TunRootCA2.crt —
Flags: needinfo?(kwilson)
I will start the Information Verification phase when I get caught up after the holidays. https://wiki.mozilla.org/CA:How_to_apply#Information_Verification Also note that as per https://wiki.mozilla.org/CA:How_to_apply all information considered for inclusion in Mozilla's root store must be publicly available. So, clearing the "confidential" flag.
Group: mozilla-employee-confidential
Status: UNCONFIRMED → ASSIGNED
CC list accessible: false
Ever confirmed: true
Not accessible to reporter
Flags: needinfo?(kwilson)
My two cents here (as a Tunisian, and Mozillian) who's encountering online technical difficulties because of the lack of the this cert: the government wants this the soonest possible as part of their early 2016 plan, and I can see why this is very needed since even my domestic flight tickets are now literally impossible to purchase online and every time I would need to actually go to the airport to either finish the payment part or buy new tickets. But that's just one use case (which is likely affecting many people as we speak). It would be a huge help if we get this in soon if it meets the requirements. Thanks Kathleen!
Whiteboard: Information incomplete
I have entered the information for this request into Salesforce. Please review the attached document to make sure it is accurate and complete, and comment in this bug to provide corrections and the additional requested information (search for NEED in the attached document).
Please find in attachement the response to your questions in the 1233645-CAInformation document. Our responses are in blue.
Attached file OCSP certificate —
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
Olfa, Resolving this bug as invalid means that you no longer want to move forward with this root inclusion request. Is that what you intended?
No, we intend to pursue this request.
Please change the status.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(In reply to Olfa from comment #6) > Created attachment 8709981 [details] > Explanation of mozilla check errors I've asked the engineer who wrote the revocation checker site for an evaluation of your response.
Thank you kathleen
(In reply to Kathleen Wilson from comment #11) > (In reply to Olfa from comment #6) > > Created attachment 8709981 [details] > > Explanation of mozilla check errors > > I've asked the engineer who wrote the revocation checker site for an > evaluation of your response. From the engineer: I'm getting a 403 Forbidden when trying to download the CRL files: GET /TunServerCA2.crl HTTP/1.1 Host: crl.certification.tn User-Agent: Online Certificate Revocation Check (http://revocationcheck.com) Connection: close Accept: application/pkix-crl Pragma: akamai-x-cache-on Accept-Encoding: gzip Connection: close HTTP/1.1 403 Forbidden Date: Tue, 26 Jan 2016 07:18:25 GMT Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 186 Connection: close Content-Type: text/html; charset=iso-8859-1 I solved a bug in the OCSP GET request, this contained the full URL in the GET where this should only be path. The OCSP signing certificate "ocsp.certification.tn" is used to sign the response for both end-entity and the CA certificate. The signing certificate needs to be delegated by the issuer of the certificate (ca-delegated) or the response needs to be signed by the issuer them self (ca-signed). See also: https://tools.ietf.org/html/rfc6960#section-2.6
we already had solved the problem which concerns the forbidden access for CRL files. For the second point, according to the section 2.6 of RFC 6960: •The key that signs a certificate‘s status information (certificate of ocsp.certification.tn) is not the same key that signed the certificate (in our case the certificate of TunServerCA2 which issue the OCSP certificate). •The certificate’s issuer (TunServerCA2) explicitly delegates OCSP signing authority key usage extension (critical, OCSP Signing) in the OCSP signer’s certificate. •The OCSP ‘s certificate is issued directly to the responder by the cognizant CA (TunServerCA2) According to the section 4.2.2.2 of RFC 6960: •The key that signs a certificate‘s status information (certificate of ocsp.certification.tn) is not the same key that signed the certificate (in our case the certificate of TunServerCA2 which issue the OCSP certificate). •Therefore, a certificate's issuer MUST do one of the following: 1.Sign the OCSP responses itself, or 2.Explicitly designate this authority to another entity OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extended key usage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that is identified in the request. We are in the second case. If we have completely misunderstood the RFC, please clarify for us how to resolve this bug.
Hello Kathleen. We are still waiting for your answer. If everything is okay, please let us know. Thank you.
All errors listed in https://certificate.revocationcheck.com/webmail.ance.tn are fixed. Would you please check and confirm for us.
Hello Kathleen, We haven't heard from you since 12/02/2016, could you please let us know if there is any progress or changes to be made. Thank you for your time.
(In reply to Olfa from comment #17) > All errors listed in https://certificate.revocationcheck.com/webmail.ance.tn > are fixed. Would you please check and confirm for us. I'm getting errors: Online Certificate Status Protocol (OCSP) This OCSP response was cached at Friday, 19 February 2016 12:31 UTC http://ocsp.certification.tn:8080 (GET) Server failed (Try Later) Certificate status is 'Server failed' OCSP service returned 'Try Later' This OCSP response was cached at Friday, 19 February 2016 12:31 UTC http://ocsp.certification.tn:8080 (POST) Server failed (Try Later) Certificate status is 'Server failed' OCSP service returned 'Try Later'
We have fixed this error. We have rediced the period of update frequency. Would you please try again?
(In reply to Kathleen Wilson from comment #19) > (In reply to Olfa from comment #17) > > All errors listed in https://certificate.revocationcheck.com/webmail.ance.tn > > are fixed. Would you please check and confirm for us. I confirm that I am not seeing the errors anymore.
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.
Whiteboard: Information incomplete → Ready for Public Discussion
We have been wainting to start the public discussion since February 2016. Is there any way to speed up the process ? We are actually experiencing many difficulties with our e-gov services based on the NDCA certificate. Kindly, please consider our request asap.
You can see the discussion queue here: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion As indicated at https://wiki.mozilla.org/CA:How_to_apply#Timeline, the timeline to be included can easily extend longer than a year and there is no expedited option. Based on my experience, CAs should assume 3-5 years from start until they are trusted by the majority of Firefox users.
Whiteboard: Ready for Public Discussion → [ca-ready-for-discussion-new 2016-02-25]
Olfa and Syrine, 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-new 2016-02-25] → [ca-ready-for-discussion-new 2016-02-25] - Need BR Self Assessment
Product: mozilla.org → NSS
Attached file BR Self Assessment —
Hi, Please find attached the BR Self Assessment.
Assignee: kwilson → awu
Whiteboard: [ca-ready-for-discussion-new 2016-02-25] - Need BR Self Assessment → [ca-ready-for-discussion-new 2016-02-25] - BR Self Assessment Completed
Hi Olfa and Syrine, There are several things still need your update and input before moving to next stage. 1. Please review Mozilla's April 2017 CA Communication and attach your responses to this bug. https://wiki.mozilla.org/CA/Communications#April_2017 2. We found you have updated CP/CPS on your website(http://www.certification.tn/en/content/certificate-policy), please provide the direct URLs to the relevant CP/CPS documents. And please have English translation of your current Policy document regarding TLS/SSL certificate issuance. 3. Please provide the 3 URLs to the test websites as described in Section 2.2 of the BRs: "The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired. In your BR Self Assessment you list: - Valid certificate: http://www.certification.tn/pub/A.crt - Revocked certificate: http://www.certification.tn/pub/R.crt - Expired certificate: http://www.certification.tn/pub/E.crt but please provide URLs to test websites whose TLS/SSL cert chains up to the root you requested. 4. Clarify the Date period in Audit Statement Based on your updated audit statement[1], not sure if the dates in the audit statement is typo or not: "The assessment covered the period from October 09th 2016 to September 30th 2017. " Usually the audit period start from October 9, 2015. the audit period end should be October 9, 2016. Could you please confirm the date period is correct? [1]https://bugzilla.mozilla.org/show_bug.cgi?id=1321039 Thank you so much! Kind regards, Aaron
Hi Aaron, Would you please clarify which login and pasword to use to access this page https://ccadb.force.com/CustomLogin. I tried with the same login of this account (https://bugzilla.mozilla.org/show_bug.cgi?id=1233645) but without success. Kinf Regards, Olfa
Hi Olfa, For Common CA Database (CCADB), Please send email to certificates@mozilla.org with your name and the name of the CA you represent. For more information about CCADB, please refer to the following wiki. https://wiki.mozilla.org/CA:CommonCADatabase#Request_a_license Thanks, Aaron
Olfa, I will have a CCADB license issued to you. You will receive email when that happens. However, the April 2017 CA Communication survey is closed. The request in Comment #29 is that you go to https://wiki.mozilla.org/CA/Communications#April_2017 click on "Read-only copy of April 2017 CA Communication" and list your answers in a separate document or as a comment in this bug.
Hi Aaron, Please find below our responses: 1) The direct URL to the relevant CP/CPS is http://www.certification.tn/sites/default/files/documents/PolitiqueSERVEURS-PTC-BR-05.pdf 2) Please find the the english translation of the current Policy document in http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf 3) The 3 URLs to the test websites as described in Section 2.2 of the BRs are: - Web page that hosts a valid certificate: https://valid-ov.certification.tn - Web page that hosts a revocked certificate: https://revoked-ov.certification.tn - Web page that hosts expired certificate: https://expired-ov.certification.tn 4)The audit took place from 27th to 30th September 2016 in applying the relevant ETSI Technical Specifications ETSI TS 102042v2.4.1. The audit was performed by LSTI as a full audit. This audit confirms the validity of the certificate N° 11140 issued on November 2015 and valid until November 2018. Please find attached the Audit Attestation Letter. Best Regards Olfa
Hi Olfa, Thank you for your update! I have verified the test websites, still working on all CP/CPS and BR Self Assessment verification. Once done, this request will move to public discussion in mozilla.dev.security.policy forum. Please stay tuned. Thanks, Aaron
Whiteboard: [ca-ready-for-discussion-new 2016-02-25] - BR Self Assessment Completed → [ca-in-discussion] - BR Self Assessment Completed
I am now opening the public discussion period for this request from the Government of Tunisia is to include the “Tunisian Root Certificate Authority - TunRootCA2” root certificate, and enable the Websites trust bit. 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 "TunRootCA2 root inclusion 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
Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324
Assignee: awu → kwilson
Results of my CPS review have been posted to m.d.s.p.: The TunrootCA2 root operates under the following CPS: http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf The TunserverCA2 subordinate CA operates under a different CPS: http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf ==Good== * Misissued certificates reported earlier in this thread have been revoked ==Meh== * Numerous warning level lint errors in issued certificates: https://crt.sh/?caid=5680&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01 * From the US, the server is returning an error or taking more than one minute to deliver the CRL at http://crl.certification.tn/TunServerCA2.crl (crt.sh is also timing out) * The great majority of certificates issued by this CA fall under the .tn TLD; however, the Government of Tunisia has not requested that the root be constrained to issuance for .tn names. * The subordinate CA certificate contains no EKU extension so is not constrained to issuing certain types of certificates. * Delegated 3rd parties are permitted. The CPS does not clearly state the BR requirement that domain validation may not be performed by a delegated third party. * The only method of domain validation specified in the BR Self Assessment is the now deprecated 3.2.2.4.5. How and when will the Government of Tunisia comply with CA/Browser Forum ballot 218? * The Government of Tunisia’s answer for wildcard domain validation in their BR Self Assessment implies the use of method 3.2.2.4.1, but they claim not to use that method in the same document. * CPS section 4.9.2 does not permit a person who controls a domain name contained in a certificate to request revocation unless they are the Subscriber or the Subscriber's legal representative. ==Bad== * Missing SAN entries: https://crt.sh/?cablint=25&iCAID=5680&minNotBefore=2017-01-01 This CA continues to misissue certificates, so the manual controls described earlier in this thread are inadequate. * The current subordinate CA CPS is dated October-2016. The current root CPS is dated July-2015. Mozilla policy requires annual CPS updates. * The CPS does not comply with the BR requirement to document support for Certificate Authority Authorization (CAA). Has CAA been implemented? * The CPS does not describe how domain validation is performed and which of the BR methods are utilized as required by Mozilla policy section 2.2. * The CPS claims in section 4.2.1 that the databases of regional IP address registries are used to verify domain control. Please explain how this is possible. Next steps: 1. I would ask a representative of the Government of Tunisia to answer the above questions. 2. The CPS issues need to be corrected and new versions published. 3. Given ongoing misissuance, I would not recommend approval of this request until pre-issuance linting has been implemented.
Flags: needinfo?(ndca.pki)
Hi Wayne, The TunRootCA2 root CA operates under the following CPS: http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf ==> The TunRootCA2 operates under a new version of the CP/CPS: : http://www.certification.tn/sites/default/files/documents/CPCPS-NG-EN-02.pdf The TunserverCA2 subordinate CA operates under a different CPS: http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf ==> The TunServerCA2’s subordinate CA operates under a new version of the CP/CPS : http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf ==Good== * Misissued certificates reported earlier in this thread have been revoked ==> Yes. The RA of the TunServerCA2 has revoked all the misissued certificates and issued new ones for its clients. ==Meh== * Numerous warning level lint errors in issued certificates: https://crt.sh/?caid=5680&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01 ==> 99182607 : The certificate has been issued on the 28th Feburary 2017 and was revoked the 03rd of March 2017. ==> 242366304 : The certificate has been issued on 25th October 2017 and was revoked on the 02nd of November 2017. ==> 201192937 : This is the certificate of the OCSP server which checks the status of the TLS/SSL certificates issued under TunServerCA2. * From the US, the server is returning an error or taking more than one minute to deliver the CRL at http://crl.certification.tn/TunServerCA2.crl (crt.sh is also timing out). ==> This problem has been resolved. The reason of this slowness was that during the last two weeks, we migrated to our new backup site. * The great majority of certificates issued by this CA fall under the .tn TLD; however, the Government of Tunisia has not requested that the root be constrained to issuance for .tn names. ==> Yes the great majority of certificates issued by this CA fall under the .tn TLD. However, this CA also issues certificates under others TLD like .com, .net and .org. * The subordinate CA certificate contains no EKU extension so is not constrained to issuing certain types of certificates. ==> Yes, the subordinate CA certificate doesn’t contain a EKU extension. TunServerCA2 signs SSL certificate, CRL and OCSP certificate. This subordinate contains Certificate Sign and CRL Sign key usage. * Delegated 3rd parties are permitted. The CPS does not clearly state the BR requirement that domain validation may not be performed by a delegated third party. ==> Yes the delegated 3rd parties are permitted. But, the domain validation is only performed by the CRA of TunServerCA2 (see section 1.3.2.2 of the new version of the CP/CPS). * The only method of domain validation specified in the BR Self Assessment is the now deprecated 3.2.2.4.5. How and when will the Government of Tunisia comply with CA/Browser Forum ballot 218? ==> See section 3.2.2 of the new version http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. * The Government of Tunisia’s answer for wildcard domain validation in their BR Self Assessment implies the use of method 3.2.2.4.1, but they claim not to use that method in the same document. ==> See section 3.2.2 of the new version http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. * CPS section 4.9.2 does not permit a person who controls a domain name contained in a certificate to request revocation unless they are the Subscriber or the Subscriber's legal representative. ==> Yes we confirm that TunServerCA2 does not permit that the person who controls the domain name to request revocation. Only the subscriber and the subscriber’s legal representative are allowed to request revocation. ==Bad== * Missing SAN entries: https://crt.sh/?cablint=25&iCAID=5680&minNotBefore=2017-01-01 This CA continues to misissue certificates, so the manual controls described earlier in this thread are inadequate. ==> To resolve the missing SAN entries, a specific coding has been done this week on the RA scripts. The common name specified in the CSR is, from now on, automatically included in the SAN entries. In addition to that, a check of the issued certificate using the lintcert will be done by the operators before delivering the certificate to the RSC. ==> * The current subordinate CA CPS is dated October-2016. The current root CPS is dated July-2015. Mozilla policy requires annual CPS updates. ==> The revision dates of the subordinate CA CPS are: the 26th of June 2015, 28th of July 2015, 21st of October 2015, 21st of January 2016, 12th of February 2016, 18th of October 2016, 27th of November 2017 and 27th of February 2018. ==> The revision dates of the root CPS are : 01st of june 2015, 28th of july 2015 and 27th of November 2017. In the future, both of the TunRootCA2 and TunServerCA2 CPSs will be reviewed at least once a year to meet the requirement of the Mozilla policy. * The CPS does not comply with the BR requirement to document support for Certificate Authority Authorization (CAA). Has CAA been implemented? ==> See section 4.2.1 of the new version http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. * The CPS does not describe how domain validation is performed and which of the BR methods are utilized as required by Mozilla policy section 2.2. ==> See section 3.2.2 of the new version http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-07.pdf. * The CPS claims in section 4.2.1 that the databases of regional IP address registries are used to verify domain control. Please explain how this is possible. ==> The TunServerCA2 does not allow IP Address to be listed in certificates. Best Regards
Flags: needinfo?(ndca.pki)
Dear Jonathan, Given the misissued certificates in CT under the existing root, I believe this request should be rejected, and a new clean root with audits should be required before moving forward. ==> All the misissued certificates have been revoked by the NDCA and new correct ones were substituted to the clients. The TunServerCA2 has been audited yearly by a qualified auditor (LSTI, France) since 2015. A new root will not resolve these problems because all of these issues are a part of the validation process in the RA. That’s why we implemented new technical controls in the TunServerCA2 RA to reject all the CSR that contain any problem of this kind. The errors in the issued certificates indicate a lack of technical controls in addition to improperly implemented certificate profiles. Given this, an explanation should also be provided of what changes have been made to the issuance environment to ensure these types of mistakes will not happen under the new root.  Two technical controls have been implemented: 1. In the RA of the TunServerCA2, a specific coding has been done on the RA scripts. The Common Name specified in the CSR is, from now on, automatically included in the SAN entries. In addition to that, a control that ensures that the SAN entries contain the Common Name has been implemented. 2. An automatic check of TBS certificates using TBSCertificate crt.sh API has been added today and integrated into the issuance processes. Actually, we followed the suggestion of Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online published in https://groups.google.com/forum/m/#!topic/mozilla.dev.security.policy/oTQ9OYgS8D4). There are a bunch of warnings, but these jumped out at me as being very serious: These certificates have a commonName that is not included as a dNSName SAN: - https://crt.sh/?id=99182607&opt=cablint ==> We investigated on the error of this case: The TunServerCA2 RA included only the SAN declared in the CSR. This problem has been resolved since last week by implementing a code that includes automatically the Common Name in the SAN entries. Moreover, all the domain names declared in the certificate (CN and Subject Alternative Names) are checked by the RA according to the 3.2.2.4 of the CAB/Forum. - https://crt.sh/?id=242366304&opt=cablint ==>We investigated on the error of this case: The TunServerCA2 RA included only the SAN declared in the CSR. This problem has been resolved since last week by implementing a coding that includes automatically the Common Name in the SAN entries. This certificate has a SAN with a domain ending in .local, which is a reserved special-use TLD: - https://crt.sh/?id=79470561&opt=cablint => We investigated on the error of this case: The TunServerCA2 RA included only the SAN declared in the CSR. This problem has been resolved by updating our CSR checker to include the inspection of all the SAN entries declared in the CSR that contain a “.local” in CN or in any of the SAN entries. All of these cases are automatically rejected by the TunServerCA2 RA and the RSC has to generate a new correct CSR. It’s important to remember that these are only the certificates that we know about via CT. There may be certificates with similar or other issues that are not logged.  We have checked all the issued certificates by a daemon which integrates the crt.sh API. This daemon checked the issued certificates one by one in the RA database: There are 15 misissued certificates since the issuance of the TunServerCA2. You find below the serial number of each one, the Error reported by cablint, x509lint and zlint: 41591505131605113993BB051309A9A8 cablint WARNING Certificate Policies should not contain notice references cablint INFO TLS Server certificate identified x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR CAs must include keyIdentifer field of AKI in all non-self-issued certificates zlint ERROR CAs must support key identifiers and include them in all certificates zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint NOTICE Subscriber Certificate: commonName is deprecated. ==> This issue has been fixed after the first audit in august 2015. 41591509041609025C4CD135DDB18DDD cablint WARNING Certificate Policies should not contain notice references cablint WARNING Name has deprecated attribute emailAddress cablint WARNING Special name in SAN cablint INFO TLS Server certificate identified x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR DNSNames must have a valid TLD. zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint NOTICE Subscriber Certificate: commonName is deprecated. ==> This certificate has been revoked and a new correct one issued for the client. 4159151023161021A29E9C80721A9E52 cablint WARNING Certificate Policies should not contain notice references cablint WARNING Extension should be critical for KeyUsage cablint WARNING Name has deprecated attribute emailAddress cablint INFO TLS Server certificate identified x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR Effective October 1, 2016, CAs must revoke all unexpired certificates that contains a reserved IP or internal name. zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint WARNING The keyUsage extension SHOULD be critical zlint NOTICE Subscriber Certificate: commonName is deprecated. ==> This certificate expired in the 21st of October 2016. 41591603111703106E72B4E6B753F8E3 cablint ERROR commonNames in BR certificates must be from SAN entries cablint WARNING Certificate Policies should not contain notice references cablint WARNING Extension should be critical for KeyUsage cablint WARNING Name has deprecated attribute emailAddress cablint INFO TLS Server certificate identified x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint WARNING The keyUsage extension SHOULD be critical zlint NOTICE Subscriber Certificate: commonName is deprecated. ==>This issue is fixed with the new automatic technicals controls. 41591603301703290E16B4E7B593C481 cablint WARNING Certificate Policies should not contain notice references cablint WARNING Extension should be critical for KeyUsage cablint WARNING Name has deprecated attribute emailAddress cablint WARNING Special name in SAN cablint INFO TLS Server certificate identified x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR DNSNames must have a valid TLD. zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint WARNING The keyUsage extension SHOULD be critical zlint NOTICE Subscriber Certificate: commonName is deprecated. ==> This issue is fixed with the new automatic technicals controls. 4159160412180411114E3A7D0FEDA87E cablint ERROR BR certificates must not contain rfc822Name type alternative name cablint ERROR commonNames in BR certificates must be from SAN entries cablint WARNING Certificate Policies should not contain notice references cablint WARNING Name has deprecated attribute emailAddress cablint INFO TLS Server certificate identified x509lint ERROR Invalid type in SAN entry x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension zlint ERROR The Subject Alternate Name extension MUST contain only 'dnsName' and 'ipaddress' name types. zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint NOTICE Subscriber Certificate: commonName is deprecated. ==> This issue is fixed with the new automatic technicals controls. 415916061017060953E7E2AC04D0FE54 cablint ERROR BR certificates must not contain rfc822Name type alternative name cablint ERROR commonNames in BR certificates must be from SAN entries cablint WARNING Certificate Policies should not contain notice references cablint WARNING Name has deprecated attribute emailAddress cablint INFO TLS Server certificate identified x509lint ERROR Invalid type in SAN entry x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension zlint ERROR The Subject Alternate Name extension MUST contain only 'dnsName' and 'ipaddress' name types. zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint NOTICE Subscriber Certificate: commonName is deprecated. ==> This issue is fixed with the new automatic technicals controls. 41591612091712080154AE004DC753E1 cablint ERROR BR certificates must not contain rfc822Name type alternative name cablint ERROR commonNames in BR certificates must be from SAN entries cablint WARNING Certificate Policies should not contain notice references cablint WARNING Name has deprecated attribute emailAddress cablint INFO TLS Server certificate identified x509lint ERROR Invalid type in SAN entry x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension zlint ERROR The Subject Alternate Name extension MUST contain only 'dnsName' and 'ipaddress' name types. zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint NOTICE Subscriber Certificate: commonName is deprecated. ==> This issue is fixed with the new automatic technicals controls. 4159170109180108A0A676CA5F5C3F70 cablint WARNING Certificate Policies should not contain notice references cablint WARNING Extension should be critical for KeyUsage cablint WARNING Name has deprecated attribute emailAddress cablint WARNING Special name in SAN cablint INFO TLS Server certificate identified x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR DNSNames must have a valid TLD. zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint WARNING The keyUsage extension SHOULD be critical zlint NOTICE Subscriber Certificate: commonName is deprecated. ==> This issue is fixed with the new automatic technicals controls. 4159170228180227F03C255A5BE535F6 cablint ERROR commonNames in BR certificates must be from SAN entries cablint WARNING Certificate Policies should not contain notice references cablint WARNING Extension should be critical for KeyUsage cablint WARNING Name has deprecated attribute emailAddress cablint INFO TLS Server certificate identified x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint WARNING The keyUsage extension SHOULD be critical zlint NOTICE Subscriber Certificate: commonName is deprecated. ==> This issue is fixed with the new automatic technicals controls. 41591706151906144B98D55B34AD958D cablint ERROR commonNames in BR certificates must be from SAN entries cablint WARNING Certificate Policies should not contain notice references cablint WARNING Extension should be critical for KeyUsage cablint WARNING Name has deprecated attribute emailAddress cablint INFO TLS Server certificate identified x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR Effective October 1, 2016, CAs must revoke all unexpired certificates that contains a reserved IP or internal name. zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint WARNING The keyUsage extension SHOULD be critical zlint NOTICE Subscriber Certificate: commonName is deprecated. ==>This issue is fixed with the new automatic technicals controls. 41591710251910243E52C0A86C15D20C cablint ERROR commonNames in BR certificates must be from SAN entries cablint WARNING Certificate Policies should not contain notice references cablint WARNING Name has deprecated attribute emailAddress cablint INFO TLS Server certificate identified x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint WARNING Sub certificates SHOULD include Subject Key Identifier in end entity certs zlint NOTICE Subscriber Certificate: commonName is deprecated. ==>This issue is fixed with the new automatic technicals controls. 4159180223200222BF945607FA19132A cablint ERROR commonNames in BR certificates must be from SAN entries cablint WARNING Certificate Policies should not contain notice references cablint WARNING Name has deprecated attribute emailAddress cablint WARNING Trailing whitespace in commonName cablint INFO TLS Server certificate identified x509lint ERROR The string contains non-printable control characters x509lint WARNING explicitText is not using a UTF8String x509lint WARNING Policy information has qualifier other than CPS URI x509lint INFO Subject has a deprecated CommonName x509lint INFO Unknown validation policy zlint ERROR Characters in labels of DNSNames MUST be alphanumeric, - , _ or * zlint ERROR DNSNames must have a valid TLD. zlint ERROR The common name field in subscriber certificates must include only names from the SAN extension zlint WARNING AttributeValue in subject RelativeDistinguishedName sequence SHOULD NOT have trailing whitespace zlint WARNING Compliant certificates SHOULD NOT use the noticeRef option zlint WARNING Compliant certificates should use the utf8string encoding for explicitText zlint NOTICE Subscriber Certificate: commonName is deprecated. ==> This certificate contained a special caracter in the CSR. This I just took a closer look at the thread, and it appears that some misissuance was pointed out in July and most of the controls that were suggested as a solution relied on humans. These controls appear to have predictably failed, as multiple misissued certificates are from this fall, well after the fixes should have been in place. ==> It’s true that at the beginning only human controls were implemented. However, today many other technical controls are implemented in the TunServerCA2 RA, including: 1. The update of the CSR checker in the RA to reject automatically any CSR that contains a .local, IP address. 2. The certtbslint API is integrated in the TunServerCA2 RA to prohibit the issuance of a certificate which the result has a severity fatal or error. 3. Update in the code of TunServerCA2 RA to include automatically the CN in the SAN entries and to check if it is repeated. Dear Wayne, Olfa's most recent response indicates that additional/technical controls were added this week. However, I'm not convinced that they are adequate. ==>We hope that the additional technical controls described above, will convince you and we assure you that these controls will prohibit the occurrence of this type of mistakes from now on. Olfa
the inclusion of the certification authority in Mozilla is a challenge for the Tunisian government, efforts of more than 4 years of massive work, international audits, the improvement of this authority does not stop to prove the seriousness of the team that works day and night to succeed this challenge, despite the errors we read in this group, but I do not think they are so fatal compared to other errors of other certification authorities, I wish you give this authority a chance as you gave it to others. I found the responsiveness to answer you while remedying any noncompliance encountered, and the transparency that showed by listing the errors encountered and not detected by you. For me, if I could give my opinion, I would say favorable. Anis
Denying this request based on the public discussion at https://groups.google.com/d/msg/mozilla.dev.security.policy/wCZsVq7AtUY/Abm71IFYBgAJ CAs inherently must be trusted, and trust must be earned. A CA can't simply fix one problem after another as we find them during the inclusion process and expect to be rewarded for their reactive efforts, nor can they ignore program requirements until the time comes to get their inclusion request approved. Recurrences of the same issue that the CA claimed to have fixed are especially damaging. As Ryan mentioned, section 7.1 of the Root Store Policy states that "We will determine which CA certificates are included in Mozilla's root program based on the benefits and risks of such inclusion to typical users of our products." While I believe the decision to deny this request is fully supported by that policy statement, I would be interested to know if anyone thinks there are ways we could make our expectations clearer in this regard. Regarding next steps, the Tunisian Government is welcome to submit a new root (using a newly generated key pair) for inclusion. The current bug may be reopened and used for the new request, but it will still need to go through the entire process. The only real "shortcut" in the inclusion process - as has been demonstrated by a few CAs recently who completed the process in 9-18 months) - is to have all the requirements fully met before the request is reviewed. Tests that are performed during the information verification process are documented [1], and every previous inclusion request is publicly accessible in Bugzilla and archives of this list, so this really shouldn't be as difficult as it seems to be. I agree with the comments Hans made on the desire to rapidly move through the process with the new request. Establishing confidence in a CA takes time, and attempts to move too quickly to regain trust can be extremely counterproductive (e.g. StartCom). Regarding the choice of auditor, Mozilla has not disqualified LSTI and so will not require a different auditor to be selected if/when a new root is submitted. However, given the concerns that have been raised with the current audits, choosing a different auditor may help to gain the confidence of the community in the new root and in the Tunisian Government CA. [1] https://wiki.mozilla.org/CA:TestErrors
Status: REOPENED → RESOLVED
Closed: 9 years ago → 7 years ago
Resolution: --- → WONTFIX
Whiteboard: [ca-in-discussion] - BR Self Assessment Completed → [ca-denied] Comment #43

Hi Wayne and Kathleen

Agence Nationale de Certification Electronique, Tunisia wants to request for the inclusion of our new root certificate, namely TunTrust Root CA, to be included in Mozilla Root Store. As per your last comment in bug 1233645, we would like to re-open this bug to submit our new root certificate

The audit case for the new Root inclusion request is in CCADB
https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000499.

As per your recommendation, we have held a key generation ceremony (KGC) regarding our new Root CA, TunTrust Root CA, and internally operated Subordinate CAs. The new PKI hierarchy is as follows :
TunTrust Root CA: root-signing all TunTrust issuing CAs and kept offline
TunTrust Services CA: This issuing CA is restricted to only issue OV SSL certificates to domain names- under “.tn” top-level domain and owned by entities operating under the Tunisian Jurisdiction.
TunTrust Qualified CA: This issuing CA is technically constrained to prevent issuance of SSL- certificates.

We have completed a point-in-time audit performed in accordance with applicable standards under WebTrust scheme and a KGC audit used to ensure the integrity and confidentiality of the key pairs.
We provide you the download links of the related audit reports which can be found from the following links:
WebTrust for CA point-in-time audit report
https://www.tuntrust.tn/sites/default/files/Ressources/ANCE_TunTrust_Webtrust_for_CA_Point_In_Time_Audit_30_April_2019.pdf
WebTrust for CA-SSL BR and Network Security point-in-time audit report
https://www.tuntrust.tn/sites/default/files/Ressources/ANCE_TunTrust_Webtrust_for_CA_BR_SSL_and_Network_Security_Point_in_Time_Audit_30_April_2019.pdf
Audit report of Root & Sub Key Generation Ceremony
https://www.tuntrust.tn/sites/default/files/Ressources/ANCE_TunTrust_RKGC_Audit_Report_26_April_2019.pdf

We have also completed a period-of-time audit performed in accordance with applicable standards under WebTrust scheme for TunTrust Root CA . The related audit reports will be published once received from auditors.

Kindly, let us know whether we should re-open the previous bug 1233645 or should we open a new one and refer to it from bug 1233645.

Best Regards

Syrine Tlili
Agence Nationale de Certification Electronique
https://www.tuntrust.tn

Flags: needinfo?(kwilson)

The request to include the new root will be handled in Bug #1587779.

Flags: needinfo?(kwilson)
QA Contact: kwilson
Product: NSS → CA Program
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: