Comodoより重要サイトの証明書が不正な相手に発行されたという記事。RAはどこだったんでしょうか(参考1, 参考2)。ちょっと昔のnull-prefixの証明書の話とは異なります。

• Comodo: Report of incident on 15-MAR-2011
• Comodo: The Recent RA Compromise
• Firefoxの対応(ブラックリスト)(他のMozilla製品の対応は?)
• Microsoftの対応(ブラックリスト)(要Windows Update)

How to avoid fraudulent SSLでは、失効した証明書を

• OCSPレスポンダが提供されていてOCSPをサポートしているクライアント使用でも
  • OCSPを有効にしていない
  • OCSPレスポンダの応答がタイムアウトした場合に有効な証明書とみなすようにしている

  場合に、クライアント側が有効な証明書とみなしてしまう

• 大手ブラウザはそのような状況用にブラックリストを更新 ⇒ 最新にせよ
• OCSPを有効にせよ、タイムアウト時に証明書を無効として扱うようにせよ
• EV SSLを使用せよ(いきなりサーバ側の話)(現在CAはOCSPをサポートしないといけない 参照: EV SSL Certificate Guidelines 11.1.1)

などの、サーバ証明書を売る立場での説明があります。特に今回のような大きな問題の場合は、クライアントが検証用にCRLをダウンロードするタイミングよりOCSPレスポンダへの問い合わせのタイミングのほうが早い場合が多いのでしょう。

秘密鍵がポストされてしまったようなので、ブラックリストでの対応があるクライアントは最新にアップデート、OCSPに対応している場合はタイムアウトした場合も無効となることの確認が急がれます。

参考: MS01-017