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 . 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
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
2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited,
Certificate Serial Number: 5e68d61171946350560068f33ec9c591
3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA
Certificate Serial Number: 6b25da8a889d7cbc0f05b3b17a614544
4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 684a5870806bf08f02faf6dee8b09090
5) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate
Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 01
6) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate
Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 2d
7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd.,
Certificate Serial Number: 3b
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
mozilla.dev.security.policy, 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 .
-- 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
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 mozilla.dev.security.policy 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
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.
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