1233645 - Add TunRootCA2 root certificate(s)

Status: RESOLVED WONTFIX

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

Description

[TunTrust]

Attachment: 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

Comment 1

[TunTrust]

Attachment: TunRootCA2.crt

Comment 2

[Kathleen Wilson]

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.

Comment 3

[Ahmed Nefzaoui [:Nefzaoui]]

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!

Comment 4

[Kathleen Wilson]

Attachment: 1233645-CAInformation.pdf

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).

Comment 5

[TunTrust]

Attachment: Response to 1233645-CAInformation

Please find in attachement the response to your questions in the 1233645-CAInformation document. Our responses are in blue.

Comment 6

[TunTrust]

Attachment: Explanation of mozilla check errors

Comment 7

[TunTrust]

Attachment: OCSP certificate

Comment 8

[Kathleen Wilson]

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?

Comment 9

[TunTrust]

No, we intend to pursue this request.

Comment 10

[TunTrust]

Please change the status.

Comment 11

[Kathleen Wilson]

(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.

Comment 12

[TunTrust]

Thank you kathleen

Comment 13

[Kathleen Wilson]

(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

Comment 14

[TunTrust]

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.

Comment 15

[TunTrust]

Hello Kathleen. We are still waiting for your answer. If everything is okay, please let us know. Thank you.

Comment 16

[Kathleen Wilson]

Please read 
https://wiki.mozilla.org/CA:OCSP-TrustedResponder
and
https://wiki.mozilla.org/CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root 
to see if that answers your question.

Comment 17

[TunTrust]

All errors listed in https://certificate.revocationcheck.com/webmail.ance.tn are fixed. Would you please check and confirm for us.

Comment 18

[TunTrust]

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.

Comment 19

[Kathleen Wilson]

(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'

Comment 20

[TunTrust]

We have fixed this error.
We have rediced the period of update frequency.
Would you please try again?

Comment 21

[Kathleen Wilson]

(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.

Comment 22

[Kathleen Wilson]

Attachment: 1233645-CAInformation-Complete.pdf

Comment 23

[Kathleen Wilson]

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.

Comment 24

[syrine.tlili]

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.

Comment 25

[Peter Bowen]

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.

Comment 26

[Kathleen Wilson]

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.

Comment 27

[TunTrust]

Attachment: BR Self Assessment

Hi, 

Please find attached the BR Self Assessment.

Comment 28

[Aaron Wu]

Attachment: CAInformation_TunRootCA_Complete_20170522.pdf

Comment 29

[Aaron Wu]

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

Comment 30

[TunTrust]

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

Comment 31

[Aaron Wu]

Hi Olfa,

For Common CA Database (CCADB), Please send email to [e-mail] 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

Comment 32

[Kathleen Wilson]

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.

Comment 33

[TunTrust]

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

Comment 34

[TunTrust]

Attachment: Attestation Letter ANCE 2016.pdf

Comment 35

[Aaron Wu]

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

Comment 36

[Aaron Wu]

Attachment: CAInfomation_TunRootCA2_20170709.pdf

Comment 37

[Aaron Wu]

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

Comment 38

[Firefox Bug Husbandry Bot]

Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324

Comment 39

[Wayne Thayer]

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.

Comment 40

[TunTrust]

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

Comment 41

[TunTrust]

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

Comment 42

[ANIS DJEMAL]

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

Comment 43

[Wayne Thayer]

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

Comment 44

[syrine.tlili]

Attachment: ANCE - TunTrust - Webtrust for CA Point In Time Audit - 30 April 2019.pdf

Comment 45

[syrine.tlili]

Attachment: ANCE - TunTrust - Webtrust for CA BR SSL and Network Security Point in Time Audit - 30 April 2019.pdf

Comment 46

[syrine.tlili]

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

Comment 47

[Kathleen Wilson]

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