ZoTrus Trusted Root ProgramEffect Date: April 20, 2022, Updated: Feb. 18, 2024
1.Program Requirements
ZT Browser uses public key infrastructure (PKI) to secure and enhance the experience for users, it supports RSA/ECC/SM2 algorithm, the requirements for root certificate using RSA/ECC algorithm must be compliant with the international standards, and the root certificate using SM2 algorithm must be compliant with the Chinese Cryptography standards.
1.1 CA providers using RSA/ECC algorithm requirements
-
CA providers must ensure their CAs are audited against at least one of the below criteria at least annually:
✦ WebTrust Principles and Criteria for Certification Authorities (Preferred)
✦ ETSI EN 319 411-1 LCP, NCP or NCP+ (Accepted on a case-by-case basis)
-
CA providers must ensure their SSL/TLS enabled root CAs and all subordinate CAs capable of issuing TLS certificates are audited against at least one of the below sets of criteria at least annually:
✦ WebTrust Principles and Criteria for Certification Authorities and WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security (Preferred)
✦ ETSI EN 319 411-1 LCP and (DVCP or OVCP) (Accepted on a case-by-case basis)
-
CA providers must ensure their Extended Validation (EV) enabled root CAs and all subordinate CAs capable of issuing EV TLS certificates are audited against at least one of the below sets of criteria at least annually:
✦ WebTrust Principles and Criteria for Certification Authorities, WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security, and WebTrust Principles and Criteria for Certification Authorities – Extended Validation SSL (Preferred)
✦ ETSI EN 319 411-1 NCP and EVCP (Accepted on a case-by-case basis)
- CA providers must strictly adhere to their Certificate Policy (CP) and/or Certification Practices Statement (CPS) documents.
- TLS CA providers must constantly maintain compliance with the CA/Browser Forum Baseline Requirements Certificate Policy for the Issuance and Management of Publicly-Trusted Certificates, and must incorporate and commit to compliance with the CA/Browser Forum’s Baseline Requirements in their CP and/or CPS documents.
- EV CA providers must constantly maintain compliance with the CA/Browser Forum Guidelines for The Issuance And Management Of Extended Validation Certificates, and must incorporate and commit to compliance with the CA/Browser Forum’s EV Guidelines in their CP and/or CPS documents.
- To apply for the including root CA certificate for PDF document digital signature and timestamp signing, the root CA certificate must have been trusted by Adobe AATL.
- CA providers must notify ZoTrus if they anticipate any change in control or ownership of any CA certificate (whether directly included or subordinate thereto). Do not assume inclusion is transferable.
- A root certificate must provide broad value to ZT Browser's users.
- CA providers applying for inclusion in the ZoTrus Trusted Root Program are expected to meet all Program and Policy requirements prior to submitting an application.
1.2 CA providers using SM2 algorithm requirements
- CA providers must a valid China CA license issued by MIIT and SCA, must have its own SM2 Root certificate or sub-CA issued by the Chinese SM2 Root CA for issuing SM2 SSL/TLS certificates.
- If CA providers don’t have valid China CA license, then must have WebTrust audited annual report and at least one RSA/ECC root is included in Microsoft/Mozilla/Google/Apple Root Certificate Program, the non-licensed root CA’s application is accepted on a case-by-case basis.
- CA providers applying for the including SM2 root CA for PDF document digital signatures and timestamp signing must have a valid China CA license issued by MIIT and SCA. ZT Browser will include and trust the intermediate root certificate issued by the Chinese SM2 Root CA, so that users can directly use the USB Key SM2 client certificate issued by the CA to digitally sign PDF/ODF documents.
- Other requirements are same as RSA/ECC algorithm related standard as above described, just the algorithm is different.
2.Policy Requirements
2.1 CA providers using RSA/ECC algorithm requirements
- CA providers must disclose all sub-CA certificates which chain up to their root CA Certificate(s) included in the ZoTrus Trusted Root Program.
- To quickly identify the PDF document signing certificate type, CAs must declare one of the following Policy OIDs in its Certificate Policy extension for end-entity PDF document signing certificate, otherwise the T1 icon will be displayed by default.
✦ MV Document Signing Certificate:1.3.6.1.4.1.57933.41
✦ IV Document Signing Certificate: 1.3.6.1.4.1.57933.42
✦ OV Document Signing Certificate: 1.3.6.1.4.1.57933.43
✦ SV Document Signing Certificate: 1.3.6.1.4.1.57933.44
- Other policy requirements are compliant with CAB Forum requirements.
2.2 CA providers using SM2 algorithm requirements
- The Chinese SM2 Root Certificate is included and trusted in ZT Browser, but all sub CAs must contact us to apply its sub-CA trusted so that ZT Browser can properly validate the certificate chain and display the correct trusted level icon.
- To quickly identify the SSL certificate type, CAs must declare one of the following Policy OIDs in its Certificate Policy extension for end-entity TLS/SSL certificate, otherwise the T1 icon will be displayed by default.
✦ DV SSL Certificate: 1.2.156.157933.11 or CABF OID: 2.23.140.1.2.1
✦ IV SSL Certificate: 1.2.156.157933.12 or CABF OID: 2.23.140.1.2.3
✦ OV SSL Certificate: 1.2.156.157933.13 or CABF OID: 2.23.140.1.2.2
✦ EV SSL Certificate: 1.2.156.157933.14 or CABF OID: 2.23.140.1.1
- To quickly identify the S/MIME certificate type, CAs must declare one of the following Policy OIDs in its Certificate Policy extension for end-entity S/MIME certificate, otherwise the T1 icon will be displayed by default.
✦ MV S/MIME certificate: 1.2.156.157933.31 or CABF S/MIME MV strict OID: 2.23.140.1.5.1.3
✦ IV S/MIME certificate: 1.2.156.157933.32 or CABF S/MIME IV strict OID: 2.23.140.1.5.4.3
✦ OV S/MIME certificate: 1.2.156.157933.33 or CABF S/MIME OV strict OID: 2.23.140.1.5.2.3
✦ SV S/MIME certificate: 1.2.156.157933.34 or CABF S/MIME SV strict e OID: 2.23.140.1.5.3.3
- To quickly identify the document signing certificate type, CAs must declare one of the following Policy OIDs in its Certificate Policy extension for end-entity document signing certificate, otherwise the T1 icon will be displayed by default.
✦ MV Document Signing Certificate: 1.2.156.157933.41
✦ IV Document Signing Certificate: 1.2.156.157933.42
✦ OV Document Signing Certificate: 1.2.156.157933.43
✦ SV Document Signing Certificate: 1.2.156.157933.44
- To quickly validate the TLS/SSL certificate, the certificate must have Authority Key Identifier (KeyID), Authority Information Access URL (AIA), and the Enhanced Key Usage must be Server Authentication and Client Authentication. The intermediate root certificate must also have Authority Key Identifier (KeyID), Authority Information Access URL (AIA).
- SM2 Certificate Transparency Policy: SM2 SSL certificates with a certificate validity period of less than or equal to 180 days must contain 2 SM2 SCT data, and SM2 SSL certificates greater than 180 days must contain 3 SM2 SCT data. But due to there are currently only three SM2 certificate transparency log systems available provided by ZoTrus, for the time being, only one SM2 SCT data is required for less than or equal to 180 days SM2 SSL certificate, and two SM2 SCT data are required for the greater than 180 days SM2 SSL certificate. If there are more SM2 certificate transparency log systems available on the market in the future that pass the certification of ZT Browser, the formal certificate transparency policy will be implemented.
- Starting on Jan. 1, 2025, ZT Browser no longer trusts the SM2 SSL certificate that does not embed the ZT Browser trusted SCT data, it will display “Not secure” in the address bar. Prior to this, only display “Certificate NOT Transparency” in the SM2 encryption icon details.
- Other requirements are same as RSA/ECC algorithm related standard as above described, just the algorithm is different.
2.3 CA Requirements for Issuing Intranet SSL Certificates
In view of the standard for publicly trusted TLS/SSL certificates (CABF BR 4.2.2), CA SHALL NOT issue SSL certificates containing Internal Names or Reserved IP addresses, as such names and IP addresses cannot be validated according to relevant validation standards, but such SSL certificates are required to implement HTTPS encryption to ensure the security of the Internal Web systems. To this end, ZT Browser has specially formulated the CA Requirements for Issuing Intranet SSL certificates.
- An Intranet SSL certificate is an SSL certificate that contains an internal name and/or reserved IP address in the Subject Alternative Name field of SSL certificate. Reserved IP addresses follow the definition of the IANA (IP V4 and IP V6), and the Internal Name refers to a non-public domain name.
- CAs that issue intranet SSL certificates can submit a dedicated root CA certificate for issuing intranet SSL certificates to apply for the ZoTrus Trusted Root Program, and CAs are not allowed to issue intranet SSL certificates from the root CA certificate that issues publicly trusted SSL certificates.
- The "Subject" field of the intranet SSL certificate must be a public domain name (FQDN) and shall not be an internal name or reserved IP address, which is used by the CA to validate the ownership of the intranet SSL certificate, and the CA must complete the domain name control validation in accordance with the requirements of SSL BR Section 3.2.2.4 or Section 3.2.2.5.
- The "Subject Alternative Name" field of the intranet SSL certificate must have at least one internal name or reserved IP address, and the internal name or reserved IP address can only be included in the "Subject Alternative Name" field of the intranet SSL certificate, and the CA does not need to validate these internal names and reserved IP addresses. However, the CA must verify all public domain names and IP addresses contained in the Subject Selectable Name field according to relevant standards.
- The validity period of the intranet SSL certificate can be 1-5 years.
- In order to quickly identify the type of intranet SSL certificate and enable ZT Browser to correctly display the certificate trusted level T1/T2/T3/T4 icon, the CA must declare one of the following policy OIDs in the certificate policy extension of the SSL certificate, otherwise the T1 icon will be displayed by default.
✦ Intranet DV SSL certificate: 1.2.156.157933.81 or 1.3.6.1.4.1.57933.81
✦ Intranet IV SSL certificate: 1.2.156.157933.82 or 1.3.6.1.4.1.57933.82
✦ Intranet OV SSL certificate: 1.2.156.157933.83 or 1.3.6.1.4.1.57933.83
✦ Intranet EV SSL certificate: 1.2.156.157933.84 or 1.3.6.1.4.1.57933.84
- If the intranet SSL certificate contains the specified OID defined in (6), it indicates that the issued intranet SSL certificate meets the requirements of above (1)-(5). If the certificate does not meet the requirements, ZT Browser will display "Not secure".
- In view of the fact that only the 3 certificate transparency log systems trusted by ZT Browser currently support intranet SSL certificates, the intranet SSL certificate with a certificate validity period of less than or equal to 180 days must contain 1 certificate transparency SCT data trusted by ZT Browser, and the intranet SSL certificate more than 180 days must contain 2 SCT data. If there are more certificate transparency log systems in the market that support intranet SSL certificates, and it passes ZT browser certification and included, the certificate transparency policy of the intranet SSL certificate will be updated and implemented to the same as the Internet SSL certificates policy.
- Other requirements for intranet SSL certificates are the same as those related to standards for publicly trusted SSL certificates.
- This requirement applies to both RSA/ECC algorithm intranet SSL certificates and SM2 algorithm intranet SSL certificates.
3.Submission Process
Download the application form, send email to with the details of your Root Inclusion information such as company name, contact info, root certificate, test website, signed test PDF file etc. CA providers will be contacted if any additional information is required, and when consideration of the inclusion request is complete.
4.Root Acceptance
ZoTrus accepts and removes root certificates as it deems appropriate at its sole discretion. ZoTrus prioritizes root inclusion requests as it deems appropriate at its sole discretion.
All RSA/ECC algorithm root certificates included in Chromium is trusted as default, but we will change our policy at any time without notice that we may des-include some default roots.
SM2 algorithm root certificate inclusion applicant must have a valid China CA license issued by MIIT and SCA and must have its own SM2 Root certificate or sub-CA issued by the China Public Root CA (SM2) for issuing SM2 SSL/TLS certificates. Other special cases are dealt with on a case-by-case basis.
All ZT Browser trusted root CA operators are qualified to provide ZT Browser trusted Website Trusted Identity Validation service. ZT Browser not only display the validation level of the SSL certificate issued by trusted CA for free, but also trust its website validation data that the CA operators are qualified to synchronize to the trusted website data to ZT Browser Trusted Website Validation Database, and ZT Browser will also display its validation level in the address bar for free.
5.Incidents
Failure to comply with the above requirements in any way is considered an incident. CA providers must report such incidents to ZoTrus Trusted Root Program at with a full incident report.