概要
- DigiCert は、Mozilla Bugzilla において、必須のアンダースコアプレフィックスを付けずに CNAME レコードのランダム値で一部のドメインを検証したことを報告した。これにより、同社の OEM 検証システムの一経路に影響が及んだ。インシデント報告によれば、この方式で 83,267 件の有効な TLS 証明書が発行されており、システムがアンダースコアの有無を適切に記録していなかったため、影響を受けたセットは過大計上されている可能性が高いと述べた。
- 失効問題は即座に生じた。CA/Browser Forum の TLS ベースライン要件は、誤発行された証明書について定められた期間内に失効することを要求しており、DigiCert の遅延失効インシデント報告では、影響を受けた 83,267 件の TLS 証明書を、当時のルールで要求される 24 時間ではなく、120 時間以内に失効させたとしている。
- この出来事は、単なる CA のコーディングエラーではなかった。証明書インベントリの加入者側の脆弱性、リセラーやエンタープライズアカウントを通じたコミュニケーションの限界、顧客による一時的差止命令紛争による法的圧力、そして多くの組織が依然として大規模に証明書を迅速に交換する自動化を欠いていた事実が明らかになった。
- 実質的な管理は分散していた。DigiCert は検証の実装、証明書の特定、顧客通知、失効の実行、インシデント報告を管理していた。ルートプログラムと CA/Browser Forum は信頼の期待とポリシー圧力を管理していたが、顧客の展開は管理していなかった。加入者は自らのインベントリ、自動化、変更ウィンドウ、サービス固有のロールアウトを管理していた。エンドユーザーはリスクをほとんど管理できなかった。
- 説明責任の教訓は、認証局は失効を稀な事務作業として扱うことはできず、加入者は公的に信頼された TLS 証明書を静的なインフラとして扱うことはできないということだ。Web PKI の安全モデルは、緊急事態が発生する前に迅速な交換が日常業務として退屈であることに依存している。
アンダースコアの欠落が世界的な継続性問題に
DigiCert のインシデントは、句読点の問題に矮小化すれば些細なものに見える。技術的な問題は、DNS CNAME ベースのドメイン制御検証パスにおいて、必須のアンダースコアプレフィックスが関与していた。しかし、その結果は単なるタイポの修正では済まなかった。DigiCert は、クラウドサービス、通信ネットワーク、医療環境、エンタープライズアプリケーション、顧客向けウェブサイトに展開された数万件の公的に信頼された証明書を特定し、失効させなければならなかった。
DigiCert の公的なインシデント記録（Mozilla Bugzilla bug 1910322）が事実の基盤である。DigiCert は、メソッド 7（DNS ベースの検証）の実装に問題がある可能性を示す証明書問題報告を受けたと報告した。複数の DNS 関連検証プロセスを説明し、コードレビューにより、CNAME レコードでホストとしてランダム値を使用する際にアンダースコアを先頭に付加せずに証明書が発行される可能性のあるパスが見つかったと述べた。同じバグの後続の投稿で、DigiCert のインシデント報告は、影響は同社の OEM 検証システムを利用する発行者に限定され、クラウドプロバイダー向けの大量発行エンジンである CertCentral と CIS の検証パスはドメインを正しく検証しており、影響を受けなかったとしている。
件数も公的なインシデント記録に基づいている。DigiCert は、この方式で 83,267 件の有効な証明書が発行され、修正前に CNAME ベースの DNS 検証を使用したとデータベースにリストされている有効な証明書をすべて失効させていると述べた。OEM システムの管理がアンダースコアの有無を適切に保存していなかったため、実際の影響セットを過大にカウントしている可能性が高いと説明した。この一文が説明責任の要である。システムはリスクのある母集団を特定できても、どの証明書が準拠していたのかを明確に証明できなかった。信頼システムにおいて、コンプライアンスに関する不確実性は失効義務になり得る。
アンダースコアのセキュリティ上の理由は、単なる見た目の問題ではない。CA/Browser Forum の検証メソッドは、加入者が制御する名前と、より大きなドメイン下で委任されたりユーザーが作成したりする可能性のある名前を区別する。Bugzilla での議論では、アンダースコアプレフィックス付きのラベルが、通常のホスト名や多くの委任サブドメインサービスが回避できる特別な検証名前空間を作成するのに役立つことが強調された。アンダースコアが欠落すると、ユーザーが管理していないドメイン下でサブドメインを作成できる場合に、不要な証明書発行を防ぐために用いられる前提を損なう可能性がある。
これが、このイベントが DNS 委任の権限に属する理由である。ドメイン検証は、DNS からの証拠を証明書発行の権限に変換する方法である。証拠が誤った場所から受け入れられたり、必要な境界マーカーが欠落している場合、CA はより弱い DNS 配置を制御の証明として扱う可能性がある。その後、証明書は依拠当事者に対して、ある名前に対するブラウザが信頼するシグナルを提供する。したがって、発行権限は DNS 委任を正しく解釈する権限と結びついている。
ルールはルールの役割を果たした：行動を強制した
CA/Browser Forum のTLS ベースライン要件は、インシデントの中心にある公的なルールセットである。これらは、公的に信頼される TLS サーバー証明書のドメイン検証方法と証明書失効義務を定義している。説明責任の構造を説明するために、すべての要件を引用する必要はない。証明書が誤発行されたか、検証がベースライン要件に準拠していなかった場合、CA は適用される期限内に失効させなければならない。ただし、ルール自体が別の道を許可している場合を除く。
DigiCert の遅延失効報告（Mozilla Bugzilla bug 1910805）は、コンプライアンス上の矛盾を明確に述べている。DigiCert は、24 時間以内にすべての証明書を失効させる作業を進めていたが、影響についてルートプログラムやコミュニティと協議した後、失効を延期し、影響を受けるすべての証明書を 120 時間以内に失効させることを決定したと述べた。その後のインシデント報告では、DigiCert が現在のベースライン要件で要求される 24 時間ではなく、5 日間で 83,267 件の証明書を失効させたと影響を要約している。
この告白は、2 つのインシデントを分ける点で重要である。Bug 1910322 はドメイン検証の非準拠に関するものだった。Bug 1910805 は遅延失効に関するものだった。1 つ目の問題は、証明書が非準拠と見なされるに至った経緯である。2 つ目の問題は、顧客が依然としてライブサービスでそれらの証明書に依存している中で、エコシステムがそれらの証明書を信頼から除外する義務にどのように対応したかである。
この区別は浅薄な議論を防ぐ。「DigiCert は単に即座に失効させてルールに従うべきだった」と言うことができる。それがクリーンなポリシーの立場である。「即座の失効は重要なサービスを混乱させたであろうから、遅延は現実的だった」と言うこともできる。それがオペレーショナルな立場である。このインシデントは、両者の間の居心地の悪いギャップを示している。公開信頼ルールは、依拠当事者を無効または誤発行された証明書から保護するように設計されている。現実世界の加入者は、証明書がメンテナンスウィンドウ、アプライアンス、ロードバランサー、組み込みシステム、変更承認に拘束される交換が困難な資産であるかのように運用していることが多い。
ルートプログラムは権限について慎重だった。Bugzilla のスレッドで、Chrome ルートプログラムの代表者は、CA/Browser Forum ベースライン要件に対する例外を認める権限はなく、これらの要件は 1 つのルートプログラムが所有するものではなく、合意主導であると述べた。Chrome ルートプログラムポリシーは、より広範なブラウザールートの文脈を提供している。つまり、CA はプログラムの期待、インシデント評価、継続的なコンプライアンスプレッシャーの下でルートストアに参加する。しかし、危機の際のルートプログラムの協議は、公的ルールの免除という魔法の杖ではない。
Mozilla のルートストアポリシーとCA インシデント対応ガイダンスも同様の機能を果たす。これらはインシデント報告と応答性を信頼ガバナンスの一部としている。これらは加入者のサーバーを運用するものではなく、顧客インフラ内の証明書のインベントリを作成するものでもない。これらは、DigiCert が何が起こり、何が変わるのかを説明しなければならない公的な説明責任のフォーラムを作り出す。
DigiCert の報告は組織的原因について異例なほど率直だった
DigiCert のインシデント報告で最も価値があるのは証明書の数ではない。それは根本原因に関する文言だった。DigiCert は、ドメイン検証フローを統合し、複数のメソッド間でランダム値を再利用するための変更を展開した際に問題が明らかになったと述べた。システム内の 1 つのパスが、CNAME 検証を使用する際にアンダースコアを含めていなかったと指摘した。根本原因として、エンジニアリングとコンプライアンス間のサイロ化、シリアル番号を含まない証明書問題報告を真剣に受け止めなかったこと、エンジニアリングの厳格さの欠如を挙げた。
この率直さが重要なのは、Web PKI のインシデントがしばしば狭義のコンプライアンス欠陥として扱われるからだ。検証プレフィックスの欠落はコードのバグと説明できるが、DigiCert 自身の報告はそれを組織的なシステム障害として位置づけた。コンプライアンスに不可欠なエンジニアリングは、コンプライアンス解釈とは別の精神的領域に存在することはできない。シリアル番号のない証明書問題報告でも、依然として真の警告であり得る。統合プロジェクトはシステムを改善する一方で、古いワークフローの境界から受け継がれた欠陥を表面化させることもある。
同じ Bugzilla の記録には、内部チームが常に必要とされるほど協力できていなかったこと、そして彼らに依存する世界がそれを許容できないものであることを DigiCert のリーダーシップが認める内容が含まれている。これは法的な認定ではないが、強力な制度的な告白である。公的に信頼される認証局は単なる SaaS ベンダーではない。その検証コードは、ブラウザ、オペレーティングシステム、ウェブサイト、政府機関、銀行、病院、ユーザーが CA の内部ワークフローを見ることなく依存する主張を行う。
DigiCert はまた、影響を受けたパスは OEM 検証システムに限定されており、CertCentral や CIS ではないと述べた。この境界は重要である。これにより、インシデントがすべての DigiCert 検証チャネルの障害として誇張されるのを防ぐ。しかし、この境界は管理上の疑問も提起する。なぜ 1 つの検証システムパスが異なるコンプライアンス動作をしたのか、そしてなぜデータモデルが事後に準拠ケースと非準拠ケースを区別するのに十分な詳細を保持していなかったのか。
過大カウントの決定は理解できる。CA がどの証明書がアンダースコア欠落で発行されたかを判断できない場合、リスクセット内のすべての証明書を失効させることは、非準拠の可能性がある証明書を存続させるよりも依拠当事者の信頼にとって安全である。しかし、過剰な失効は加入者の混乱とサポート負担を増大させる。これが、証明書発行データのフォレンジック精度の不足の代償である。
したがって、CA にとっての説明責任の教訓は 2 つある。第 1 に、検証の実装にはベースライン要件に対する厳格なテストカバレッジが必要である。第 2 に、発行システムは正確な修復をサポートするのに十分な証拠記録を保持する必要がある。CA は、自社のシステムがコンプライアンスに不可欠な事実を保存できなかったために、過少失効と大量の過剰失効のどちらかを選択せざるを得ない状況に陥るべきではない。
加入者側はポリシーを痛みに変えた
DigiCert の最初の Bugzilla の更新では、83,267 件の証明書が 6,807 の加入者に影響したと述べていた。また、重要なインフラ、不可欠な通信ネットワーク、クラウドサービス、医療業界を運営する多くの顧客は、重要なサービス中断なしに失効される状況になかったとも述べている。この声明は一律の免除ではなかった。これは、加入者エコシステムの大部分が迅速な交換に対して運用上の準備ができていなかった証拠である。
CISA のDigiCert 証明書失効警報は、公共サービスへの影響を示している。CISA は、DigiCert がドメイン制御検証に関する非準拠の問題により TLS 証明書の一部を失効しており、その失効により、安全な通信のためにこれらの証明書に依存するウェブサイト、サービス、アプリケーションに一時的な中断が生じる可能性があると警告した。CISA は顧客に対し、DigiCert アカウントを確認し、証明書を再発行または再キー化するよう促した。7 月 31 日の更新では、最新情報と期限を案内し、更新された失効期限までに再発行または再キー化ができない場合は DigiCert に連絡するよう促した。
Google Cloud のDigiCert 失効イベントに関するインシデントページは、CA イベントがクラウド顧客の作業にどのように転換されるかを示しているため有益である。クラウドプロバイダーは検証バグを引き起こしていないかもしれないが、サービス、ロードバランサー、API、ゲートウェイ、または管理製品が影響を受ける証明書に依存する可能性のある顧客を抱えている。認証局が大規模に失効する場合、仲介者は影響を受ける資産を特定し、コミュニケーションを取り、交換パスを提供し、ダウンタイムを削減する必要がある。
中小規模の組織にとっては、痛みはより深刻になり得る。SME は、ホスティングパネル、ファイアウォール、VPN アプライアンス、POS システム、メールゲートウェイ、ID プロバイダー、API ゲートウェイ、モバイルアプリバックエンド、SaaS 統合、ベンダー管理プラットフォームに証明書をインストールしている可能性がある。証明書を注文した担当者は退職しているかもしれない。DNS 検証の連絡先はリセラーかもしれない。証明書はスプレッドシートで管理されているか、まったく管理されていない可能性がある。交換には、時間外の変更承認やベンダーチケットが必要かもしれない。24 時間はスクリプトにとっては長い時間だが、脆弱な組織にとっては短い時間である。
これが「SME サービス継続性」というラベルが適合する理由である。このインシデントは、セキュリティ管理の修正を通じて可用性を脅かした。証明書は数学的には小さくても、運用上は中心的であり得る。交換なしに有効期限が切れたり失効したりすると、ブラウザやクライアントは接続を拒否し、API が失敗し、ユーザーに警告が表示され、「証明書インフラストラクチャ」のように見えなかったサービスが利用できなくなる。
加入者の説明責任は現実である。公共サービスを運営する組織は、どの証明書を持っているか、どこに展開されているか、どの CA が発行したか、いつ有効期限が切れるか、どのように交換するか、誰が変更を承認するか、自動化が存在するかどうかを把握すべきである。しかし、CA の説明責任もまた現実である。失効が必須であることを知っている CA は、通常の更新だけではなく、緊急交換のために検証、インベントリ、通知、顧客ツールを設計すべきである。
リセラーと顧客チャネルは障害面の一部だった
Bugzilla の議論には、リセラーが加入者に失効情報を提供しない可能性や、メールのみの通知が混乱を招いたという懸念が含まれていた。DigiCert は後に、ユーザーに警告するためにコンソール内メッセージを追加したが、短期間でメール以外の方法でコミュニケーションを取ることは困難だったと述べた。これは大きな結果をもたらす実際的な詳細である。
認証局は、アカウント階層、リセラー、エンタープライズ調達チーム、マネージドサービスプロバイダー、クラウド仲介者を通じて運営されることが多い。ライブエンドポイントを制御する加入者が、CA のメールを受信するアカウント所有者であるとは限らない。リセラーは通知を受信し、それを転送する必要があるかもしれない。中央のセキュリティチームが CA アカウントを所有し、アプリケーション所有者が展開を所有する場合もある。マネージドサービスは、顧客に代わって秘密鍵と証明書を保持する場合もある。すべての受け渡しが、24 時間の失効ウィンドウ内で時間を消費する。
これにより、失効コミュニケーションは礼儀ではなく管理手段となる。緊急通知は、技術担当者、アカウント担当者、リセラー担当者、機械可読エンドポイントに届くべきである。影響を受ける証明書のシリアル番号、ドメイン、製品、交換手順、期限、不作為の結果を特定すべきである。アカウントコンソール、API、メール、ステータスチャネルを通じて利用可能であるべきである。加入者が完全な影響インベントリをエクスポートしやすくすべきである。
DigiCert の失効インシデント通知は、CISA や Mozilla の議論でリンクされており、顧客向け通知の役割を果たした。CISA が最新のタイムラインのために参照したstatus.digicert.comの DigiCert ステータスポータルも同様である。これらのページは、アーカイブアクセスが不完全であっても重要である。なぜなら、公的機関やルートプログラムの議論が、インシデント中に顧客をそこに誘導したからである。
コミュニケーションは、失効が任意であるという誤った約束を生み出さないようにする必要もあった。Bugzilla の参加者の 1 人は、失効が必須であり、交渉可能であるかのように示唆する可能性があるという理由で、顧客の遅延要求の考えを批判した。DigiCert 自身も後に、遅延失効は許可されておらず、そのようなフォームは許可されていると伝える可能性があるため、遅延要求フォームを作成したくないと述べた。この緊張は現実である。CA は重要インフラのリスクについて聞く必要があるが、ルールは非公開の会話に参加しない依拠当事者を保護するために存在する。
より良い答えは沈黙ではない。それは準備された、ポリシーと一貫性のあるコミュニケーションである。加入者は、CA が延長交渉なしに失効させる可能性があることを事前に知っておくべきである。迅速に交換するための自動化を備えるべきである。CA は正確なインベントリとマルチチャネル通知を持つべきである。ルートプログラムは、例外的な要求が非公開の取引にならないように、公開インシデント議論を十分に可視化すべきである。
法的圧力が強制失効の脆弱な部分を露呈させた
遅延失効報告には、顧客が失効に対する一時的差止命令を申請したとの通知を DigiCert が受け取ったと記されている。公開ドケットであるAlegeus Technologies LLC v. DigiCertは、加入者の継続性圧力が CA の義務と衝突する可能性を示すインシデント記録の一部である。後の Bugzilla のコメントでは、法的問題は当事者間で解決されたと述べられている。
法的紛争を過大解釈すべきではない。一時的な裁判所への提出は、DigiCert が正しいか間違っているか、あるいは顧客が失効を阻止する永続的な権利を持っているかについての最終的な認定ではない。それはインシデント中の圧力の証拠である。ダウンタイムに直面する加入者は、失効が害を及ぼすと考える場合、法的ツールに手を伸ばすかもしれない。ルートプログラムの義務に直面する CA は、加入者契約と公的信頼ルールに基づいて失効する権限を擁護する必要があるかもしれない。
これは Web PKI の構造的な問題である。世界中の依拠当事者は、CA が誤発行された証明書を速やかに失効させることに依存している。1 人の加入者は、自身のサービスが稼働し続けることに依存している。裁判所、契約、緊急申請はローカルであり得るが、ブラウザの信頼はグローバルである。CA が 1 人の加入者が法的救済を得たために遅延した場合、リスクはその加入者に隔離されない。それは公的信頼記録の一部となる。
したがって、加入者契約とエンタープライズ契約は明示的であるべきだ。CA は、ベースライン要件やルートプログラムポリシーによって要求される場合に証明書を失効させる権利を保持しなければならない。顧客は、運用上の不便さが遅延の保証ではないことを知っておくべきだ。同時に、CA は、何年も証明書を手動資産として扱った後に緊急失効が驚きとして訪れないように、顧客プログラムを設計すべきである。
このインシデントは、法的準備が CA のインシデント準備の一部であることも示唆している。CA は、次の大量失効の前に、誰が差止命令要求を審査できるか、加入者契約が強制失効をどのようにサポートするか、どのような公的声明が出せるか、そして持っていない権限をルートプログラムに求めることなくどのように調整するかを知っておくべきである。即興に使える時間はあまりに短い。
自動化が欠けていた回復力の層
遅延失効のバグには、エピソード全体で最も明確な一文が含まれている。失効が完了した後、DigiCert は、組織が 24 時間以内に交換できなかった最大の理由は、業界の大多数の組織が依然として証明書の発行、維持、交換に自動化を使用していなかったことだと述べた。それが運用上の教訓である。
RFC 8555で定義された ACME は、証明書の発行と管理を自動化するために作られた。自動化は ACME に限定されず、すべてのエンタープライズシステムが ACME に対応しているわけでもない。しかし、原則はより広範である。証明書は、年に一度の手動の儀式ではなく、テストされたワークフローを通じて更新および交換可能であるべきだ。CA/Browser Forum のSC-063 投票（短寿命証明書と自動化インセンティブに関する）は、このインシデント以前から、業界がより短いライフタイムとより優れた俊敏性に向けて推進していたことを示している。
Chrome ルートプログラムの Bugzilla コメントも同じ点を指摘した。Chrome の代表者は、失効イベントの混乱を減らすために、Web PKI 全体の俊敏性と回復力の向上を優先しており、自動化や ARI スタイルのアプローチは、CA と加入者による広範な採用がなければ限られた利益しかないと指摘した。ACME Renewal Information 拡張ドラフトは、CA が ACME クライアントに更新タイミング情報をシグナリングできるようにすることを目的としており、関連性がある。これはすべての遅延失効問題に対する完全な解決策ではないが、正しい方向性を示している。それは、機械可読な更新と交換の調整である。
自動化はインベントリにとっても重要である。加入者は、見つけられないものは交換できない。証明書管理は、どの証明書が DigiCert にチェーンされているか、CA インシデントの影響を受けるのはどれか、どのシステムがそれらを使用しているか、どの秘密鍵が利用可能か、どの所有者が責任を負うか、どの交換が展開されたか、どのエンドポイントがまだ失効または古い証明書を提供しているか、といった基本的な質問に迅速に答えるべきである。多くの組織は、緊急時に証明書インベントリが願望に過ぎないことを発見する。
CA にとって、自動化には影響を受ける証明書の発見と顧客通知が含まれなければならない。Bugzilla での DigiCert の議論では、証明書と連絡先情報の収集に中央データレイクとビジネスインテリジェンスチームが関与していたと述べられている。この詳細は、どの CA も心配すべきである。24 時間の期限内にリストを組み立てるために通常のインシデント対応外のチームが必要な場合、プロセスは十分に運用化されていない。失効に必要なデータはインシデント対応の準備ができているべきである。
自動化は説明責任を回避する方法ではない。それは、インターネット規模で説明責任が可能になる手段である。迅速な失効を要求するルールは、CA と加入者が毎回人的な多大な努力なしに迅速な交換を実行できる場合にのみ信頼できる。
交換ワークフローには、成功の検証も含める必要がある。加入者は、新たにダウンロードした証明書をインシデントの終わりと見なすべきではない。証明書がすべてのエンドポイントにインストールされていること、中間チェーンが正しいこと、古い証明書がセカンダリロードバランサーやディザスタリカバリサイトからまだ提供されていないこと、監視が失効したシリアルを確認しなくなったこと、依存するクライアントが交換を受け入れることを確認する必要がある。大規模な環境では、これらのチェックにはスキャンとサービス所有者の証明が必要であり、単一のアカウントコンソールのスクリーンショットではない。DigiCert のイベントは、証明書の俊敏性がライフサイクル規律である理由を示した。発見、発行、展開、検証、監視、廃棄。これらのステップのいずれかが欠けると、CA のコンプライアンス修正が長引く顧客のダウンタイムに変わる可能性がある。
同じ教訓は経営監視にも当てはまる。証明書の交換は、1 人のインフラ所有者が扱う静かな更新作業としてではなく、回復力の演習としてリハーサルされるべきである。取締役会やリスク委員会はすべてのシリアル番号を検査する必要はないが、重要な公共サービスが年次更新シーズン外に証明書を交換できるかどうか、例外要求が法務および運用チームに迅速に届くかどうか、組織が失効がユーザーに到達する前に完了を証明できるかどうかを把握すべきである。その意味で、DigiCert のエピソードは、多くの加入者が時計が動き始めてから初めて発見した机上訓練でもあった。
影響を受けた証明書は信頼の問題であり、必ずしも悪用の発見ではない
公的記録は、非準拠検証と大量失効の認定を裏付けている。ここで使用した情報源からは、攻撃者が DigiCert のバグを悪用して主要サービスの証明書を取得したという広範な認定は裏付けられない。Bugzilla の参加者は、DigiCert が悪用の調査を行ったかどうかを質問し、ユーザーが任意のサブドメインを作成できるサービスを含む可能性のあるリスクシナリオについて議論した。これらの質問は重要だが、質問は認定ではない。
この境界は重要である。悪用を誇張することは無責任である。リスクを過小評価することも間違いである。ドメイン制御検証の目的は、関連ドメインを制御していない当事者への発行を防ぐことである。検証メソッドが必要な境界を緩めた場合、既知の攻撃者が使用しなかったとしても、CA はそのパスを通じて発行された証明書を疑わしいものとして扱わなければならない。公的信頼は、依拠当事者がすべての発行イベントを調査できないという理由だけで、ルール遵守に依存している。
CCADB 公開サイトは、ルートストアや CA が使用する透明性インフラの文脈を提供し、crt.shや Certificate Transparency ログは、コミュニティが発行された証明書を検査するのに役立つ。Bugzilla スレッドでは、コミュニティメンバーが DigiCert 提供の証明書リストを証明書透明性データと比較分析した。これは Web PKI の強みである。公開証拠が外部レビューのために存在する。また、発行後の透明性が発行前の正しい検証に取って代わるわけではないことを思い出させるものでもある。
インシデント報告には、DigiCert がリスクセット内のすべての証明書を失効させるとあり、たとえそのセットが過大にカウントされていたとしても、とある。これは保守的な信頼判断である。しかし、保守的な信頼判断は可用性のコストを課す。したがって、Web PKI は両面に投資しなければならない。より良い検証管理を通じて誤発行を減らし、より良い交換自動化を通じて混乱を減らすことである。
この区別はエンドユーザーにとっても重要である。失効した証明書の警告を見るブラウザユーザーは、その証明書が積極的に悪用されたのか、非準拠のパスで発行されたのか、保守的な過大カウントに巻き込まれたのかを知らない。ユーザーはサービスの問題だけを見る。だからこそ説明責任は失効で止まってはならない。顧客コミュニケーションと迅速な修復を含め、セキュリティシグナルが意味を保ち、ユーザーが警告をクリックして通過する別の理由にならないようにしなければならない。
ルートプログラムは監督者であり、顧客の稼働時間の運用者ではなかった
Mozilla、Chrome、Apple、Microsoft のルートプログラムは、公的に信頼される CA エコシステムを形成している。Mozilla のルートストアポリシー、Chrome のルートプログラムポリシー、Apple のCertificate Transparency と信頼できる証明書プログラム情報、Microsoft のTrusted Root Program 要件はすべて、CA が活動する信頼環境を定義するのに役立っている。具体的なポリシーは異なるが、共通する考え方は、ルートストアへの包含は信頼できる CA の行動に条件付きであるということだ。
DigiCert のインシデントは、その監督の限界を示している。ルートプログラムは報告を要求し、パターンを評価し、CA を信頼しないものとし、アクションアイテムを要求し、業界全体の改善を推進することができる。しかし、病院の証明書を再配置したり、通信事業者のロードバランサーを更新したり、顧客の変更管理プロセスを書き換えたり、リセラーに通知を即座に転送させたりすることはできない。停止防止の作業は分散している。
それによってルートプログラムが受動的になるわけではない。彼らの公式 Bugzilla コメントは、私的な例外作りに抵抗し、ベースライン要件に対する圧力を維持したために重要だった。Chrome の「例外を認める権限がない」というコメントは説明責任の声明である。Mozilla が後に遅延失効ポリシーの改訂について議論したことは、このインシデントがルートプログラムのガバナンスにフィードバックされ得ることを示した。公開ルートプログラムフォーラムは、CA の説明が影響を受ける顧客と CA 以外の者によってレビュー可能になる場所である。
CA/Browser Forum は別の層である。フォーラムは、CA とブラウザ間の合意を通じてベースライン要件を作成する。TLS ベースライン要件ページは、したがって、DigiCert だけに課せられた外部の法令ではない。DigiCert と他の CA は、義務を生み出すエコシステムに参加している。後になって CA がその義務が運用上苦痛であると感じるなら、それはエコシステムの俊敏性を改善するシグナルであり、義務が恣意的であるという証拠ではない。
最も難しいガバナンスの問題は、重要度の低い非準拠と高い可用性リスクに対して、失効タイムラインをより柔軟にすべきかどうかである。Web PKI コミュニティの理性的な人々の間でも意見が分かれている。本稿はそのポリシー論争を解決するものではない。説明責任の事実を特定するものである。インシデント時点で、DigiCert は 24 時間の要件を認識し、その後 120 時間かけて失効を完了した。その不一致は公的信頼イベントである。
DigiCert が管理したものと加入者が管理したもの
DigiCert は、検証コードパス、エンジニアリングとコンプライアンスのレビュープロセス、証明書問題報告への対応、修正、影響を受ける証明書の特定プロセス、顧客通知、公開インシデント報告、失効の実行、フォローアップのアクションアイテムを管理していた。また、システムがどの検証が準拠したアンダースコアを使用したかを正確に区別するのに十分なデータを保持しているかどうかも管理していた。公的記録では、そのデータ精度は欠落していた。
DigiCert は、すべての加入者の証明書展開を管理していたわけではない。すべてのリセラーの受け渡し、すべてのエンタープライズ変更委員会、すべてのアプライアンスの制限、すべてのクラウド顧客のアーキテクチャ、すべての病院のメンテナンスウィンドウを管理していたわけではない。また、ベースライン要件だけを管理していたわけでもない。DigiCert は、それらを遵守し、遵守しなかった場合に説明する責任を負っていた。
加入者は、インベントリ、所有権、自動化、展開アーキテクチャ、更新テスト、ベンダーエスカレーション、変更管理の準備を管理していた。1 日以内に公開 TLS 証明書を交換できない加入者は、即時のトリガーが DigiCert の過失であるかどうかに関わらず、可用性リスクを抱える。次のトリガーは、キーの漏洩、短期証明書ポリシー、緊急の信頼喪失イベント、秘密鍵の露出、有効期限エラーである可能性がある。
リセラーとマネージドサービスプロバイダーは、CA の通知とエンドポイント運用者の間の受け渡しを管理していた。通知を受け取っても転送しなかったり、それをライブシステムにマッピングできなかったりした場合、彼らは停止面の一部となった。クラウドプロバイダーは、自らが運用するサービスの管理証明書レイヤーと顧客コミュニケーションを管理していた。CISA のような公的機関は、CA のシステムではなく、公的警告と顧客ガイダンスを管理していた。
エンドユーザーはほとんど何も管理していなかった。彼らは、ブラウザとクライアントが証明書の信頼を強制し、CA が正しく検証し、サービス事業者が証明書を交換し、ルートプログラムが CA の責任を追及することに依存していた。証明書が失効し、サービスが失敗した場合、ユーザーの選択肢は、サービスの使用を中止するか、クライアントがバイパスを許可する場合はリスクを受け入れるか、待つことであった。この非対称性が、負担が機関にある理由である。
次のインシデントに備えたより良い証拠と管理
より良いインシデント後管理セットは、検証設計から始まる。すべての CA は、サポートする各ベースライン要件検証メソッドに直接マッピングされる実行可能なテストを維持すべきである。メソッドの文言がアンダースコアプレフィックス付きラベルを要求する場合、それがないとテストは失敗すべきである。複数の製品や OEM システムが同じメソッドを実装する場合、コンプライアンスレビュー済みの検証ライブラリを共有するか、同等の動作を証明すべきである。
DigiCert によるドメイン制御検証コードのgithub.com/digicert/domain-control-validationでの公開や、Maven Centralでのパッケージ情報、javadoc.ioでのドキュメントは、ここに関連する。オープン実装資料は、顧客やコミュニティが検証動作を理解するのに役立つが、オープンコードだけでは本番環境の設定を証明したり、組織的リスクを排除したりはしない。
第 2 に、発行記録はコンプライアンスに不可欠な事実を保持すべきである。CA は、有効な証明書ごとに、どの検証メソッドが使用されたか、どのシステムパスがそれを実行したか、どの DNS レコードが観測されたか、必要なプレフィックスが存在していたか、いつ検証が行われたか、どのアカウントまたはリセラーが関与したか、そしてどの証明書がその検証に依存したかを答えられるべきである。この情報は、即興のビジネスインテリジェンス作業を必要とせずに、インシデントのプレッシャー下でクエリ可能であるべきだ。
第 3 に、失効コミュニケーションは機械可読であるべきだ。加入者は、API、ダッシュボード、自動化フックを通じて、影響を受けるシリアル番号や交換要件を取得できるべきである。メールは必要だが不十分である。コンソールバナーは役立つが、毎日ログインしない運用者を見逃す可能性がある。リセラーは、契約上の義務と技術的メカニズムを持って、迅速に通知を通過させるべきである。
第 4 に、加入者は証明書の部品表を維持すべきである。それには、公開および非公開の証明書の場所、更新所有者、自動化ステータス、キーストレージ、依存サービス、交換ランブック、緊急連絡先を含めるべきである。証明書インベントリは、年次更新シーズン外に証明書を交換することでテストされるべきだ。プレッシャー下で証明書を一度も交換したことのないランブックは、単なる希望に過ぎない。
第 5 に、ルートプログラムと CA/Browser Forum は、私的な例外文化が常態化するのを許さずに、遅延失効に関する公的議論を継続すべきである。ルールが進化するなら、透明性をもって進化すべきである。進化しないなら、CA と加入者はそれらを満たすための運用を構築しなければならない。
永続的な教訓
DigiCert の 2024 年の失効インシデントは、信頼と稼働時間がどのように衝突するかについてのコンパクトな教訓である。検証パスは必須のアンダースコアを見逃した。CA は、準拠しているケースと非準拠のケースを正確に分離できなかった。ルールは迅速な失効を要求した。顧客は十分な自動化を欠いていた。一部の重要サービス事業者は混乱に直面した。法的異議が現れた。ルートプログラムは協議されたが、ルールを放棄することはできなかった。CISA は公衆に警告した。DigiCert は最終的に影響を受けた TLS 証明書を 5 日間で失効させ、組織的原因を認めた。
この話における攻撃者は、もし存在したとしても、公的記録の要点ではない。記録は機関の管理についてである。DigiCert は検証と失効を管理した。ルートプログラムは信頼の監視を管理した。加入者は展開の準備を管理した。リセラーとクラウドプロバイダーはコミュニケーションパスを管理した。ユーザーは結果を負った。
実践的な基準は明確である。認証局は、サポートするすべての検証メソッドが必要とされる通りに実装されていること、証明書記録が正確な修復のための十分な詳細を保持していること、そして緊急失効が人海戦術的なデータ収集を必要とせずに実行できることを証明できるべきである。加入者は、公開証明書を迅速に、繰り返し、自動化を通じて交換できるべきである。ルートプログラムは、信頼判断が見えるように、インシデント報告を十分に公開し続けるべきである。
Web PKI の信頼性は、ルールの居心地の悪い部分に依存している。誤発行または非準拠の証明書は、たとえ運用上苦痛であっても、迅速に信頼から外れなければならない。答えは、失効が常に痛みを伴わないふりをすることではない。答えは、次の強制失効が期限をめぐる世界的なスクランブルではなく、管理されたメンテナンスワークフローになるように、証明書運用を構築することである。