Closed Bug 1309797 Opened 3 years ago Closed 9 months ago

Add SHECA root certificate(s)

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: xiongyuanyuan, Assigned: wayne)

References

Details

(Whiteboard: [ca-approved] - In NSS 3.41, Firefox 65 - EV enabled in Firefox 66)

Attachments

(19 files, 2 obsolete files)

428.72 KB, application/pdf
Details
203.81 KB, application/pdf
Details
42.55 KB, application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Details
439.01 KB, application/pdf
Details
4.87 MB, application/pdf
Details
68.48 KB, image/png
Details
47.09 KB, image/png
Details
70.71 KB, image/png
Details
354.33 KB, image/png
Details
104.47 KB, image/png
Details
78.44 KB, image/png
Details
1.85 KB, application/x-x509-ca-cert
Details
1.87 KB, application/x-x509-ca-cert
Details
215.15 KB, application/pdf
Details
1.43 MB, application/pdf
Details
5.23 MB, application/pdf
Details
3.85 MB, application/pdf
Details
4.00 MB, application/pdf
Details
675 bytes, application/pkix-crl
Details
CA Details

CA Name: Shanghai Electronic Certification Authority Co., Ltd.
Website: www.sheca.com

One Paragraph Summary of CA:
Shanghai Electronic Certification Authority Co., Ltd. (‘SHECA’ thereafter) is a Shanghai-based commercial company and is one of the biggest Certification Authorities in China. SHECA is a national recognized CA and operates under China’s Electronic Signature Law. Our customers include individuals and companies from mainland China, Taiwan and Hong Kong. 

Audit Type:WebTrust
Auditor:PricewaterhouseCoopers
Auditor Website:www.pwc.com
Audit Document URL(s): 
WebTrust :https://cert.webtrust.org/ViewSeal?id=2045
WebTrust SSL :https://cert.webtrust.org/ViewSeal?id=2047 
WebTrust EV  :https://cert.webtrust.org/ViewSeal?id=2048

Certificate Details

Certificate Name: UCA Global G2 Root
Summary Paragraph:
Our certificates, which are issued by UCA Global G2 Root, are intended for the following use: 
a)  For Business Entity 
i) digital signature (e.g., emails and documents)
ii) authentication to certain B2B applications.
b)  For Government Entity
i) digital signature (e.g., emails and documents)
ii) authentication to certain B2B applications. 
c)  For Individuals 
i) digital signature (e.g., emails, documents)
ii) authentication to certain B2C applications.
d)  For Servers 
i) Secure Communication service (e.g., SSL)
ii) Authentication with other servers / applications
e)  For Software Developers
i) digital signature (e.g., software)

Under the root certificates, there are two subordinate CAs, “SHECA Global G3 SSL” and “SHECA Global G3 CodeSigning”, which are used for issuing SSL and CodeSigning certificates respectively.  

Certificate download URL (on CA website): http://www.sheca.com/download/getdownloadforpdf/126
Version: X.509 V3
SHA1 Fingerprint: 28 f9 78 16 19 7a ff 18 25 18 aa 44 fe c1 a0 ce 5c b6 4c 8a
Public key length (for RSA, modulus length) in bits:4096
Valid From (YYYY-MM-DD): 2016-03-11
Valid To (YYYY-MM-DD): 2040-12-31

CRL HTTP URL: http://ldap2.sheca.com/root/ucaglobalg2.crl
CRL issuing frequency for subordinate end-entity certificates: 24hours
CRL issuing frequency for subordinate CA certificates: 3months
OCSP URL: http://ocsp3.sheca.com/ocsp/sheca/sheca.ocsp

Class (domain-validated, identity/organizationally-validated or EV): OV		
Certificate Policy URL: http://www.sheca.com/download/getdownloadforpdf/162
CPS URL: http://www.sheca.com/download/getdownloadforpdf/160
Requested Trust Indicators (email and/or SSL and/or code signing): Email(S/MIME),Websites(SSL/TLS) and Code Signing 
URL of example website using certificate subordinate to this root
(if applying for SSL):  https://ef-gb.wwwtrust.org

Certificate Name: UCA Extended Validation Root
Summary Paragraph:
EV certificates issued by UCA Extended Validation Root are mainly used to verify identity. Clients who are in the need of high level security will benefit from using EV certificates. UCA Extended Validation Root has two subordinate certificates which are for the issuance of EV SSL certificates and EV Code Signing certificates respectively. 
EV SSL Certificates can be used to verify the identity of the domain name identified in the certificate, as well as the identity of the legal entity holding the domain name. EV Code signing certificate can be used to verify the identity that who is providing or publishing the software.  The information contained in EV certificates issued by SHECA is authentic, effective, and validated.

Certificate download URL (on CA website): http://www.sheca.com/download/getdownloadforpdf/73
Version: X.509 V3
SHA1 Fingerprint: a3 a1 b0 6f 24 61 23 4a e3 36 a5 c2 37 fc a6 ff dd f0 d7 3a
Public key length (for RSA, modulus length) in bits:4096
Valid From (YYYY-MM-DD): 2015-03-13
Valid To (YYYY-MM-DD): 2038-12-31

CRL HTTP URL: http://ldap2.sheca.com/root/ucaevsub.crl
CRL issuing frequency for subordinate end-entity certificates: 24hours
CRL issuing frequency for subordinate CA certificates: 3months
OCSP URL: http://ocsp3.sheca.com/ocsp/sheca/sheca.ocsp

Class (domain-validated, identity/organizationally-validated or EV): EV		
Certificate Policy URL: http://www.sheca.com/download/getdownloadforpdf/166
CPS URL: http://www.sheca.com/download/getdownloadforpdf/165
Requested Trust Indicators (email and/or SSL and/or code signing): Websites(SSL/TLS) and Code Signing
URL of example website using certificate subordinate to this root
(if applying for SSL): https://ef-EV.sheca.com
Hi Kathleen. This is Ruby from SHECA. We are now applying for two new roots' inclusion in your program. The related information of the two root has been given above. Should you have any questions, please let me know. Thank you.
Hi Ruby,
Does this request replace the request in Bug #566310? 
i.e. so should I close Bug #566310?
Thanks,
Kathleen
Hi Kathleen, 
This bug is a replacement for Bug#566310,so you can close Bug#566310 now. 
Thank you.
Aaron and Francis, please close Bug #566310 as a duplicate of this bug.

Then please do the Information & Verification for this new request.
https://wiki.mozilla.org/CA:How_to_apply#Information_Verification

Thanks!
Kathleen
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Duplicate of this bug: 566310
Whiteboard: Information incomplete - Begin Information Verification
Assignee: kwilson → awu
Whiteboard: Information incomplete - Begin Information Verification → [ca-verification]
Hi,

We've done of 1st round of Information Verification, please provide the information which marked "NEED CA Response" in attachment as Comment#7.

Note:
For test website, please refer to the following statement and provide valid/revoke/expired test site.
CA Browser Forum section 2.2: “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.”

Thank you!

Regards,
Aaron
Whiteboard: [ca-verification] → [ca-verifying]
(In reply to Aaron Wu from comment #8)
> Hi,
> 
> We've done of 1st round of Information Verification, please provide the
> information which marked "NEED CA Response" in attachment as Comment#7.
> 
> Note:
> For test website, please refer to the following statement and provide
> valid/revoke/expired test site.
> CA Browser Forum section 2.2: “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.”
> 
> Thank you!
> 
> Regards,
> Aaron

Hi Aaron,

Thank you very much for your comments. We will update the information and clarification as soon as possible.

Regards,
Ruby
(In reply to Aaron Wu from comment #8)
> Hi,
> 
> We've done of 1st round of Information Verification, please provide the
> information which marked "NEED CA Response" in attachment as Comment#7.
> 
> Note:
> For test website, please refer to the following statement and provide
> valid/revoke/expired test site.
> CA Browser Forum section 2.2: “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.”
> 
> Thank you!
> 
> Regards,
> Aaron

Hi Aaron,

As we are going through the file that you commented(attachment 8844357 [details]), for 'Response to Mozilla's list of Potentially Problematic Practices',do you mean that we need to respond to all from point 1)to point 14)?

Sorry for disturbing you. Your reply will be greatly appreciated.
Hi Ruby,

Regarding to CAs response to 'Recommended Practices'(#1~#12) and 'Problematic Practices'(#1~#14), please respond to the items marked as '???' and clarify and correct the rest of them.

Note:
1. For 'Recommended Practices' please refer to:
https://wiki.mozilla.org/CA:Recommended_Practices#CA_Recommended_Practices
2. For 'Problematic Practices' please refer to:
https://wiki.mozilla.org/CA:Problematic_Practices#Potentially_problematic_CA_practices

Thank you so much!

Kind regards,
Aaron
Hi Ruby,

Please also 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

Please let me know if you have any question, thank you!


Kind regards,
Aaron
Whiteboard: [ca-verifying] → [ca-verifying] - Need BR Self Assessment
Product: mozilla.org → NSS
Hi Aaron,

Thank you very much for your comments. Here I attached the reply for your comments of the 1st round of Information Verification as well as the self assessment of SHECA. Please check.
Hi, SHECA is applying for inclusion in Mozilla for two roots. UCA Global G2 Root is for the issuance of OV SSL and CodeSigning certificates and UCA Extended Validation Root is for the issuance of EV SSL and EV CodeSigning certificates. Thanks.
I believe Mozilla no longer handles code-signing.
Whiteboard: [ca-verifying] - Need BR Self Assessment → [ca-verifying] - BR Self Assessment Received
Hi,

Thank you for information provided!

1. BR Self Assessment received as Comment#14 - verifying
2. Comment reply for 1st round of information verification - doing 2nd round of information verification, and update into Salesforce.

And Yes, Mozilla is no longer handling code-signing


Kind regards,
Aaron
Hi,

As verifying your BR Self Assessment, the result of test websites {Valid/Expired/Revoked) you provided for 2 root certs are not shown correctly. Please help to double confirm. 

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

Thanks,
Aaron
By the way, it is also failure when doing EV test. 

ev-checker reported failure: ev-checker did not exit successfully. exit status 1, Stderr: BuildCertChain failed: SEC_ERROR_UNKNOWN_ISSUER Peer's Certificate issuer is not recognized.

EV Testing as described here https://wiki.mozilla.org/PSM:EV_Testing_Easy_Version


Providing the correct test websites is helpful for EV test. You can also try testing with https://certificate.revocationcheck.com/ because frequently resolving the errors listed on that page will resolve problems with EV testing.

Thanks,
Aaron
Given more information regarding Comment#19 and Comment#20

I see that the test websites are as follows

UCA Global G2 Root
valid : https://ef-gb.wwwtrust.org  
revoked : https://re-gb.wwwtrust.org
expired : https://ex-gb.wwwtrust.org 

UCA Extended Validation Root
valid : https://ef-EV.sheca.com   
revoked : https://re-EV.sheca.com 
expired : https://ex-EV.sheca.com  

As discussed with Kathleen, we believe that the reason that the test websites are failing is because the web server is not serving up the intermediate cert(s) along with the end-entity cert. Please update the web servers and test to make sure you are able to access the test sites from outside your organization’s firewall.

Best regards,
Aaron
(In reply to Aaron Wu from comment #21)
> Given more information regarding Comment#19 and Comment#20
> 
> I see that the test websites are as follows
> 
> UCA Global G2 Root
> valid : https://ef-gb.wwwtrust.org  
> revoked : https://re-gb.wwwtrust.org
> expired : https://ex-gb.wwwtrust.org 
> 
> UCA Extended Validation Root
> valid : https://ef-EV.sheca.com   
> revoked : https://re-EV.sheca.com 
> expired : https://ex-EV.sheca.com  
> 
> As discussed with Kathleen, we believe that the reason that the test
> websites are failing is because the web server is not serving up the
> intermediate cert(s) along with the end-entity cert. Please update the web
> servers and test to make sure you are able to access the test sites from
> outside your organization’s firewall.
> 
> Best regards,
> Aaron

Hi Aaron,
Thank you very much for your advice. We have updated our web server according to your suggestion and the test results are correct now. Screenshots of the test results of EV certificates are attached.
Attached image test result of EV certificates (obsolete) —
Attachment #8877888 - Attachment is obsolete: true
Hi Ruby,

Thanks to update your web server, now i've verified all test websites.

I would like to double confirm about the certificate download URL of UCA Extended Validation Root, is it still the following? I saw you use EV Root.cer for EV test in your screentshot, any new update for certificate file?

Certificate download URL (on CA website): http://www.sheca.com/download/getdownloadforpdf/73

Kind regards,
Aaron
(In reply to Aaron Wu from comment #27)
> Hi Ruby,
> 
> Thanks to update your web server, now i've verified all test websites.
> 
> I would like to double confirm about the certificate download URL of UCA
> Extended Validation Root, is it still the following? I saw you use EV
> Root.cer for EV test in your screentshot, any new update for certificate
> file?
> 
> Certificate download URL (on CA website):
> http://www.sheca.com/download/getdownloadforpdf/73
> 
> Kind regards,
> Aaron

Hi Aaron,

Please use the URL ( http://www.sheca.com/download/getdownloadforpdf/191 )  to get the root file for EV certificate.

Thank you! 
Best Regards,
Ruby
(In reply to Aaron Wu from comment #27)
> Hi Ruby,
> 
> Thanks to update your web server, now i've verified all test websites.
> 
> I would like to double confirm about the certificate download URL of UCA
> Extended Validation Root, is it still the following? I saw you use EV
> Root.cer for EV test in your screentshot, any new update for certificate
> file?
> 
> Certificate download URL (on CA website):
> http://www.sheca.com/download/getdownloadforpdf/73
> 
> Kind regards,
> Aaron
(In reply to xiongyuanyuan from comment #28)
> (In reply to Aaron Wu from comment #27)
> > Hi Ruby,
> > 
> > Thanks to update your web server, now i've verified all test websites.
> > 
> > I would like to double confirm about the certificate download URL of UCA
> > Extended Validation Root, is it still the following? I saw you use EV
> > Root.cer for EV test in your screentshot, any new update for certificate
> > file?
> > 
> > Certificate download URL (on CA website):
> > http://www.sheca.com/download/getdownloadforpdf/73
> > 
> > Kind regards,
> > Aaron
> 
> Hi Aaron,
> 
> Please use the URL ( http://www.sheca.com/download/getdownloadforpdf/191 ) 
> to get the root file for EV certificate.
> 
> Thank you! 
> Best Regards,
> Ruby

Hi,

Here is the URL(http://www.sheca.com/download/getdownloadforpdf/193) for downloading the subordinate certificate(SHECA Extended Validation SSL CA).
BR,
Ruby
(In reply to Aaron Wu from comment #27)
> Hi Ruby,
> 
> Thanks to update your web server, now i've verified all test websites.
> 
> I would like to double confirm about the certificate download URL of UCA
> Extended Validation Root, is it still the following? I saw you use EV
> Root.cer for EV test in your screentshot, any new update for certificate
> file?
> 
> Certificate download URL (on CA website):
> http://www.sheca.com/download/getdownloadforpdf/73
> 
> Kind regards,
> Aaron

Hi Aaron,

I am sorry that the earlier URL( http://www.sheca.com/download/getdownloadforpdf/73 )was attached with an old EV root certificate which was issued with SHA1 in 2013 and was never in use. The one that I applied for root inclusion in your program was issued with SHA256 in 2015, and what I have submitted to you in the application information form are all about the latter one with SHA256 (URL: http://www.sheca.com/download/getdownloadforpdf/191).
Hi Ruby,

Yes, I noticed that the previous ones seems pretty old and that's why I asked for any newer version. 

Thank you so much for your update!

Cheers,
Aaron
Hi Aaron,

We have just passed the WebTrust Audit for period from 20160501 to 20170430, the new reports are available on:
https://cert.webtrust.org/ViewSeal?id=2264
https://cert.webtrust.org/ViewSeal?id=2263
https://cert.webtrust.org/ViewSeal?id=2262
https://cert.webtrust.org/ViewSeal?id=2265
If you have any questions, please contact me.
Thank you!
Hi Ruby,

Noted with thanks!

We still keep working on all document/information verification, will let you know if anything else need your input. Please stay tuned, thanks!

Kind regards,
Aaron
One question is that I am going to re-verify the certs lately, but the pages are all shown as 404 error.

http://www.sheca.com/download/getdownloadforpdf/191
http://www.sheca.com/download/getdownloadforpdf/193

Could you help to double check? Thanks!

Regards,
Aaron
(In reply to Aaron Wu from comment #34)
> One question is that I am going to re-verify the certs lately, but the pages
> are all shown as 404 error.
> 
> http://www.sheca.com/download/getdownloadforpdf/191
> http://www.sheca.com/download/getdownloadforpdf/193
> 
> Could you help to double check? Thanks!
> 
> Regards,
> Aaron

Hi Aaron,

I am sorry the old pages are not available because SHECA has just just changed its official Internet website. The current URLs for the submitted cert files are given below.
https://www.sheca.com/repository/certs/uca-global-g2-root.cer
https://www.sheca.com/repository/certs/UCA%20Extended%20Validation%20Root.cer

Best Regards,
Ruby
Hi Ruby,

Thanks for updating root cert files/urls, they look good now.

When re-verifyinf the test websites for UCA Global G2 Root, i cannot get correct test result (maybe web server issue). Could you please double check?
 - valid : https://ef-gb.wwwtrust.org  
 - revoked : https://re-gb.wwwtrust.org
 - expired : https://ex-gb.wwwtrust.org

By the way, the test websites of UCA Extended Validation Root look good to me.

Thanks,
Aaron
Hi Aaron,

We are very sorry for late responde. Ruby left SHECA last August, and I took over her job since last month.

For the isssue mentioned in comment 36, I believe it's due to the web server. since we find the test websiteds for UCA Global G2 Root alright. Except the revoked test website that showed as invalid or expired because the cert was already expired when you tested it. We replaced the certificate and it works well now. 

I'll attach the screenshots of these websites below, if it look different to you then I believe it's the web server issue.

Many thanks,
Toria
Flags: needinfo?(awu)
Attached image Valid_Web Screeshot.png
Screenshot of the test website(Valid) of UCA Global G2 Root
Flags: needinfo?(awu)
Flags: needinfo?(awu)
Attached image Revoked_Web Screeshot.png (obsolete) —
Screenshot of test website(revoked) of UCA Global G2 Root
Flags: needinfo?(awu)
Attachment #8941739 - Attachment is obsolete: true
Flags: needinfo?(awu)
Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324
Assignee: awu → kwilson
Hi Wilson,

Is this bug reassigned to you now? Please kindly go through comment 37, we have re-agrranged the test websites.

(In reply to Firefox Product Integrity Bug Husbandry Bot (contact :emceeaich) from comment #41)
> Bulk reassign, see https://bugzilla.mozilla.org/show_bug.cgi?id=1430324
Seems that I have no access to bug 1430324, please kindly help me with it.
Flags: needinfo?(kwilson)
Attached file UCA-Global-G2-Root.crt
Flags: needinfo?(kwilson)
This root inclusion request is ready for the Detailed CP/CPS Review phase, step 3 of
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
so assigning this bug to Wayne.
Assignee: kwilson → wthayer
Whiteboard: [ca-verifying] - BR Self Assessment Received → [ca-cps-review] - KW 2018-03-28
This is the next inclusion request that I will be reviewing.
Flags: needinfo?(wthayer)
Hi Wayne,

We have just passed the WebTrust Audit for period from 20170501 to 20180430, the new reports are available on:
WebTrust:                 https://cert.webtrust.org/ViewSeal?id=2470
WebTrust SSL:             https://cert.webtrust.org/ViewSeal?id=2471
WebTrust EV:              https://cert.webtrust.org/ViewSeal?id=2472
WebTrust EV Code Signing: https://cert.webtrust.org/ViewSeal?id=2473

If you have any questions, please contact me.
Thank you!
I have performed a preliminary review of this request and found a number of concerns. This one is a clear violation of Mozilla policy (section 1.1 "scope" combined with section 3 "audits") that prevents this request from proceeding:

* The SHECA Global G3 Code Signing subordinate [5] and the SHECA Extended Validation Code Signing CA [6] are not constrained to code signing and are not named on the most recent BR audit.

The following issues should also be addressed:
* A few unrevoked certificates with IP Addresses encoded as DNSName type in the SAN [3]
* Common Name not in SAN and multiple CN entries in one unrevoked cert [4]
* Improper encoding of 17 unrevoked EV certificates [7][8]
* Section 4.2 of all policy docs is missing the recognized CAA domain names. The EV CP and/or CPS do not state SHECA’s CAA processing policies. BR section 2.2 requires both.
* Global G2 Root CPS section 3.2.5(3) does not document the BR methods used to perform domain validation as recommended by Mozilla policy section 2.2(3), nor does it “clearly specify” the procedures used. As of 1-July when version 2.6 of Mozilla policy went into effect, procedures used for IP address and email address validation also must be clearly documented in the CP/CPS.

Also, please provide the BR audit statement covering the period from 1-May 2014 to 30-April 2015 as I am unable to locate a copy.

This request is on-hold pending a response from the CA on each of these issues.

[3] https://crt.sh/?CAID=40266&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[4] https://crt.sh/?id=329498950&opt=cablint
[5] https://crt.sh/?id=154596200
[6] https://crt.sh/?id=154596198
[7] https://crt.sh/?caid=40251&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[8] https://crt.sh/?caid=83252&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
Flags: needinfo?(xiongyuanyuan)
Whiteboard: [ca-cps-review] - KW 2018-03-28 → [ca-cps-review] - Pending CA Response 09-July 2018
Hello Wayne,
Thanks for comment.

* Fistly, both of SHECA Global G3 Code Signing and the SHECA Extended Validation Code Signing were disabled in late May,2018 and no longer issue any certificates.
These two subordinate CAs were issued in 2015 and early 2016, before the  publication of Minimum Requirements of Issuance and Management of Publicly Trusted Code Signing Certificates. We didn't notice the necessary of contraint then.
But these two subordinate CAs are never meant to issue and have never issued SSL certs, as you can tell by their names. So we didn't include these code signing used sub-CAs in SSL audit report, but in code signing report.


As for the following issues:
* For the first three issue, we are revoking all these certs and trying to figure out the underlying reason. I will update the progress.
* For the concerning about CP/CPS, I wonder if you are reviewing the right version which already document the BR methods used to perform domain and IP address validation in section 3.5. 
Please refer to the latest version as linked in comment 48:
CP: https://assets-cdn.sheca.com/documents/unitrust-certificate-policy-en-v1.3.pdf
CPS: https://assets-cdn.sheca.com/documents/sheca-certification-practice-statement-en-v3.6.pdf
EV CP: https://assets-cdn.sheca.com/documents/unitrust-ev-certificate-policy-en-v1.4.pdf
EV CPS: https://assets-cdn.sheca.com/documents/unitrust-ev-certification-practice-statement-en-v1.4.pdf

* For CAA Record issue, we started to perform CAA checking in last Sept.. We will revise our CP/CPS accordingly to declare the recognized CAA domain names and complement EV CPS.
Flags: needinfo?(wthayer)
Sincerely sorry, I just made a mistake. We haven't yet updated the domain validation method in Global G2 Root CPS. We will update these part in the next version as soon as possible.
Flags: needinfo?(wthayer)
(In reply to chenxiaotong from comment #52)
> 
> * Fistly, both of SHECA Global G3 Code Signing and the SHECA Extended
> Validation Code Signing were disabled in late May,2018 and no longer issue
> any certificates.
> These two subordinate CAs were issued in 2015 and early 2016, before the 
> publication of Minimum Requirements of Issuance and Management of Publicly
> Trusted Code Signing Certificates. We didn't notice the necessary of
> contraint then.
> But these two subordinate CAs are never meant to issue and have never issued
> SSL certs, as you can tell by their names. So we didn't include these code
> signing used sub-CAs in SSL audit report, but in code signing report.
> 
Mozilla policy does not yet require subordinate CAs to be constrained, but if they are not constrained then they fall within the scope of the Mozilla policy and must be audited. If you do not want to include these subordinate CAs in your BR and EV audits, then they must be revoked. It is not enough to "disable" them.
We understand and respect the policy.
SHECA will evaluate the effect to subscribers, find a solution and then revoke these two subordinate CAs ASAP.

Besides,the BR audit statement covering the period from 1-May 2014 to 30-April 2015 is attached below.
Flags: needinfo?(wthayer)
BR:                        https://cert.webtrust.org/SealFile?seal=1882&file=pdf
Other audit reports covering May,1,2014-Apr.,30,2015 for reference
EV Guideline:              https://cert.webtrust.org/SealFile?seal=1883&file=pdf
Certification Authorities: https://cert.webtrust.org/SealFile?seal=1881&file=pdf
Flags: needinfo?(wthayer)
Hello Wayne,

We have revised our CPS accordingly and publish the latest version in July 12. Links as below:

CPS V3.6.1:    https://assets-cdn.sheca.com/documents/sheca-certification-practice-statement-en-v3.6.1.pdf
EV CPS V1.4.1: https://assets-cdn.sheca.com/documents/unitrust-ev-certification-practice-statement-en-v1.4.1.pdf

As for the issues involving subscriber certificates, we are informing and communicate closely with the subscribers. We will update the process ASAP.
Flags: needinfo?(wthayer)
Hi Rob,

Thanks for bringing this to our attention. 
We did an investigation, and conducted an initial report.

1.How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

On July 9th,2018, Wayne Thayer noticed the some problematic certificates during the CPS Review, including 17 unrevoked improper encoded EV certificates; 1 unrevoked certificate with multiple CN entries, 2 certificates with IP Addresses encoded as DNS Name type in the SAN.
https://bugzilla.mozilla.org/show_bug.cgi?id=1309797#c51

2.A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

* 2018/07/09 Wayne Thayer reported the problematic certificates mentioned above
* 2018/07/09 SHECA suspended the issuance of EV SSL certificates and OV SSL certificates containing IP address.
* 2018/07/10 SHECA identified the reason causing wrong issuance of certificates with IP Addresses encoded as DNS Name type in the SAN
* 2018/07/10 SHECA identified the reason of issuing incorrectly coded EV SSL certificate
* 2018/07/10 SHECA identified the reason of issuing OV SSL certificates containing multiple CN entries
* 2018/07/10 SHECA began to inform subscribers former certificates have to be revoked, and issue new certificate
* 2018/07/11 SHECA began to do extra manual verification of CSR , and refuse to issue certificate for CSR containing more than one CN entries.
* 2018/07/12 SHECA scanned all valid certificates to see if there were any other such incorrect certificates
* 2018/07/12 SHECA revoked OV SSL certificates with multiple CN entries.
* 2018/07/16 SHECA fixed the IP Addresses encoded as DNS Name type in the SAN
* 2018/07/16 SHECA fixed the incorrect coding error of EV SSL
* 2018/07/17 SHECA revoked all unexpired incorrect coded EV SSL certificates

3.Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.
SHECA suspended the issuance of OV SSL containing IP address and EV SSL, and performed extra manual verification, and refuse to issue certificate for CSR with multiple CN entries.

4.A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
* OV SSL Certificate with multiple CN entries
Certificate 1: https://crt.sh/?id=329498950 (Revoked)

* Certificates with IP Addresses encoded as DNS Name type in the SAN
Certificate 1: https://crt.sh/?id=493129755  (To be revoked)
Certificate 2: https://crt.sh/?id=509820552  (To be revoked)

* Incorrect coded EV SSL certificates
Certificate 1: https://crt.sh/?id=415168215 (Revoked)
Certificate 2: https://crt.sh/?id=415168208 (Revoked)
Certificate 3: https://crt.sh/?id=415168219 (Revoked)
Certificate 4: https://crt.sh/?id=389816605 (Revoked)
Certificate 5: https://crt.sh/?id=393413131 (Revoked)
Certificate 6: https://crt.sh/?id=376234272 (Pre-certificate, not issued)
Certificate 7: https://crt.sh/?id=375070920 (Pre-certificate, not issued)
Certificate 8: https://crt.sh/?id=326814195 (Expired)
Certificate 9: https://crt.sh/?id=323640949 (Revoked)
Certificate 10: https://crt.sh/?id=326023470 (Revoked)
Certificate 11: https://crt.sh/?id=226628292 (Expired)
Certificate 12: https://crt.sh/?id=79581130 (Expired)
Certificate 13: https://crt.sh/?id=226658311 (Expired)
Certificate 14: https://crt.sh/?id=270071540 (Revoked)
Certificate 15: https://crt.sh/?id=462466761 (Expired)
Certificate 16: https://crt.sh/?id=462466765 (Revoked)
Certificate 17: https://crt.sh/?id=461426362 (Revoked)

5.The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
Please refer to section 4.

6.Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
* IP Addresses encoded as DNS Name type
This issue is caused by manual misoperation. Currently, SHECA manually selects the type of domain name or IP when entering SAN items, and these two certificates issuance is caused by human error. 
* OV SSL with multiple CN entries
We noticed that there are 2 CN entries in the CSR document submitted by subscriber. After verifying that the contents of the CSR file are consistent with the input data, the CA system completely extracts the DN items in the file, resulting in the issued certificate containing two CN entries.
* Improper encoded EV certificates
During a system update, code error caused the CA system ignored the coding type of the system configuration, and the DN information was encoded using the default coding.

7.List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

* Suspend the issuance service of EV SSL and OV SSL certificate containing IP address. ( Issuance service resumed since July 18th)
* Update the system to automatically judge type of DNS Name or IP address in the SAN, reduce manual process to reduce manual error.( Completed )
* Manually double check the CSR document submitted by applicants, and refuse to issue certificated containing multiple CN entries. (Executed)
* Fixed code error to ensure CA system can correctly use the designated code to encode DN information. (Completed)
* No longer fully extract the DN information contained in CSR, the DN content of CSR file is only used for verification. ( Expected to be fixed on July 20th)
* Use lint tools( cablint, x509lint and zlint )to check before the certificate signature, terminate the certificate issuing process if any problem found, and record logs. (Expected to be fixed on July 31th)
Hi Wayne,
Besides, we just noticed the links of audit report covering 2014-2015 expired in recent days, so please refer to the PDF documents attached below for reference.
Flags: needinfo?(wthayer)
As for the issue about codes signing, SHECA already informed all related subscribers who hold code signing certificates issued by subordinate CA SHECA Global G3 Code Signing and SHECA Extended Validation Code Signing, and issued new codes signing certificates for them. Up to July 19th, we have received confirmation from all subscribers. 
We will soon revoke the SHECA Global G3 Code Signing and the SHECA Extended Validation Code Signing subordinate CAs.
Hello Wayne,

We revoked the SHECA Global G3 Code Signing and the SHECA Extended Validation Code Signing subordinate CA yesterday. 
Please kindly check.
Flags: needinfo?(wthayer)
(In reply to chenxiaotong from comment #65)
> Hello Wayne,
> 
> We revoked the SHECA Global G3 Code Signing and the SHECA Extended
> Validation Code Signing subordinate CA yesterday. 
> Please kindly check.

I've confirmed that these two subordinate CAs have been revoked and I have updated CCADB. I will restart my review of this request soon.
Flags: needinfo?(wthayer)
I've reviewed all four CP/CPS documents and found the following issues:

* Non-EV CP section 3.2.4 seems to state that an email address included in a certificate will not be verified. This would violate the BRs and Mozilla policy.
* Non-EV CP section 4.1 seems to give SHECA the authority to issue “test” certificates from trusted hierarchies without performing any validation or providing any warranty. 
* Section 4.6 of the non-EV CP/CPS seems to permit certificate renewal without revalidation, even when the information is more than 825 days old.
* EV CP/CPS section 4.9.1.1 do not include all BR required revocations reasons, such as (6).
* The CP/CPS documents contain version histories, but they don’t describe what changed in each version.
* The non-EV CP and CPS section 6.1 seem to permit CA generation of key pairs for SSL certificates in violation of section 5.2 of Mozilla policy.

Also:
* As of 8-August, both root CRLs have a “Next update” of 29-June 2018, meaning they are expired.
* The valid EV test site https://ef-EV.sheca.com delivers a revoked certificate, serial number 453f3d6ed474bc46777a6ed5b5080df7

Would you like to address any of these issues before I begin the public comment period?
Flags: needinfo?(xiongyuanyuan) → needinfo?(chenxiaotong)
Hi Wayne,

Let me address these issues one by one.

* Non-EV CP section 3.2.4 seems to state that an email address included in a certificate will not be verified. This would violate the BRs and Mozilla policy.

Non-EV CP section 3.2.4 only state we don’t perform email address verification for individual and organization certificate. In practice we do verify the email address in SSL certificate, conforming to Non-EV CPS section 3.2.8..
SHECA is going to verify the email address for individual and organization certificate as well. We will revise this section in next version of CP/CPS.

* Non-EV CP section 4.1 seems to give SHECA the authority to issue “test” certificates from trusted hierarchies without performing any validation or providing any warranty. 

We state in Non-EV CPS section 4.1.1.1 SHECA do not issue SSL test certificates for subscribers.  As for individual and institution certificates, in practice, SHECA verify the applicant’s identity, but give no warranty to the authentication of information in certificate application.

* Section 4.6 of the non-EV CP/CPS seems to permit certificate renewal without revalidation, even when the information is more than 825 days old.

Current renewal process does not apply to SSL certificates, but for other identification certificates. SHECA have no renewal process for SSL certificates, for subscribers who have renewal request, we performed a complete new application process.
SHECA plan to apply renewal process for SSL certificate recently and we will complement the renewal process and 825 days limitation in the next version CP/CPS.

* EV CP/CPS section 4.9.1.1 do not include all BR required revocations reasons, such as (6).

SHECA will complement the required revocation reasons in the next version CP/CPS.


* The CP/CPS documents contain version histories, but they don’t describe what changed in each version.

SHECA will record abstract of the changes in later versions’ update.

* The non-EV CP and CPS section 6.1 seem to permit CA generation of key pairs for SSL certificates in violation of section 5.2 of Mozilla policy.

We have performed an investigation of Section 6.1 of Non-EV CP/CPS.

Finally, we confirm that SHECA has never generated key pairs on behalf of subscribers. 
This section was wrote for a plan to provide this service for subscribers of online doc-signing certificate at that time. But this plan was ultimately unformed. Thus, we never adopt this method to generate private key in any business.
 
Until we really plan to start this kind of service for special business, SHECA will delete relevant description and revise the description of key pair generation process in CP/CPS according to practical situation.

If we plan to provide this service in the future, we will revise relevant content in CP/CPS and state the scope of application accordingly. 
According to requirements of Mozilla policy, SHECA will never provide key generation service in SSL and code-signing business.

Also:
* As of 8-August, both root CRLs have a “Next update” of 29-June 2018, meaning they are expired.

We checked both CRLs, “Next update” of both is 30-September. Please see attached CRL files below. 
If you don’t mind, I wonder where did you query the CRLs having a “next update” of 29-June?


* The valid EV test site https://ef-EV.sheca.com delivers a revoked certificate, serial number 453f3d6ed474bc46777a6ed5b5080df7

The test site changed, as we updated in the CCADB, please refer to the following sites:
Test Website – Valid:      https://rsaevg1.good.sheca.com/ 
Test Website – Revoked:   https://rsaevg1.revoked.sheca.com/ 
Test Website – Expired:    https://rsaevg1.expired.sheca.com/

Thanks for bringing these issues to our attention, we do have some negeligence, especially in statement of applicable scope of some special workflow.
Concerning that, we are revising and updating our CP/CPS and work flow accordingly. SHECA would like to go into the public comment period after finishing the corrective actions.
Flags: needinfo?(chenxiaotong) → needinfo?(wthayer)
Flags: needinfo?(wthayer)
(In reply to chenxiaotong from comment #68)
> Also:
> * As of 8-August, both root CRLs have a “Next update” of 29-June 2018,
> meaning they are expired.
> 
> We checked both CRLs, “Next update” of both is 30-September. Please see
> attached CRL files below. 
> If you don’t mind, I wonder where did you query the CRLs having a “next
> update” of 29-June?
> 
I was using https://certificate.revocationcheck.com to query your old test sites when I saw this error. I am not able to reproduce it.
> 
> * The valid EV test site https://ef-EV.sheca.com delivers a revoked
> certificate, serial number 453f3d6ed474bc46777a6ed5b5080df7
> 
> The test site changed, as we updated in the CCADB, please refer to the
> following sites:
> Test Website – Valid:      https://rsaevg1.good.sheca.com/ 
> Test Website – Revoked:   https://rsaevg1.revoked.sheca.com/ 
> Test Website – Expired:    https://rsaevg1.expired.sheca.com/
> 
I have updated the test sites in my documents. I am seeing that the CRL is expired for the non-EV 'expired' test site's certificate: https://certificate.revocationcheck.com/rsaovg3.expired.sheca.com

> Thanks for bringing these issues to our attention, we do have some
> negeligence, especially in statement of applicable scope of some special
> workflow.
> Concerning that, we are revising and updating our CP/CPS and work flow
> accordingly. SHECA would like to go into the public comment period after
> finishing the corrective actions.

Please update this bug when the new CP/CPS are published.
Hello Wayne,

We just updated CP/CPS as below:
Non-EV CP     https://assets-cdn.sheca.com/documents/unitrust-certificate-policy-en-v1.4.pdf
Non-EV CPS    https://assets-cdn.sheca.com/documents/sheca-certification-practice-statement-en-v3.6.2.pdf
EV CP         https://assets-cdn.sheca.com/documents/unitrust-ev-certificate-policy-en-v1.5.pdf
EV CPS        https://assets-cdn.sheca.com/documents/unitrust-ev-certification-practice-statement-en-v1.4.2.pdf


As for the CRL Problem, SHECA distributes CRLs in segmented form. Certificates issued within a period of time use the same CRL according to a certain grouping rule. When all the certificates corresponding to a CRL are expired, SHECA stop updating this CRL. We have updated the maintenance method of CRL for SSL certificate and Code signing certificate, these CRLs will be continuously updated.
Flags: needinfo?(wthayer)
I have begin the discussion period for this request on the mozilla.dev.security.policy forum with the following comments:

==Good==
* SHECA plans to issue code signing and TLS certificates from separate intermediate certificates.
* While the non-EV CP permits external RAs, it expressly prohibits using them to issue SSL certificates.

==Meh==
* Issuance of SHA-1 certs after the CA/Browser Forum deadline [1][2] This issuance was under an older root that is not part of the current request.
* Non-EV CPS section 7.1.2 states that serial numbers are random but does not specify the entropy requirement in BR section 7.1. The EV CP and CPS do not contain any information about serial numbers.
* On 8-August, both root CRLs showed a “Next update” of 29-June 2018 when tested from revocationcheck.com [3], meaning they were expired. Neither SHECA or I were able to reproduce this problem at a later date.
* For reference, an older root inclusion request that SHECA ultimately decided to replace with the current request is at https://bugzilla.mozilla.org/show_bug.cgi?id=566310

==Bad==
* A few unrevoked certificates with IP Addresses encoded as DNSName type in the SAN [4]. I reported these to SHECA in this bug and they said that they would revoke them, but as of this writing they are still valid.
* Common name not in SAN and multiple CN entries in one unrevoked cert [5]. I reported these to SHECA in this bug and they filed an incident report and revoked them.
* The SHECA Global G3 Code Signing subordinate [6] and the SHECA Extended Validation Code Signing CA [7] are not constrained to code signing and are not named on the most recent BR audit. I reported these to SHECA in this bug and they chose to revoke them.
* Improper encoding of 17 EV certificates [8][9]. I reported these to SHECA in this bug and they filed an incident report and revoked them.
* Section 4.2 of all policy docs was missing the recognized CAA domain names. The EV CP and/or CPS did not state SHECA’s CAA processing policies. I reported these to SHECA in this bug and they updated both CPS documents.
* Global G2 Root CPS section 3.2.5 did not document the BR methods used to perform domain validation as recommended by Mozilla policy section 2.2(3), nor did it “clearly specify” the procedures used. I reported this to SHECA in the bug and they updated both CPS documents.
* Version 1.3 of the Global G2 Root CP and version 3.6 of the Global G2 Root CPS were published more than a year after the prior versions in violation of Mozilla policy section 3.3.
* Non-EV CP section 3.2.4 seemed to state that an email address included in a certificate will not be verified. SHECA responded that they do verify email addresses in SSL certificates, and they clarified this section of the CP.
* Section 4.6 of the non-EV CP/CPS seemed to permit certificate renewal without revalidation, even when the information is more than 825 days old. SHECA updated the CPS to clarify that SSL renewal is treated as a new application.
* EV CP/CPS section 4.9.1.1 did not include all BR required revocations reasons, such as (6). SHECA has fixed this in the latest version of the EV CPS.
* The CP/CPS documents contain version histories, but they didn’t describe what changed in each version. SHECA began including this information in the latest versions of these documents.
* The non-EV CP and CPS section 6.1 seem to permit CA generation of key pairs for SSL certificates in violation of section 5.2 of Mozilla policy. SHECA states that they have never generated key pairs for Subscribers and revised this section of the CPS, but my interpretation is that the revision does not forbid SHECA from generating subscriber key pairs.

This begins the 3-week comment period for this request [10].

I will greatly appreciate your thoughtful and constructive feedback on the acceptance of these roots into the Mozilla CA program.

- Wayne

[1] https://crt.sh/?cablint=211&iCAID=505&minNotBefore=2016-01-01
[2] https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/771PAebFAQAJ
[3] https://certificate.revocationcheck.com/rsaovg3.expired.sheca.com
[4]https://crt.sh/?CAID=40266&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[5] https://crt.sh/?id=329498950&opt=cablint
[6] https://crt.sh/?id=154596200
[7] https://crt.sh/?id=154596198
[8] https://crt.sh/?caid=40251&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[9] https://crt.sh/?caid=83252&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[10] https://wiki.mozilla.org/CA/Application_Process
Flags: needinfo?(wthayer)
Whiteboard: [ca-cps-review] - Pending CA Response 09-July 2018 → [ca-in-discussion] - ends after 21-September 2018
Hi Wayne,

As we said in public comment, we just published the new CP/CPS, which added the changes description of all historical veresions, as well as stated that for certificates issued by UCA Global G2 Root and UCA Extended Validation Root, SHECA must not generate key pair for subscribers.
Please refer to links below for details:
Non-EV CP   https://assets-cdn.sheca.com/documents/unitrust-certificate-policy-en-v1.4.1.pdf
Non-EV CPS  https://assets-cdn.sheca.com/documents/sheca-certification-practice-statement-en-v3.6.3.pdf
EV-CP       https://assets-cdn.sheca.com/documents/unitrust-ev-certificate-policy-en-v1.6.pdf
EV-CPS      https://assets-cdn.sheca.com/documents/unitrust-ev-certification-practice-statement-en-v1.4.3.pdf

Thanks.
Toria Chen
Flags: needinfo?(wthayer)
I am satisfied by the following statement that was added: "For certificates issued by UCA Global G2 Root and UCA Extended Validation Root, SHECA must not generate key pair for subscribers."

There is still one week left in the discussion period.
Flags: needinfo?(wthayer)
The discussion period for this request has ended. I believe that all concerns have been resolved, so I am recommending approval of this request.

Link to the discussion: https://groups.google.com/d/msg/mozilla.dev.security.policy/2RCO0P-gX0g/mp6mWLkPAwAJ
Whiteboard: [ca-in-discussion] - ends after 21-September 2018 → [ca-pending-approval]
Thanks Wayne.
SHECA will kepp following up the subsequent processes.


Regards,
Toria Chen
As per Comment #75, and on behalf of Mozilla I approve this request from Shanghai Electronic Certification Authority Co., Ltd. (SHECA) to include the following root certificates:

** 'UCA Global G2 Root' (Email, Websites)
** 'UCA Extended Validation Root' (Websites), enable EV

I will file the NSS and PSM bugs for the approved changes.
Whiteboard: [ca-pending-approval] → [ca-approved] - Pending NSS and PSM code changes
Depends on: 1496214
Depends on: 1496215
I have filed bug #1496214 against NSS and bug #1496215 against PSM for the actual changes.
QA Contact: kwilson
Whiteboard: [ca-approved] - Pending NSS and PSM code changes → [ca-approved] - In NSS 3.41, Firefox 65 - Pending PSM code changes
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Whiteboard: [ca-approved] - In NSS 3.41, Firefox 65 - Pending PSM code changes → [ca-approved] - In NSS 3.41, Firefox 65 - EV enabled in Firefox 66
You need to log in before you can comment on or make changes to this bug.