博士

やっほー、ロボ子！今日もITニュースの時間じゃぞ！

ロボ子

こんにちは、博士。今日のニュースは何でしょうか？

博士

今日はSSL.comの脆弱性についてじゃ。ちょっと深刻な話みたいじゃぞ。

ロボ子

SSL.comですか。聞いたことがあります。どんな脆弱性が見つかったんですか？

博士

Domain Control Validation (DCV) プロセスに脆弱性があって、「Email to DNS TXT Contact」方式に影響があったらしいのじゃ。

ロボ子

DCVの脆弱性ですか。具体的にはどういうことですか？

博士

SSL.comのシステムが、証明書を要求したドメインじゃなくて、承認者のメールアドレスのドメインの制御を誤って検証してたみたいじゃ。

ロボ子

それは大変ですね！つまり、本来とは違うドメインで証明書が発行されてしまう可能性があるということですか？

博士

そういうことじゃ。実際、そのせいで誤発行された証明書が10個も見つかって、失効されたらしいぞ。

ロボ子

それは大きな問題ですね。SSL.comは何か対策を取ったんですか？

博士

もちろんじゃ。脆弱なDCV方式は無効化して、調査を開始したみたいじゃ。でも、Chrome Root Programからセキュリティ制御違反の報告パターンを指摘されてるみたいじゃぞ。

ロボ子

Chrome Root Programからの指摘ですか。それはかなり厳しいですね。

博士

CAAレコード処理とか、空のCAAセットに基づくワイルドカード発行とか、以前に侵害されたキーを使った証明書発行とか、色々問題があったみたいじゃ。

ロボ子

それは運用体制に根本的な問題があるのかもしれませんね。

博士

Chrome Root Programは、SSL.comの運用安定性、ポリシー遵守、内部統制の有効性に懸念を表明してるみたいじゃ。メールベースのDCVの永久的な廃止とか、変更管理の改善とか、内部監査の強化とか、色々質問してるみたいじゃぞ。

ロボ子

SSL.comがきちんと対応しないと、ブラウザから信頼されなくなる可能性もあるんですね。

博士

その通りじゃ。Google ChromeとかMozilla Firefoxみたいな主要なブラウザRootプログラムは、厳しいポリシーに基づいてCAを信頼してるからな。ポリシー違反とか運用上の懸念があると、不信されて削除されることもあるんじゃ。

ロボ子

過去にもそういう事例があったんですか？

博士

DigiNotarとかTrustCorとかSymantecとか、色々あったみたいじゃぞ。SSL.comは、ブラウザからの懸念に対して、包括的かつ持続的な改善を示す必要があるんじゃ。

ロボ子

ドメイン所有者や証明書マネージャーとしては、どういう対策を取るべきでしょうか？

博士

ドメインのセキュリティ体制を積極的に監視することが重要じゃな。CAA DNSレコードの実装、Certificate Transparency (CT) ログの監視、DCVメールアカウントの監査、CAの記録に関する情報の収集を推奨するぞ。

ロボ子

なるほど。自分たちのドメインは自分たちで守る、ということですね。

博士

そういうことじゃ！しかし、SSL.comも大変じゃな。信頼を回復するのは簡単じゃないからの。

ロボ子

本当にそうですね。今回の件で、改めてセキュリティの重要性を認識しました。

博士

まあ、ロボ子も私も、うっかりミスには気をつけようぞ！…って、ロボットにうっかりミスはないか！

ロボ子

博士、私はまだ学習途上なので、うっかりミスをする可能性も…ゼロではない、かもしれません。