566310 - Add SHECA root certificates

Status: RESOLVED DUPLICATE of bug 1309797

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

Description

[John Cui]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: 

CA Details

CA Company/Organization Name:Shanghai Electronic Certification Authority Co., Ltd.

Website:www.sheca.com

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. SHECA currently has two root certificates, “UCA Global Root” and “UCA Root”.  Under the root certificates, there are two subordinate CAs, “SHECA Global” and “SHECA”. “SHECA Global” is signed by UCA Global Root for the issuance of web server certificates.  “SHECA” is signed by UCA Root and is used for the issuance of web server certificates and others.

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


Certificate Details

Certificate Name:UCA Global Root
When applying a certificate, end entities must offer real materials and information. The list of required materials is described in CPS and CP. Subscribers must formally accept and be liable to the terms specified by SHECA.  SHECA would check the completeness and validity of the materials provided by the subscribers.  If necessary, SHECA would obtain additional information from third parties.

There is only one subordinate CA “SHECA Global” signed by UCA Global Root, which is operated internally for the issuance of web server certificates.

Certificate HTTP download URL :http://ldap2.sheca.com/root/ucaglobalroot.der
Version: X.509 V3
SHA1 Fingerprint:0b 97 2c 9e a6 e7 cc 58 d9 3b 20 bf 71 ec 41 2e 72 09 fa bf
Public key length (for RSA, modulus length) in bits:4096Bits
Valid From (YYYY-MM-DD):2008-01-01
Valid To (YYYY-MM-DD):2037-12-31
CRL HTTP URL:http://ldap2.sheca.com/root/ucaglobalsub.crl
CRL issuing frequency for end-entity certificates: 12 hours
Class:identity/organisationally-validated
Certificate Policy URL:http://www.sheca.com/policy/
CPS URL:http://www.sheca.com/cps/
Trust Bits: Websites (SSL/TLS),Code (code/document signing)
URL of website whose SSL certificate chains to this root:https://net.cj-pension.com.cn/

Certificate Name: UCA Root
When applying a certificate, end entities must offer real materials and information. Different types of certificates (e.g., Websites, E-mail, personal identity) require different application materials. The list of required materials is described in CPS and CP. Subscribers must formally accept and be liable to the terms specified by SHECA.  SHECA would check the completeness and validity of the materials provided by the subscribers.  If necessary, SHECA would obtain additional information from third parties.

There is only one subordinate CA “SHECA” signed by UCA Root, which is operated internally for the issuance of web server certificates, E-mail certificates, personal identity certificates and others.

Certificate HTTP download URL : http://ldap2.sheca.com/root/ucaroot.der
Version: X.509 V3
SHA1 Fingerprint: 82 50 be d5 a2 14 43 3a 66 37 7c bc 10 ef 83 f6 69 da 3a 67
Public key length in bits: 2048 Bits
Valid From (YYYY-MM-DD):2004-01-01
Valid To (YYYY-MM-DD):2029-12-31
CRL HTTP URL: http://ldap2.sheca.com/root/ucasub.crl
CRL issuing frequency for end-entity certificates: 12 hours
Class: identity/organisationally-validated
Certificate Policy URL: http://www.sheca.com/policy/
CPS URL: http://www.sheca.com/cps/
Trust Bits: Websites (SSL/TLS), Email (S/MIME), and/or Code (code/document signing)
URL of website whose SSL certificate chains to this root: https://ibanks.bankofshanghai.com 


Reproducible: Always

Comment 1

[Kathleen Wilson]

Accepting this bug so I can begin the Information Gathering and Verification phase as described in
https://wiki.mozilla.org/CA:How_to_apply#Information_gathering_and_verification

Comment 2

[John Cui]

thanks for your reply,the checklist as blow:

General information about the CA’s associated organization:
1, Name.
Shanghai Electronic Certification Authority co., ltd. (SHECA)
2, Website URL.
www.sheca.com
3, Organizational type.
  SHECA is operated by a commercial company.
4, Primary market / customer base.
  a)  For business corporations
	  Business corporations registered in mainland China
b)  For government agencies
Government agencies of China (e.g., tax bureau) 
c)  For individuals 
China citizens (including citizens from Hong Kong, Macau and Taiwan)
d)	  For servers 
Servers of business corporations which have been registered in mainland China
e)  For software developers
China citizens (individuals) or business corporations registered in mainland China


For each root CA whose certificate is to be included in Mozilla:
1, The name of the root CA.
(1)	UCA Global Root 
(2)	UCA Root
2, The root CA certificate: 
UCA Global Root: http://ldap2.sheca.com/root/ucaglobalroot.der  
UCA Root: http://ldap2.sheca.com/root/ucaroot.der
3, The X.509 certificate version.
  X.509.V3
4, SHA-1 fingerprint.
UCA Global Root: 0b 97 2c 9e a6 e7 cc 58 d9 3b 20 bf 71 ec 41 2e 72 09 fa bf
UCA Root: 82 50 be d5 a2 14 43 3a 66 37 7c bc 10 ef 83 f6 69 da 3a 67
5, Type of signing key. (For example, RSA or ECC.)
  RSA
6, Signing key parameters.
  UCA Global Root: 4096 bits 
UCA Root: 2048 bits
7, Valid from. (YYYY-MM-DD).
UCA Global Root: 2008-01-01
UCA Root: 2004-01-01
8, Valid to.
UCA Global Root: 2037-12-31
UCA Root: 2029-12-31
9, A description of the PKI hierarchy rooted at or otherwise associated with this root CA certificate.
  1) A list (or summary description) of CAs.
	Any subordinate CAs operated by the CA organization associated with the root CA.
There are two subordinate CAs, “SHECA Global” and “SHECA”. “SHECA Global” is signed by UCA Global Root for the issuance of web server certificates.  “SHECA” is signed by UCA Root and is used for the issuance of web server certificates and others.
	Any subordinate CAs operated by third parties.
None.
	Any other roots for which this root CA has issued cross-signing certificates.
None.
  2) A list of any other root CAs that have issued cross-signing certificates for this root CA.
    None.
  3) The extent and nature of contractual and technical controls exercised over subordinate CAs, including
	Whether or not subordinate CAs are constrained to issue certificates only within certain   domains.
        Subordinate CAs offer all kinds of domains from general public, including government, enterprise, organization, institute, individual and so on.
	Whether or not subordinate CAs can create their own subordinates.
        Subordinate CAs can not create their own subordinates.
4) The extent and nature of audits performed against subordinate CAs, including:
	Whether or not subordinate CAs are included within the scope of any audit(s) done against the root CA.
        Subordinate CAs are included within the audit.
	Whether or not subordinate CAs are subject to third-party audits independent of any audit(s) done against the root CA.
        Subordinate CAs are subject to third-party audit.
	The frequency at which any audit(s) for subordinate CAs are done.
Once a year.
10, UCA global Root issue certificates for enabling web or other servers to support SSL/TLS connections, Technical Descriptions as blow:
	key length in bits: 2048 Bits
	CRL : LDAP &HTTP 
	provide OCSP inquiring
	Class: identity/organisationally-validated
	CRL updates per 12 hours
	X.509 V 3
UCA Root issue certificates for enabling web or other servers to support SSL/TLS connections, signing and encrypting email messages ,and  digitally signing executable code objects. Technical Descriptions as blow:
	key length in bits: 2048 Bits or 1024Bits
	CRL : LDAP &HTTP 
	provide OCSP inquiring
	Class: identity/organisationally-validated
	CRL updates per 12 hours
	X.509 V 3
11, If SSL certificates are issued within the hierarchy rooted at this root CA certificate:
   1) Whether or not the domain name referenced in the certificate is verified to be owned/controlled by the certificate subscriber.
      For applying the web-site certificate, SHECA would ask applicant provide the ID Card (additonal Certificate of Organization Code would be needed, if the web-site belongs to some organization)，and provide additional proof of usufruct of web-site or inquire domain registry organization and other the third-parts to make sure the application has the right to use relevant web-site besides auditing the materials submitted by written. SHECA would take other independent measure to affirm the proprietary of the web-site. If SHECA requests applicant to provide some assistant and support, the applicant can’t refuse that.
   2) Whether or not the value of the Organization attribute is verified to be that associated with the certificate subscriber.
      When applying a certificate for business organization, the applicant should appoint and authorize some represent, once he/she signs that means he/she accepts relevant terms, and also takes the responsibility.   
      SHECA would checkup all the materials applied, the applicant should submit the evidence to prove that the organization or server exists actually, and thereinto, Industry and commerce business license and Organizations and agencies code card issued by government are necessary; The applicant has the obligation to ensure the material is real and needs to take relevant responsibility. If necessary, SHECE may get phone number and other ways of contact through the third-part, to confirm some information by contacting the organization (for example, to validate the position of deputy or whether someone on the table is the applicant). 
If SHECA have confirmed the identity of the organization, SHECA would trust the proof submitted by the applicant. This kind of authentication of identity is by face to face generally.
   3) Whether verification of the certificate subscriber conforms to the Extended Validation Certificate Guidelines issued by the CAB Forum.
      We do not offer EV certificates.
12, If email certificates are issued within the hierarchy rooted at this root CA certificate:
1)	Whether or not the email account associated with the email address in the certificate is verified to be owned/ controlled by the certificate subscriber.
When the applicant applys a certificate for email, SHECA would verify the ownership by sending an email to the relevant address and waiting for the response.
   2) Whether or not the identity information in the certificate is verified to be that of the certificate subscriber.
      When applying a certificate for personal, the applicant should signs that means he/she accepts relevant terms, and also takes the responsibility.   
      SHECA would checkup all the materials applied, the applicant should submit the copy the IC Card or someothers legal identity paper like passport , and SHECA will compare the copy with the original of identity certificate of the applicant.。The applicant has the obligation to ensure the material is real and needs to take relevant responsibility.
If SHECA have confirmed the identity of the personal, SHECA would trust the proof submitted by the applicant. This kind of authentication of identity is by face to face generally.
13, If code signing certificates are issued within the hierarchy rooted at this root CA certificate, whether or not the identity information in the certificate is verified to be that of the certificate subscriber.
When applying a certificate for code signing, SHECA would authenticate material of identity of the applicant face to face, including Industry and commerce business license, Organizations and agencies code card and identity card so on. Additionally, SHECA would ask the applicant to fill the application with information of identity and propose of the certificate, the application must declare that he/ she would not sign baleful software with the certificate.
14, If EV certificates are issued within the hierarchy rooted at this root, the EV policy OID(s) associated with those EV certificates.
   We do not offer EV certificates.
15, Example certificate(s) issued within the hierarchy rooted at this root, including the full certificate chain(s) where applicable. 
(1)	UCA Global Root: 
website certificate: https://net.cj-pension.com.cn/ （attachment: cj-pension.cer）
(2)	UCA Root: 
website certificate: https://ibanks.bankofshanghai.com （attachment: bankofshanghai.cer）
email certificate: attachment: email.der
identity certificate: attachment: identity.der
code signing certificate: attachment: codesigning.der
16, Whether or not the validity of end entity and CA certificates issued within the hierarchy rooted at this root may be verified using Certificate Revocation Lists (CRLs) and, if so, the URL(s) at which the CRL(s) may be obtained.
   http://ldap2.sheca.com/root/ucaglobalsub.crl
17, the URL for the associated OCSP responder: http://ocsp3.sheca.com/Global/global.ocsp, http://ocsp3.sheca.com/Sheca/sheca.ocsp
18, The maximum time elapsing from the revocation of an end entity or CA certificate until CRLs and/or OCSP responders are updated to reflect that revocation.
   The maximum time of CRLs update is 12 hours and the OCSP is available real-time.
19, The published document(s) describing how certificates are issued within the hierarchy rooted at this root, as well as other practices associated with the root CA and other CAs in the hierarchy, including in particular the Certification Practice Statement(s) (CPS) and related documents.
   CP: http://www.sheca.com/service/driver//UniTrustCPV1.1.1.pdf
   CPS: http://www.sheca.com/service/driver/SHECACPSV3.4.1.pdf
20, The published document(s) relating to independent audit(s) of the root CA and any CAs within the hierarchy rooted at the root.
   http://cert.webtrust.org/ViewSeal?id=755

Comment 3

[John Cui]

Attachment: examples of certificates

Comment 4

[Kathleen Wilson]

Attachment: Initial Information Gathering Document

Comment 5

[Kathleen Wilson]

The attached document summarizes the information that has been gathered and
verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness.

Comment 6

[John Cui]

Hi,Kathleen,pls check the attached documents for the further information.
Thanks for your work:)

Comment 7

[John Cui]

Attachment: Futher information for the items highlighted in yellow

Comment 8

[John Cui]

Attachment: new version of the cps which have copying enabled

Comment 9

[John Cui]

Attachment: new version of the cp which have copying enabled

Comment 10

[Kathleen Wilson]

Attachment: Updated Information Gathering Document

Thank you for the information. I have attached an updated Information Gathering
Document. Please note the items that are highlighted in yellow to indicate
where further information or clarification is needed.

Comment 11

[John Cui]

Hi Kathleen,thanks for your good work with our application. I have attached the reply to the Information Gathering Document.Pls check it.

Comment 12

[John Cui]

Attachment: Futher information for the InfoGathering

Comment 13

[Kathleen Wilson]

Thank you for the information.

I was able to access https://eds.myliving.cn/ with OCSP enforced.

For some reason I'm not able to connect to https://www.sheca.com or http://www.sheca.com at this time. I'll have to try again later.

In regards to Organization Identity...
> Reference to the provisions of CPS4.1.1.2, we usually verify the 
> organization identity follow the following steps:
> Firstly, applicants fill out an application form and bring relevant 
> original and copies evidence of their organizations to SHECA; 
> secondly, SHECA check the identity of the applicant face to face; 
> thirdly, SHECA compare the original and copies to confirm the authenticity;
> fourthly, if the material has no problem, SHECA will issue certificates for
> subscriber and keep a copy of materials of organization’s identity.

How does SHECA confirm the authenticity of the "relevant original and copies evidence of their organizations" that the applicant brings?

Comment 14

[John Cui]

We compare the original and copy to confirm the authenticity of the "relevant original and copies evidence of their organizations" that the applicant brings. For example, business license is necessary when organizations apply some certificate, the applicant is asked to bring the original business license and a copy stamped with company seal, SHECA would confirm the authenticity of the original one firstly, and then compare the difference between the original and the copy, and last SHECA would file the copy one.

Comment 15

[Kathleen Wilson]

> SHECA would confirm the authenticity of the original one firstly

What are the basic steps that SHECA takes to confirm the authenticity of the original?

> Test websites

Both websites are working for me now.

> New question

My notes say that SHECA is a commercial company, but perhaps my notes are not entirely complete. Is SHECA owned by the Shanghai municipal government?

Comment 16

[John Cui]

The originals are issued by government agencies, which is authoritative with the obvious identity.Generally, we think that the originals submitted by the applicant are reliable.If an original one is suspected in review, we will confirm the authenticity of the original by inquiring the public database of the government to obtain the relevant information, such as the Companies Registry's database of Shanghai administration of industry and commerce.

SHECA is a commercial company entirely and not owned by any government at all. Firstly, SHECA is a registered commercial company by Chinese Company Law. Secondly, all of our four shareholders are registered commercial companies. And thirdly, in china only a legally registered commercial company is allowed to operate CA business under the Chinese Electronic Signature Law.

Comment 17

[Kathleen Wilson]

Thank you for the clarifications.

In regards to the originals that are issued by government agencies, I don't understand how SHECA can confirm that they are authentic without comparing the documents with the information in the public database. Why not always check the information against the public database?

Comment 18

[John Cui]

thanks for your work.
Firstly, checking each business license document with the public database is very time consuming and unnecessary.  The original business license document issued by the government agency is made of paper with specific texture and chopped by a specific stamp.  Our staff, who normally check a hundred of business license documents each month, can easily identify fake evidence documents.  If our staff has any doubt, he/she will consult with his/her supervisor and take necessary procedures (e.g., checking with the public database).

Comment 19

[John Cui]

We have completed the WebTrust Attestation of 2009/2010 and obtained an unqualified auditor report issued by PwC ，please check the the uploaded report.  The report is also accessible at the WebTrust website (i.e., https://cert.webtrust.org/ViewSeal?id=755).

Comment 20

[John Cui]

Attachment: Webtrust audit report by PwC

Comment 21

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 22

[Kathleen Wilson]

This request has been added to the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Now that you have a request in the Queue for Public Discussion, you are
directly impacted by the time it takes to work through the queue. The goal is
to have each discussion take about one week. However, that time varies
dramatically depending on the number of reviewers contributing to the
discussion, and the types of concerns that are raised. If no one reviews and
contributes to a discussion, then a request may sit in the discussion for
weeks. When there are not enough people contributing to the discussions ahead
of yours, then your request will sit in the queue longer.

How can you help reduce the time that your request sits in the queue?

You can help by reviewing and providing your feedback in the public discussions
of root inclusion requests, or by asking a knowledgeable colleague to do so.

Please see: https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

John, Please review the recent discussions at mozilla.dev.security.policy, and start monitoring this newsgroup so that you will see the sorts of questions and action items that will likely arise given the current information in the attached "Completed Information Gathering Document".

Comment 23

[CY Cheung]

I have reviewed information and have no adverse comment on it.

Comment 24

[wangjuan]

I have reviewed the related info, and no adverse comments

Comment 25

[John Cui]

In China, more and more people are now using Firefox as their default web browser.  I truly believe that having SHECA's root certificates added to Firefox will bring convenience ot the Chinese web users and promote the use of Firefox in mainland China.

Comment 26

[Kathleen Wilson]

I will post a comment here in this bug when this request approaches the top of the queue for public discussion. Then I will post another comment in this bug when I start the public discussion about this request.

https://wiki.mozilla.org/CA:How_to_apply#Timeline

Comment 27

[David E. Ross]

Will this request become another CNNIC CA?  When this reaches the discussion stage, how can we ensure robust, candid participation by potential users within China?

Comment 28

[Kathleen Wilson]

I had similar questions, so I asked our in-country representatives to look into this. They don't believe that approving/including SHECA's roots would invoke the same sort of reactions as including CNNIC's root because the public image/perception of the two companies is different.

This request will go through the standard public discussion phase. There are more people following the discussions now, and many of them have voiced their opinions about CNNIC. I think we'll have to wait and see what happens when I start the discussion for this request, but that will be a while...

Comment 29

[sjs]

If Moz is ever going to re-open the CNNIC review, it seems like it could make sense to do so as part of a combined examination of the "hostile jurisdiction compelled certificate creation attack" which will inevitably be a topic during the SHECA discussion period.  Kathleen, would you consider this?  It would allow you to cabin that debate to some extent from the rest of the approval questions, while also providing an opportunity for a more rigorous public examination of the issue that might better satisfy those that have objected to lower level of scrutiny the issue enjoyed in earlier approvals (myself included).

Comment 30

[Kathleen Wilson]

>> If Moz is ever going to re-open the CNNIC review

Investigation will be performed and action will be taken whenever factual evidence is provided that a CA has issued a certificate in a manner that does not meet the requirements of the Mozilla CA Certificate Policy.

>> do so as part of a combined examination of the 
>> "hostile jurisdiction compelled certificate creation attack" 

I expect that this will be discussed during the project to update the Mozilla CA Certificate Policy. I plan to start the project by posting in m.d.s.policy in September.

Comment 31

[Kathleen Wilson]

This request is near the top of the queue for public discussion:
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

Is the audit statement for 2011 available?

Is the information on the pending page current?
http://www.mozilla.org/projects/security/certs/pending/#SHECA

Comment 32

[John Cui]

Thanks for your job:)
The audit report for 2011 will be available in several days.
The informaotion on the pending page is current.

Comment 33

[John Cui]

Attachment: Webtrust audit report by PwC 2011

Comment 34

[Kathleen Wilson]

Thanks. I just noticed that the webtrust site also has the 2011 audit statement.
https://cert.webtrust.org/ViewSeal?id=755

Comment 35

[Kathleen Wilson]

Attachment: Completed Information Gathering Document

Comment 36

[Kathleen Wilson]

This request is next in the queue for public discussion.
https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

I plan to start this discussion the week of July 11.

Comment 37

[Kathleen Wilson]

I have the following in my notes...

* Test Websites
** UCA Root: https://eds.myliving.cn/
** UCA Global Root: https://www.sheca.com


However, it appears that the SSL certs for both of these websites chain up to the UCA Root.

Please provide a URL to a website whose SSL cert chains up to the "UCA Global Root".

Comment 38

[Kathleen Wilson]

I had planned to start this discussion last week, because it is at the top of the queue: https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

However, as I was preparing to start the discussion I noticed the issue that I posted in Comment #37.  Since I am still waiting for the response, I will put this request on hold and start the next discussion in the queue. This request will remain at the top of the queue, but on hold until the item in Comment #37 is resolved.

Comment 39

[John Cui]

I'm very sorry for late response.
Here is the website whose SSL cert chains up to the "UCA Global Root":
https://www.imtrust.org
and the website,https://www.sheca.com, now is avaible for UCA Global Root.

Comment 40

[Kathleen Wilson]

Thanks for updating the website cert.

This request is at the top of the queue for discussion.

https://wiki.mozilla.org/CA:Schedule#Queue_for_Public_Discussion

I plan to start the discussion the first week of August. I will post an update in this bug when that happens.

Comment 41

[Kathleen Wilson]

I am now opening the first public discussion period for this request from SHECA to add the “UCA Root” and “UCA Global Root” root certificates. For the “UCA Root” the request is to enable all three trust bits. For the “UCA Global Root” the request is to enable the websites and code signing trust bits.

For a description of the public discussion phase, see https://wiki.mozilla.org/CA:How_to_apply#Public_discussion

Public discussion will be in the mozilla.dev.security.policy newsgroup and the corresponding [e-mail] mailing list.

http://www.mozilla.org/community/developer-forums.html
https://lists.mozilla.org/listinfo/dev-security-policy
news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “SHECA Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

A representative of SHECA must promptly respond directly in the discussion thread to all questions that are posted. 

Note: In past discussions regarding Chinese CAs, concerns have been raised about whether discussions in the mozilla.dev.security.policy forum are accessible to participants in China. Based on recent testing we believe that this forum is currently accessible to people in China. Testing found that Google Groups is blocked when https is used. However, the mozilla.dev.security.policy forum is in plain http, so it is accessible to participants in China. Anyone with information to the contrary should contact us immediately.

Comment 42

[David E. Ross]

It appears that Google Groups stopped updating from all NNTP servers on 1 August 2011.  This was noted by a member of the Big8 Management Board regarding discussions on Usenet servers in the news.groups.proposals newsgroup.  He communicated this via E-mail to the other members of the Big8 Management Board (which includes me).  I then started checking various newsgroups, both Usenet and news.mozilla.org and confirmed that there are no Google Groups messages after 1 August.

Comment 43

[Kathleen Wilson]

(In reply to David E. Ross from comment #42)
> It appears that Google Groups stopped updating from all NNTP servers on 1
> August 2011.  This was noted by a member of the Big8 Management Board
> regarding discussions on Usenet servers in the news.groups.proposals
> newsgroup.  He communicated this via E-mail to the other members of the Big8
> Management Board (which includes me).  I then started checking various
> newsgroups, both Usenet and news.mozilla.org and confirmed that there are no
> Google Groups messages after 1 August.


I filed a bug regarding the Google Groups issue:
https://bugzilla.mozilla.org/show_bug.cgi?id=677270

I will re-start this discussion after the issues with Google Groups has been resolved.

Kathleen

Comment 44

[Kathleen Wilson]

The problem has been fixed, and the messages have shown up in Google Groups.

https://bugzilla.mozilla.org/show_bug.cgi?id=677270#c3
"it was a general Google Groups issue that was resolved globally yesterday"

Since all of the messages are now showing in Google Groups, we can continue with the existing discussion thread. 

The discussion thread is called “SHECA Root Inclusion Request”

Please actively review, respond, and contribute to the discussion.

Comment 45

[chen jing]

I have reviewed information and no any adverse comments. By the way, as a  customer of Firefox from China, it's really good to know that SHECA would have its root certificates distributed with the Firefox web browser soon. Because as I know, SHECA is one of the best Certification Authorities in China, and this must would bring much convenience to us. :)

Comment 46

[Kathleen Wilson]

Please review the CA Communication that was recently sent, and is available here: https://wiki.mozilla.org/CA:Communications

Please add a comment to this bug to provide your response to the action items listed in the CA Communication. For more information about action items #1 and #3, please see items #6 and #7 of
https://wiki.mozilla.org/CA:Information_checklist#Verification_Policies_and_Practices

Comment 47

[Kathleen Wilson]

Closing this bug, because CA has not responded since 2011.

Comment 48

[John Cui]

Dear Kathleen,

We just noted that the bug was closed on 20 Aug 2013 with the reason of not
responding since late 2011.  We apologise for the delayed response.  In
fact, SHECA has been just completed our English CPS and CP (see attached
below).  Please let us know what else SHECA needs to do / provide to
proceed with the application.

Thanks.

Comment 49

[John Cui]

Pls check the URL for The latest WebTrust Audit Report 2013:  
https://cert.webtrust.org/ViewSeal?id=1530

Comment 50

[John Cui]

Attachment: Webtrust audit report2013.pdf

Comment 51

[John Cui]

Attachment: Webtrust audit report 2013 by PwC

Comment 52

[John Cui]

Attachment: Webtrust audit report 2012 By PwC

Comment 53

[Kathleen Wilson]

(In reply to John Cui from comment #48)
> SHECA has been just completed our English CPS and CP (see attached
> below). 

I do not see the English CP and CPS. Please provide the URL to the English version of the documents on SHECA's website. 


> Please let us know what else SHECA needs to do / provide to
> proceed with the application.


For each root certificate that you are requesting inclusion for, please provide the URL for downloading the root cert, and a URL to a website (may be a test website) whose SSL certificate chains up to the root cert.

Comment 54

[John Cui]

Attachment: CPS-SHECA （english version）.pdf

Comment 55

[John Cui]

Attachment: CP-SHECA （english version）.pdf

Comment 56

[John Cui]

Hi Kathleen,Sorry for the late reponse Because we are in holidays from 1Oct.to 7Otc.I have submitted the English CP and CPS,Pls check.

Comment 57

[John Cui]

Root Cert 1:UCA Global Root
URL for downloading the root cert：
http://www.sheca.com/certificate/download/UCAGlobal4096.spc
URL to a website whose SSL certificate chains up to the root cert: 
https://ziguan.xcsc.com/

Root Cert 2:UCA  Root
URL for downloading the root cert：
http://www.sheca.com/certificate/download/UCA2048.spc
URL to a website whose SSL certificate chains up to the root cert:
https://www.santak.com.cn/

Comment 58

[Kathleen Wilson]

Attachment: Updated CA Information Document

The attached document summarizes the information that has been verified.

The items highlighted in yellow indicate where further information or
clarification is needed. Please review the full document for accuracy and
completeness, and update this bug to provide or correct the information.

Comment 59

[liufangfang]

Hi Kathleen, sorry for late response. Because we are busy carrying out the WebTrust Audit ,and we will submit our updated cp and cps when we finish the audit.

Comment 60

[Kathleen Wilson]

No problem. Please make sure your current audit also includes the CA/Browser Forum's Baseline Requirements criteria.

Comment 61

[liufangfang]

Attachment: WebTrust report 2014.pdf

Comment 62

[liufangfang]

Attachment: WebTrust report - SSL- 2014.pdf

Comment 63

[liufangfang]

Dear Kathleen,
  We just completed the WebTrust Audit 2014,and I have attached the reports. Please let us know what else SHECA needs to do / provide to proceed with the application.

Comment 64

[Kathleen Wilson]

Attachment: Updated CA Information Document - June 2014

Please review the attached document. The items highlighted in yellow indicate where further information or clarification is needed.

Comment 65

[liufangfang]

Attachment: SHECA Responses to Jan 2013 Communication.pdf

Comment 66

[liufangfang]

Attachment: SHECA Responses to July 2013 Communication.pdf

Comment 67

[liufangfang]

Attachment: SHECA Responses to May 2014 Communication.pdf

Comment 68

[liufangfang]

Attachment: CP-SHECA EN-V1.1.2.pdf

Comment 69

[liufangfang]

Attachment: CPS-SHECA EN-V3.4.2.pdf

Comment 70

[liufangfang]

Attachment: UCA Root.rar

Comment 71

[liufangfang]

Attachment: UCA Global Root.rar

Comment 72

[liufangfang]

Attachment: 566310 CAInformation-finished.pdf

Comment 73

[liufangfang]

Hi Kathleen,

I just attached 5 documents you probably need to proceed the Root Certificate Program, please check them. If there is any other materials we should provide, you can feel free to contact us, and I'll very appreciate if you could tell me what we should do next. Thank you!

look forward to your reply!

Comment 74

[Kathleen Wilson]

Attachment: UCA-Root.cer

Comment 75

[Kathleen Wilson]

Attachment: UCA-Root.cert

Comment 76

[Kathleen Wilson]

Attachment: UCA-Global-Root.cert

Comment 77

[Kathleen Wilson]

Thank you for the updates. I have a few more questions/comments...

1) https://ef-g21.wwwtrust.org/ -- The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer)

2) Thank you for attaching the English translations of the most recent version of the CP and CPS. Please also update http://www.sheca.com/policy/ to have the corresponding version of the most recent documents.

3) Delegation of Domain / Email validation to third parties -- Please see the CA/Browser Forum’s Baseline Requirements sections 1.4.2.4 and 17.5,  and explain how SHECA meets these requirements for external RAs.

Comment 78

[liufangfang]

Attachment: SHECA G2-1.p7b

Comment 79

[liufangfang]

Attachment: SHECA Gb.p7b

Comment 80

[liufangfang]

Kathleen, about the questions you mentioned:

1)I have attached the certificate chains, please check the attachment 8472055 [details] and attachment 8472056 [details];

2)I have updated http://www.sheca.com/cps/default.aspx , you can check it;

3)SHECA's external RA is not charge of SSL certificates, so I think the CA/Browser Forum’s Baseline Requirements sections 1.4.2.4 and 17.5 is not application.

Comment 81

[Kathleen Wilson]

(In reply to liufangfang from comment #80)
> 1)I have attached the certificate chains, please check the attachment
> 8472055 [details] and attachment 8472056 [details];

Certificate authorities must advise their subscribers that all intermediate certificates should be installed in the servers containing the dependent subscriber certificates. 
Intermediate CA certificates are expected to be distributed to the certificate subjects (the holders of the private keys) together with the subjects' own certificates. Those subject parties (e.g. SSL servers) are then expected to send out the intermediate CA certificates together with their own certificates whenever they are asked to send out their certificates. That is required by SSL/TLS.
    
Also, please note that the SSL certificate for the test website for the UCA Root (https://www.santak.com.cn/ ) doesn't chain up to the UCA Root, so please provide a different test website.


> 
> 2)I have updated http://www.sheca.com/cps/default.aspx , you can check it;

What is the difference between these two pages? i.e. why do they have different CP/CPS links?
http://www.sheca.com/cps/default.aspx
and
http://www.sheca.com/policy/default.aspx



> 
> 3)SHECA's external RA is not charge of SSL certificates, so I think the
> CA/Browser Forum’s Baseline Requirements sections 1.4.2.4 and 17.5 is not
> application.

Where in the CP/CPS does it say that SHECA's external RA cannot issue SSL certificates?

Comment 82

[liufangfang]

Hi Kathleen，

  Thank you for you reply!

1) I'm sorry for the wrong link, here is a new link: https://mobile.haier.net/-custom/index_p.html                   ,and you can chain up to the UCA Root through it.

2)We use the first link(http://www.sheca.com/cps/default.aspx) in the past, and now we mainly use the second link( http://www.sheca.com/policy/default.aspx) to find the CP/CPS, and you can also see the link in the certificate issued by SHECA.

3)We didn't clarify the item in the CP/CPS, but in terms of internal operational control, SHECA didn't give external RA authority to issue SSL certificates. And we will update the latest version of CP/CPS to clarify the item ASAP.

Comment 83

[Kathleen Wilson]

(In reply to liufangfang from comment #82)
> 1) I'm sorry for the wrong link, here is a new link:
> https://mobile.haier.net/-custom/index_p.html                   
> and you can chain up to the UCA Root through it.

When I try to browse to this site in Firefox I get:
An error occurred during a connection to mobile.haier.net. Certificate contains unknown critical extension. (Error code: sec_error_unknown_critical_extension)

See https://wiki.mozilla.org/SecurityEngineering/x509Certs#Error_Codes_in_Firefox

> 
> 3)We didn't clarify the item in the CP/CPS, but in terms of internal
> operational control, SHECA didn't give external RA authority to issue SSL
> certificates. And we will update the latest version of CP/CPS to clarify the
> item ASAP.

OK. Please let me know when the CP/CPS is updated to say this.


(In reply to liufangfang from comment #67)
> Created attachment 8450733 [details]
> SHECA Responses to May 2014 Communication.pdf

https://ef-g21.wwwtrust.org/ -- web server doesn’t supply intermediate cert
so I get the following error when I try to browse to it in Firefox:
ef-g21.wwwtrust.org uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer)

I also tried browsing to https://ef-gb.wwwtrust.org/ but the server didn't respond.


Also...
We recently created a wiki page to explain Mozilla's expectations with regards to BR audits. Please review this and have your auditor review it too.
https://wiki.mozilla.org/CA:BaselineRequirements

Comment 84

[liufangfang]

Attachment: cp-SHECA EN-v1.1.2.1.pdf

Comment 85

[liufangfang]

Attachment: CPS-SHECA EN-v3.4.2.1.pdf

Comment 86

[liufangfang]

Attachment: screen shot .docx

Comment 87

[liufangfang]

Attachment: Certificate Extensions.docx

Comment 88

[liufangfang]

Hi Kathleen, 

  Thank you for your information!

1)There is not any critical extension in the certificate(see https://mobile.haier.net/-custom/index_p.html),and it's OK when I browse the website in Chrome, Safari.(I attached the screen shot, please check the attachment 8484788 [details]). Besides, I checked the <Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.1.7> and SHECA issued the certificate by conforming to the Baseline Requirements. And I attached the certificate extension, please see the attachment 8486306 [details]. So, I don't understand what's wrong with the situation. Please help us to check the problem. Thank you very much!

2)We have updated the CP/CPS, you can check the latest version in attachment 8484777 [details] and attachment 8484779 [details].
 
3)We deployed the web server again, so I think it's OK for you to browse the websites, please check them again. Thanks.

Comment 89

[li-mn]

(In reply to liufangfang from comment #88)
> Hi Kathleen, 
> 
>   Thank you for your information!
> 
> 1)There is not any critical extension in the certificate(see
> https://mobile.haier.net/-custom/index_p.html),and it's OK when I browse the
> website in Chrome, Safari.(I attached the screen shot, please check the
> attachment 8484788 [details]). Besides, I checked the <Baseline Requirements
> for the Issuance and Management of Publicly-Trusted Certificates, v.1.1.7>
> and SHECA issued the certificate by conforming to the Baseline Requirements.
> And I attached the certificate extension, please see the attachment 8486306 [details]
> [details]. So, I don't understand what's wrong with the situation. Please
> help us to check the problem. Thank you very much!

I get the same error - sec_error_unknown_critical_extension - when connecting to the site https://www.vesnatehno.com.
This error is only appear in Firefox since version 31.0 (with new Verification Library mozilla::pkix).
There are no such problems with Chrome and Safari.
The error disappears when we set a boolean pref "security.use_mozillapkix_verification" to "false".

Еру private key was generated by:
sudo openssl ecparam -out /etc/ssl/private/domains.key -name secp521r1 -genkey

The certificate request was generated by:
sudo openssl req -new -key /etc/ssl/private/domains.key -config /etc/ssl/ca/openssl.cnf -out /etc/ssl/ca/csr/domains.req

In openssl.cnf there was the following sections:

[ usr_cert ]
basicConstraints		= critical, CA:FALSE
keyUsage			= critical, digitalSignature, keyEncipherment
#nsCertType			= critical, server
#nsCertType			= critical, client
nsCaRevocationUrl		= http://site.ru/crl.pem
nsComment			= "OpenSSL Generated Certificate"

[ v3_req ]
basicConstraints		= critical, CA:FALSE
keyUsage			= critical, digitalSignature, keyEncipherment
subjectAltName			= critical, @alt_names

[ alt_names ]
DNS.1				= *.site1.ru
DNS.2				= *.site2.ru
DNS.3				= *.site3.ru
DNS.4				= *.site4.ru
DNS.5				= *.site5.ru
DNS.6				= *.site6.ru
DNS.7				= *.site7.travel
DNS.8				= *.site8.com

[ v3_ca ]
basicConstraints		= critical, CA:true
nsCertType			= critical, sslCA, emailCA
subjectKeyIdentifier		= hash
authorityKeyIdentifier		= keyid:always,issuer:always

[ crl_ext ]
authorityKeyIdentifier		= keyid:always

What critical extensions from listed above mozilla::pkix don't accepts?
And what extensions must be critical?

Thank you in advance.

Comment 90

[Kathleen Wilson]

>> https://mobile.haier.net/-custom/index_p.html
Now I get: 
An error occurred during a connection to mobile.haier.net. security library: improperly formatted DER-encoded message. (Error code: sec_error_bad_der) 


>> https://www.vesnatehno.com/
Please see: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes

Comment 91

[Kathleen Wilson]

Attachment: Updated CA Information Document

Updated CA Information Document showing current status of the verification of CA information. The items in yellow show where clarification is still needed.

Comment 92

[liufangfang]

Attachment: response to Updated CA Information Document.pdf

Comment 93

[liufangfang]

Hi Kathleen,

  I just attached "response to Update CA Information Document", please check the attachment 8495726 [details]. In the document, We clarified the items in yellow. 
 
  If there is any questions, please fell free to contact us. I really appreciate if you could tell me what should  I do next ASAP. Thank you!

Comment 94

[Kathleen Wilson]

1) Test website: https://bossvpn.jx.chinamobile.com
When I browse to the test website using Firefox, I get the error:
bossvpn.jx.chinamobile.com uses an invalid security certificate. The certificate is not trusted because no issuer chain was provided. (Error code: sec_error_unknown_issuer)

Please test using the Firefox browser, as described in #11 of 
https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate


2) https://wiki.mozilla.org/CA:BaselineRequirements 
> 1. The Root Certificate is issued at 2008, however BR Appendix B just specifies the 
> requirements for Certificate extensions for certificate generated after the effective date. 
> Would this impact the root inclusive?

I think that's OK, since the root was created before the BR Effective date.

> 2. For intermediate Certificate, we suggests the following actions to be taken, 
> please feel free to add your comments.
> We would like to re-generate the intermediate certificate conforming to BR, RFC 5280 and 
> Mozilla Inclusive Policy, with witness of the audit.

OK.

> If you’re OK with the renewal, 
> which kind do you think is better:
> 1) SHECA will issue a new intermediate certificate with a new key-pair;
> 2) SHECA will re-sign a new intermediate certificate with the same key-pair;

I don't know. You can ask in the mozilla.dev.security.policy forum, or ask a developer and/or auditor.

> After we re-generate the intermediate, we would send the new certificate chain, and update 
> the CP/CPS accordingly;
> If necessary, our auditor would send a separate email to give evidence of their witness 
> of the re-generation conforming to BR, RFC 5280 and Mozilla Inclusive Policy as your requirements.

OK


3) https://ef-g21.wwwtrust.org/ 
I tried again, and I am not able to browse to this site in Firefox. Are you able to browse to this site in Firefox?

Comment 95

[liufangfang]

Hi Kathleen,
  We browsed to the 3 websites using firefox: https://bossvpn.jx.chinamobile.com/
, https://mobile.haier.net/-custom/index_p.html
, https://ef-g21.wwwtrust.org
, and they’re all OK. So, I wonder if we could proceed to the next step to include the root certificates in Mozilla?

Comment 96

[Kathleen Wilson]

(In reply to liufangfang from comment #95)
> Hi Kathleen,
>   We browsed to the 3 websites using firefox:
> https://bossvpn.jx.chinamobile.com/

This website does not serve up the intermediate cert with the SSL cert, so I get the Untrusted Connection error,  (Error code: sec_error_unknown_issuer)

Item #11 of https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate
"Intermediate CA certificates are expected to be distributed to the certificate subjects (the holders of the private keys) together with the subjects' own certificates. Those subject parties (e.g. SSL servers) are then expected to send out the intermediate CA certificates together with their own certificates whenever they are asked to send out their certificates. That is required by SSL/TLS.
Certificate authorities MUST advise their subscribers that all intermediate certificates should be installed in the servers containing the dependent subscriber certificates.



> , https://mobile.haier.net/-custom/index_p.html

OK

> , https://ef-g21.wwwtrust.org

Doesn't respond.

Comment 97

[Kathleen Wilson]

Attachment: 566310-CAInformation.pdf

I have entered the information for this request into SalesForce, so please review the attached document for accuracy and completeness. 

Please also search through the attached document for "NEED" to find the things that still need to be completed, fixed, or clarified.

Comment 98

[liufangfang]

Attachment: the screenshot -20150213.docx

Comment 99

[liufangfang]

(In reply to Kathleen Wilson from comment #96)
> (In reply to liufangfang from comment #95)
> > Hi Kathleen,
> >   We browsed to the 3 websites using firefox:
> > https://bossvpn.jx.chinamobile.com/
> 
> This website does not serve up the intermediate cert with the SSL cert, so I
> get the Untrusted Connection error,  (Error code: sec_error_unknown_issuer)
> 

We browsed the website using firefox, and it's OK, and I will show you the screenshot in attachment 8563838 [details], please check it.

> > , https://ef-g21.wwwtrust.org
> 
> Doesn't respond.

We browsed the website using firefox, and it's OK, and I will show you the screenshot in attachment 8563838 [details], please check it.

Comment 100

[Kathleen Wilson]

(In reply to liufangfang from comment #99)
> (In reply to Kathleen Wilson from comment #96)
> > (In reply to liufangfang from comment #95)
> > > Hi Kathleen,
> > >   We browsed to the 3 websites using firefox:
> > > https://bossvpn.jx.chinamobile.com/
> > 
> > This website does not serve up the intermediate cert with the SSL cert, so I
> > get the Untrusted Connection error,  (Error code: sec_error_unknown_issuer)
> > 
> 
> We browsed the website using firefox, and it's OK, and I will show you the
> screenshot in attachment 8563838 [details], please check it.

It works for you, because you already happen to have that intermediate cert cached -- one of the other sites you browsed to must have correctly served up the intermediate cert. Firefox caches the certs it encounters. 

However, the webserver for https://bossvpn.jx.chinamobile.com/ is still not properly set up to serve up the intermediate cert with the SSL cert. 

See item 11 of https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate
"Make sure you test it yourself in Firefox first, by doing the following:
- Restore the default certificate settings as described..."

When you start with a fresh Firefox profile, you will get this error:
bossvpn.jx.chinamobile.com uses an invalid security certificate. 
The certificate is not trusted because no issuer chain was provided. 
(Error code: sec_error_unknown_issuer)


> 
> > > , https://ef-g21.wwwtrust.org
> > 
> > Doesn't respond.
> 
> We browsed the website using firefox, and it's OK, and I will show you the
> screenshot in attachment 8563838 [details], please check it.

I can now browse to the site within Firefox, but it is a mixed-content site.
https://support.mozilla.org/en-US/kb/how-do-i-tell-if-my-connection-is-secure?as=u&utm_source=inproduct#w_gray-warning-triangle



Please also respond to Comment #97 and the corresponding attachment.

Comment 101

[Kathleen Wilson]

https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/771PAebFAQAJ
"" More SHA-1 certs
These are all <issued> in the last week ...
Sub-CA under SHECA (which has applied to be in the Mozilla program)
https://crt.sh/?id=12367776&opt=cablint
""

Comment 102

[xiongyuanyuan]

Hi Kathleen,

This is Ruby Xiong from SHECA.From now on I will take over the work of the application for root inclusion of SHECA. Thank you!

Comment 103

[Kathleen Wilson]

Hi Ruby, Please provide the information requested in the attachment of Comment #97.

Comment 104

[xiongyuanyuan]

(In reply to Kathleen Wilson from comment #103)
> Hi Ruby, Please provide the information requested in the attachment of
> Comment #97.

Hi Kathleen, one of our root certificates(UCA Global Root) is being reissued lately, what else do we need to provide to you apart from those of comment#97?

Comment 105

[Kathleen Wilson]

(In reply to xiongyuanyuan from comment #104)
> (In reply to Kathleen Wilson from comment #103)
> > Hi Ruby, Please provide the information requested in the attachment of
> > Comment #97.
> 
> Hi Kathleen, one of our root certificates(UCA Global Root) is being reissued
> lately, what else do we need to provide to you apart from those of
> comment#97?


For each new root certificate please provide the information listed here:
https://wiki.mozilla.org/CA:Information_checklist#Technical_information_about_each_root_certificate