前幾天社群蠻熱鬧在討論綠界的 *.ecpay.com.tw 憑證被上游 Sectigo 給 revoke，而導致 login.ecpay.com.tw 無法連線的問題 (ba:d3:26:14:db:53:1b:56:49:8d:de:d5:0c:68:b9 這張，另外參考點了 OCSP 檢查的 https://crt.sh/?id=3608838685&opt=ocsp 結果)，可以看 domain 知道這個網域比較偏使用者的用途 (而非 API 類)，會買 EV 主要就是要用在瀏覽器上，所以這邊主要就討論瀏覽器受到影響的部份...
因為 Sectigo 是透過 CRL 與 OCSP 兩個機制把 revoke 資訊送出來，所以各家瀏覽器的處理方式會不太一樣...
首先是市占率最高的 Chrome，因為有自家的機制在處理 revoke，不走 CRL 或是 OCSP，所以大多數的使用者應該都沒有受到影響 (不確定...)，但 Firefox 與 Safari 都吃 OCSP，所以都會炸掉。
這次有看到兩個社群有一些討論，一個是「https://www.facebook.com/groups/rayforum/posts/4417812681632189/」，另外一個是「https://www.facebook.com/groups/616369245163622/posts/2497356027064925/」這邊。
Vincent Liang 有貼了 Sectigo 送 revoke 的原因，在 Mozilla 的 Bugzilla 上面有 Sectigo 的主動通報：「Sectigo: Subject field with unvalidated information included in certificates」，看起來是因為在內部 code review 的時候發現 postOfficeBox (以台灣來說就是郵遞區號郵政信箱) 這個欄位的問題：
Though the postOfficeBox field is permissible for inclusion in OV certificates, any field containing unvalidated information is not permissible. Furthermore, the EV Guidelines prohibit this field at all for EV certificates.
也就是說，在 OV 憑證內可以列入 postOfficeBox，但需要確認後才能列進去；而 EV 憑證則是不允許列 postOfficeBox 的；因為這兩個原因，這些憑證都要 revoke，另外也因為 Baseline Requirements 與 EV SSL Certificate Gudidelines 的要求而需要主動通報。
Sectigo 有列出 453 個受到影響的憑證，不過發文者 Lorex L. Yang 有注意到綠界的這個憑證沒有被列在這 453 個受到影響的憑證內，但是後來也有被 revoke 掉...
所以現在問題就來了，會不會 Sectigo 根本沒通知綠界要換憑證？另外 Sectigo 的通報內容不實也是一個大問題，因為沒有人在 Bugzilla 上提到，所以我就在上面回個 comment 把這個議題拋出來，讓 Mozilla 的人知道後繼續查下去...
當然綠界花了十八個小時解決也是個問題，不過那個就不是我們能管到的了...