Thanks again to all of you who have put in so much time and effort to determine 
what happened with WoSign and StartCom and discuss what to do about it.

Based on the information that I have seen regarding WoSign, I believe that 
WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL 
certs, when they knew full well that was no longer allowed. I also believe that 
the deception continued even after Mozilla directly asked WoSign about this. 
WoSign has lost my confidence in their ability and intention to follow 
Mozilla's policies. Therefore, I think we should respond similarly to WoSign as 
we did to CNNIC [1][2]. Unfortunately, the number of certificates and the 
timescales involved are such that we prefer not to create a list of the domains 
for which previously-issued certs that chain up to the Affected Roots may 
continue to be trusted, so our approach will be a little different, as Gerv 
previously described[3].

Within this message, the term “Affected Roots” applies to the following 7 root 

1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 50706bcdd813fc1b4e3b3372d211488d
SHA-1 Fingerprint   
SHA-256 Fingerprint   

2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, 
Certificate Serial Number: 5e68d61171946350560068f33ec9c591
SHA-1 Fingerprint   
SHA-256 Fingerprint   

3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA 
Limited, C=CN
Certificate Serial Number: 6b25da8a889d7cbc0f05b3b17a614544
SHA-1 Fingerprint   
SHA-256 Fingerprint   

4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 684a5870806bf08f02faf6dee8b09090
SHA-1 Fingerprint   
SHA-256 Fingerprint   

5) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate 
Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 01
SHA-1 Fingerprint   
SHA-256 Fingerprint   

6) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate 
Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 2d
SHA-1 Fingerprint   
SHA-256 Fingerprint   

7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., 
Certificate Serial Number: 3b
SHA-1 Fingerprint   
SHA-256 Fingerprint   

I intend to move forward as follows, unless further information or input causes 
me to rethink this plan. Therefore, I will continue to appreciate your input, 
and this discussion is still open.

Mozilla will perform the following 4 actions. I have filed Bugzilla Bug 
#1309707 to track the engineering work for this. Please keep discussion here in, and not in the bug.

1) Distrust certificates chaining up to Affected Roots with a notBefore date 
after October 21, 2016. If additional back-dating is discovered (by any means) 
to circumvent this control, then Mozilla will immediately and permanently 
revoke trust in the Affected Roots.
-- This change will go into the Firefox 51 release train [4]. 
-- The code will use the subject key id (hash of public key) to identify the 
Affected Roots, so that the control will also apply to cross-certs of the 
Affected Roots.
2) Add the previously identified backdated SHA-1 certs chaining up to the 
Affected Roots to OneCRL.
3) No longer accept audits carried out by Ernst & Young Hong Kong.
4) Remove the Affected Roots from NSS after the SSL certificates issued before 
October 1, 2016, have expired or have been replaced.

WoSign may apply for inclusion of new (replacement) root certificates following 
Mozilla's normal root inclusion/change process (minus waiting in the queue for 
the discussion), after they have completed all of the following action items, 
and no earlier than June 1, 2017. If StartCom is able to provide proof enough 
to convince the Mozilla community in the forum that 
WoSign has no control (people or code) over StartCom, then StartCom may 
re-apply for inclusion earlier, as soon as the following action items are 

1. Provide a list of changes that the CA plans to implement to ensure that 
there are no future violations of Mozilla Policy and the Baseline Requirements.

2. Implement the changes, and update their CP/CPS to fully document their 
improved processes. The CP/CPS must explicitly state that it is prohibited to 
backdate the notBefore of certificates by more than one day.

3. Provide a public-facing attestation from a Licensed WebTrust Practitioner[5] 
other than EY Hong Kong that the changes have been made.  This audit may be 
part of an annual WebTrust CA audit. 

4. Provide auditor attestation that a full performance audit has been performed 
confirming compliance with the CA/Browser Forum's Baseline Requirements[6].  
This audit may be part of an annual WebTrust BR audit. It must include a full 
security audit of the CA’s issuing infrastructure.

5. 100% embedded CT for all issued certificates, with embedded SCTs from at 
least one Google and one non-Google log not controlled by the CA.

* The new (replacement) root certificates may be cross-signed by the Affected 
Roots. However, the Affected Roots may *not* be cross-signed by the new 
(replacement) root certificates, because that would bring the concerns about 
the Affected Roots into the scope of the new roots. 
* Mozilla's root inclusion/change process includes checking that certificates 
in the CA hierarchy comply with the CA/Browser Forum's Baseline Requirements.

Please let me know if I’ve missed anything.



dev-security-policy mailing list

Reply via email to