Based on the Chromium Development Calendar, this change should be visible in the Chrome Dev channel in the coming weeks, the Chrome Beta channel around late July 2017, and will be released to Stable around mid September 2017.
Certificates issued before this date may continue to be trusted, for a time, if they comply with the Certificate Transparency in Chrome policy or are issued to a limited set of domains known to be customers of WoSign and StartCom.
而因為安全考量，會有某些 certificate 是沒救的情況：(就上面的描述，看起來是指不在白名單內又沒標 CT flag 的)
Due to a number of technical limitations and concerns, Google Chrome is unable to trust all pre-existing certificates while ensuring our users are sufficiently protected from further misissuance.
1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN
4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
5) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
6) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL
首先是認定這一連串的事件是惡意行為：
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].
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.
然後將之前簽出來的 SHA-1 憑證列入 OneCRL：
2) Add the previously identified backdated SHA-1 certs chaining up to the Affected Roots to OneCRL.
另外一個非常大的事情是，Mozilla 將永久不信任安永香港的稽核報告：
3) No longer accept audits carried out by Ernst & Young Hong Kong.
Gervase Markham 做了補充「永久」的部份：
To be clear, this is a permanent ban, applicable worldwide, but only to the Hong Kong branch of E&Y. (If further issues are found with E&Y audits elsewhere, then we might consider something with wider scope.)
WoSign 在 iOS 產品線中是靠 StartCom 與 Comodo 的交叉簽章，所以如果 Apple 只想擋 WoSign 憑證的話，必須以阻擋 Intermediate CA 的方式避開：
Although no WoSign root is in the list of Apple trusted roots, this intermediate CA used cross-signed certificate relationships with StartCom and Comodo to establish trust on Apple products.
不過為了降低對 user 的影響，這次的阻擋會有例外。當 CT log server 在 2016-09-19 前收到的 SSL certificate 還是會信任 (要注意的重點是，這邊的日期不是簽發，是送到 CT log server 上)：
To avoid disruption to existing WoSign certificate holders and to allow their transition to trusted roots, Apple products will trust individual existing certificates issued from this intermediate CA and published to public Certificate Transparency log servers by 2016-09-19.
接下來會開始更深入的調查 WoSign 與 StartCom：
As the investigation progresses, we will take further action on WoSign/StartCom trust anchors in Apple products as needed to protect users.
Following the publication of the recent investigative report, representatives of Qihoo 360 and StartCom have requested a face-to-face meeting with Mozilla. We have accepted, and that meeting will take place next Tuesday in London.
從頭說明，事情發生於八月底的時候 Google 通知了 Mozilla 一連串 WoSign 出包卻沒有主動通報的事件，當時知道的大約有三或四件。而在 mozilla.dev.security.policy 不斷的討論的情況下，由於關注度變得超高，在搜尋大量的資料下發現更多問題，到現在 Mozilla 的 wiki 上已經列出了 13 個。
[...], Mozilla’s program requirements say that a change of CA ownership must be disclosed. In this case, that was not done - and in fact, the change was directly denied a few months after it happened.
More recently, even after the evidence of total control was public, WoSign referred to their interest in StartCom in a press release as “an equity investment”, and maintain that the two businesses continue to be separate even today. They say “the original system ... of StartCom remains unchanged”.
However, there is technical evidence that around a month and a half after the acquisition, StartCom issuances switched to using WoSign’s infrastructure - either the same instance of it, or their own instance.
而 Mozilla 要求 WoSign 提供他們產生 serial number 的程式碼時：(在 WoSign 簽出重複的 serial number 問題時得到的)
Mozilla asked WoSign how they generated their serial numbers, and was told that they used the Java package java.crypto.SecureRandom. They supplied the following code snippet:
[...]
However, as can be seen from this simple test harness, this code snippet does not produce serial numbers matching WoSign’s idiosyncratic pattern.
We believe that, taken together, all this shows that StartCom’s certificates are now being issued using either WoSign’s existing infrastructure or a clone of it, and that WoSign’s operational control of StartCom began straight after the November 1st 2015 sale date. This evidence should be compared against WoSign’s recent assertion that “Even now, it still independent in the system, in the validation team and management team, we share the CRL/OCSP distribution resource only.”
This became clear in February of 2016, where a payment processor called WorldPay applied to the CAB Forum for an exception so they could acquire 8 SHA-1 certificates to keep SSL working for their legacy payment terminals. Their CA was unable to help them because of the ban in the CAB Forum Baseline Requirements, and to issue in violation of the ban would lead to a “qualified” (not clean) audit, which might lead to browsers no longer accepting their audit as valid to keep them trusted.
而在亞利桑那的 face-to-face meeting 中剛好就討論了這點，允許 Symantec 簽發，而要提出來的是，WoSign 的 Richard Wang 也在場：
This issue was discussed at length in the CAB Forum face-to-face meeting from 16th-18th February 2016 in Scottsdale, Arizona (where Richard Wang of WoSign was present). Mozilla then had a public discussion about it in our policy forum starting on 23rd of February. In the end, the browsers reluctantly agreed to let Symantec issue these certificates for Worldpay - or rather, they agreed to accept that Symantec’s next audit would be qualified in this way.
所以 Mozilla 再次強調，當下大家的結論是特別許可，簽發被禁止的 SHA-1 certificate 是很嚴重違反規定的事情：
Even at this point, in February 2016, it was (or should have been) clear to all CAs, including WoSign, that issuing SHA-1 certificates in violation of the ban was a Very Big Deal, and that permission had to be sought from the browsers in order for the CA not to face difficulty.
GeoTrust issues a SHA-1 certificate for *.tyro.com from their Equifax root, valid until May 6th 2013.
Apr 6th 2013
A month before their old cert expires, GeoTrust issues a replacement SHA-1 certificate for *.tyro.com from a GeoTrust root, valid until June 7th 2016. A simple roll-over replacement.
Jan 1st 2016
SHA-1 issuance ban comes into effect.
May 24th 2016
A month before their old cert expires, GeoTrust issues a SHA-256 certificate for *.tyro.com from a GeoTrust root, valid until June 23rd 2019.
But the strong evidence is that this SHA-256 certificate did not meet Tyro’s needs. We can see a SHA-1 certificate for *.tyro.com which was logged in CT on June 8th 2016, a day after their previous SHA-1 certificate expired. This certificate is not issued by GeoTrust (who still provide the cert for their main website) or Comodo, tyro.com’s usual providers, but by StartCom. And the notBefore date is that magic date of 20th December, 2015 - a date on which, as noted above, StartSSL.com was closed for upgrading, and on which we have seen many Macau certificates issued by WoSign, which we believe are back-dated.
StartCom are using WoSign’s infrastructure (the same or a clone);
Certificates on this infrastructure with a notBefore of 2015-12-20 (China time) are indeed back-dated - this further confirms our suspicions about the Macau certificates we saw issued by WoSign; and
StartCom’s hierarchy has been directed by management to mis-issue “WoSign-style”.
This last point is important; the practices at WoSign are now being seen at StartCom. Therefore, we conclude that all of ownership, infrastructure and control are sufficiently common between the two companies that it would therefore be reasonable for any action Mozilla chooses to take against WoSign to also be taken against StartCom and vice versa.
On or around April 23rd, 2015, WoSign's certificate issuance system for their free certificates allowed the applicant to choose any port for validation. Once validation had been completed, WoSign would issue certificates for that domain. A researcher was able to obtain a certificate for a university by opening a high-numbered port (>50,000) and getting WoSign to use that port for validation of control.
設計不良造成的資安事件總是會發生。重點在於 Google 知道，但 Mozilla 完全不知道：(我講得很保守是因為這個句子在 thread 後面被澄清解釋的更慘，參考後文)
This problem was reported to Google, and thence to WoSign and resolved. Mozilla only became aware of it recently.
更嚴重的是，這次的事件在 WoSign 的稽核上沒有出現：
* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].
The reporter proved the problem in two ways. They accidentally discovered it when trying to get a certificate for med.ucf.edu and mistakenly also applied for www.ucf.edu, which was approved. They then confirmed the problem by using their control of theiraccount.github.com/theiraccount.github.io to get a cert for github.com, github.io, and www.github.io.
嗯，也沒通報：
* This misissuance incident was not reported to Mozilla by WoSign as it should have been (see above).
嗯，稽核也沒出來：
* This misissuance incident did not turn up on WoSign's subsequent BR audit[1].
They reported this to WoSign, giving only the Github certificate as an example. That cert was revoked and the vulnerability was fixed. However recently, they got in touch with Google to note that the ucf.edu cert still had not been revoked almost a year later.
Using the value "1" led to a certificate which had a notBefore date (usage start date) of 20th December 2015, and which was signed using the SHA-1 checksum algorithm.
嗯，然後否認造假：
* WoSign deny that their code backdated the certificates in order to avoid browser-based restrictions - they say "this date is the day we stop to use this code"[4]. If that is true, it is not clear to us how StartCom came to deploy WoSign code that WoSign itself had abandoned.
嗯，然後還是沒有回報給 Mozilla：
* This misissuance incident was not reported to Mozilla by WoSign as it should have been.
稽核報告應該是因為這太新，還沒開始做？
另外在 thread 討論時，Google 的 Ryan Sleevi 澄清的更慘：
Clarification: In none of these incidents was Google notified proactively by WoSign. Instead, Google received communication from internal or external researchers regarding these issues, either prior to resolution or much later after the fact, and subsequently contacted WoSign regarding them.
It was only when Google found out recently that other programs were NOT notified, proactively, as had been expected, that Google shared the details it was aware of regarding various CA incidents, including those of WoSign, mentioned in this thread.
也就是說，是 Google 主動發現這些問題，並且通報 WoSign。後來過了許久發現 WoSign 沒有照規定通報其他 CA Root 管理單位 (以這邊來說是 Mozilla)，於是 Google 決定主動通報其他單位，然後大～爆～炸～
