Let's Encrypt 發現在檢查 CAA 的程式碼有問題，發了說明：「2020.02.29 CAA Rechecking Bug」，以及預定的處理方式：「Revoking certain certificates on March 4」。
問題是當一個 certificate request 包含了 N 個 domain 時，本來的 CAA 檢查應該要對這 N 個檢查，但程式寫成只會抓一個，然後檢查了 N 次：
The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.
2020/02/29 發現的，就程式碼的部屬時間，發現應該從去年 2019/07/25 開始就有這個 bug：
We confirmed the bug at 2020-02-29 03:08 UTC, and halted issuance at 03:10. We deployed a fix at 05:22 UTC and then re-enabled issuance.
Our preliminary investigation suggests the bug was introduced on 2019-07-25. We will conduct a more detailed investigation and provide a postmortem when it is complete.
然後決定要 revoke 這些可能會有問題的 SSL certificate，大約佔現有還有效的 SSL certificate 的 2.6%，大約三百萬筆：
Q: How many certificates are affected?
A: 2.6%. That is 3,048,289 currently-valid certificates are affected, out of ~116 million overall active Let’s Encrypt certificates. Of the affected certificates, about 1 million are duplicates of other affected certificates, in the sense of covering the same set of domain names.
在「Check whether a host's certificate needs replacement」這邊可以偵測線上使用的 SSL certificate 是否受到影響。
另外在「Download affected certificate serials for 2020.02.29 CAA Rechecking Incident」這邊可以抓到所有受到影響，預定要 revoke 的 SSL certificate 的序號。關於取得序號的方式，官方也有提供 CLI 的指令可以操作確認，對於有很多網域名稱需要確認的人可以用這組指令編寫程式判斷：
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d :
照目前的描述，如果申請時只有一個 domain 應該是不會中這個問題，再來是最壞的情況大概會維持三個月 (網站主人沒管他，等到時間到了自動 renew)。
