DigiCert の失効期限が証明書検証を稼働時間の説明責任テストに変えた

概要

• DigiCert は、Mozilla Bugzilla において、OEM 検証システムの一部で、CNAME レコード内のランダム値を用いたドメイン検証を、必須のアンダースコアプレフィックスなしで実施していたことを報告した。同社のインシデントレポートによると、この方法で発行された有効な TLS 証明書は 83,267 件に上り、システムがアンダースコアの有無を適切に保存していなかったために、影響を受けたセットは過大計上されている可能性が高いという。
• 失効問題は即座に発生した。CA/Browser Forum の TLS Baseline Requirements は、誤発行証明書に対して定められた期限内の失効を要求しており、DigiCert の遅延失効に関するインシデントレポートでは、当時の規則で定められた 24 時間ではなく、120 時間以内に影響を受けた 83,267 件すべての TLS 証明書を失効させたと述べている。
• この出来事は単なる CA のコーディングミスにとどまらない。加入者側の証明書インベントリの脆弱性、リセラーやエンタープライズアカウントを介したコミュニケーションの限界、顧客による一時的差止命令をめぐる法的圧力、そして多くの組織が依然として大規模かつ迅速に証明書を交換するための自動化を欠いている事実を露呈した。
• 実際の制御は分散していた。DigiCert は検証実装、証明書特定、カスタマー通知、失効実行、インシデント報告を管理していた。ルートプログラムと CA/Browser Forum は信頼の期待とポリシー圧力を管理していたが、顧客のデプロイは管理していない。加入者は各自のインベントリ、自動化、変更ウィンドウ、サービス固有の展開を管理していた。エンドユーザーはほとんどリスクを管理できなかった。
• 説明責任の教訓は、認証局は失効を稀な書類手続きとして扱うことはできず、加入者は公開信頼 TLS 証明書を静的なインフラと見なすことはできないということだ。Web PKI の安全モデルは、緊急事態が到来する前に迅速な交換が運用上退屈なものとなっていることに依存している。

アンダースコアの欠落がグローバルな継続性問題に発展した

DigiCert のインシデントは、句読点の問題に矮小化すれば軽視されがちだ。技術的問題は、ある DNS CNAME ベースのドメイン制御検証パスにおいて、必須のアンダースコアプレフィックスが欠落していたことにある。しかし、その結果は単なるタイポグラフィ修正では済まなかった。DigiCert は、クラウドサービス、通信ネットワーク、医療環境、エンタープライズアプリケーション、顧客向けウェブサイトにデプロイされた数万件の公開信頼証明書を特定し、失効させなければならなかった。

DigiCert 自身の公開インシデント記録であるMozilla Bugzilla bug 1910322が事実の基盤である。DigiCert は、DNS ベースの検証方法である method 7 の実装に問題がある可能性を示す証明書問題レポートを受領したことを報告した。複数の DNS 関連検証プロセスを説明し、コードレビューにより、ランダム値がホストとして CNAME レコードで使用され、最初にアンダースコアが付加されない場合に証明書が発行されるパスが 1 つ特定された。同じバグの後続エントリで、DigiCert のインシデントレポートは、影響が OEM 検証システムを使用する発行者に限定され、CertCentral および CIS（クラウドプロバイダー向けの大量発行エンジン）を介した検証パスはドメインを正しく検証しており、影響を受けていないと述べている。

数値も公開インシデント記録からのものだ。DigiCert は、この方法に基づいて 83,267 件の有効な証明書が発行され、修正日前に CNAME ベースの DNS 検証を使用したとデータベースにリストされているすべての有効な証明書を失効させると述べた。OEM システムの制御ではアンダースコアの有無を十分に保存していなかったため、真に影響を受けたセットは過大計上されている可能性が高いと説明している。この一文が説明責任の要である。システムはリスク母集団を特定できたが、準拠形式を持つ証明書を明確に証明できなかった。信頼システムでは、コンプライアンスに関する不確実性が失効義務になりうる。

アンダースコアのセキュリティ上の理由は、単なる見た目ではない。CA/Browser Forum の検証方法は、加入者が管理する名前と、より大きなドメインの下で委任またはユーザー作成される可能性のある名前を区別する。Bugzilla の議論では、アンダースコアプレフィックス付きラベルが、通常のホスト名や多くの委任サブドメインサービスが回避できる特別な検証名前空間を作成するのに役立つことが強調された。アンダースコアの欠落は、ユーザーが管理していないドメインの下でサブドメインを作成できる場合に、望ましくない証明書発行を防ぐために使用される前提を弱める可能性がある。

このため、このイベントは DNS 委任権限に該当する。ドメイン検証は、DNS からのエビデンスを証明書発行権限に変換する方法である。エビデンスが誤った場所から受け取られたり、必要な境界マーカーが欠落していたりすると、CA はより弱い DNS 配置を管理証明とみなす可能性がある。その後、証明書はリライングパーティにブラウザ信頼のシグナルを提供する。発行権限は、DNS 委任を正しく解釈する権限に結びついている。

規則は規則として機能した：規則は行動を強制した

インシデントの中心にあるのは、CA/Browser ForumTLS Baseline Requirementsという公開規則セットである。これらは、公開信頼 TLS サーバ証明書のドメイン検証方法と証明書失効義務を定義している。説明責任構造を説明するためにすべての要件を引用する必要はない。証明書が誤発行されたか、検証がベースライン要件に準拠していなかった場合、規則自体が別のパスを許可しない限り、CA は適用期限内に失効させなければならない。

DigiCert の遅延失効レポート（Mozilla Bugzilla bug 1910805）は、コンプライアンス上の矛盾を明確に述べている。DigiCert は、24 時間以内にすべての証明書を失効させることに取り組んでいたが、影響についてルートプログラムおよびコミュニティと協議した後、遅延を決定し、120 時間以内にすべての影響を受ける証明書を失効させたという。後のインシデントレポートは影響を要約し、DigiCert は当時のベースライン要件で要求されていた 24 時間ではなく、5 日間で 83,267 件の証明書を失効させたと述べている。

この承認は重要である。なぜなら、二つのインシデントを区別するからだ。Bug 1910322 はドメイン検証の非準拠に関するもの、Bug 1910805 は遅延失効に関するものだ。第一の問題は、証明書がどのように非準拠と見なされるに至ったかである。第二の問題は、顧客がライブサービスでそれらの証明書に依存し続ける中で、エコシステムがそれらの証明書を信頼から削除する義務をどのように処理したかである。

この区別は浅薄な議論を防ぐ。DigiCert は単に即時失効して規則に従うべきだった、というのがクリーンなポリシー立場である。即時失効は重要なサービスを中断させたであろうから、遅延は現実的だった、というのが運用上の立場である。このインシデントは、両者の間の不快なギャップを示している。公開信頼規則は、無効または誤発行証明書からリライングパーティを保護するために設計されている。現実の加入者は、証明書をメンテナンスウィンドウ、アプライアンス、ロードバランサー、組み込みシステム、変更承認に縛られた交換困難な資産として運用することが多い。

ルートプログラムは権限について慎重だった。Bugzilla スレッドで、Chrome ルートプログラム代表者は、CA/Browser Forum ベースライン要件の例外を認める権限を持たず、それらの要件は単一のルートプログラムが所有するものではなく、合意に基づくものだと述べた。Chrome ルートプログラムポリシーは、ブラウザルートのより広範な文脈を提供する。CA はプログラムの期待、インシデント評価、継続的なコンプライアンス圧力の下でルートストアに参加する。しかし、危機時のルートプログラムの協議は、公開規則からの魔法の免除ではない。

Mozilla のルートストアポリシーとCA インシデント対応ガイダンスは同様の機能を果たす。これらは、インシデント報告と応答性を信頼ガバナンスの一部とする。加入者のサーバを運用するわけでも、顧客インフラ内の証明書をインベントリするわけでもない。DigiCert が何が起きたのか、何を変えるのかを説明しなければならない公開説明責任のフォーラムを作り出す。

DigiCert のレポートは組織的原因について異例なほど率直だった

DigiCert のインシデントレポートで最も価値のある部分は、証明書の数ではない。根本原因に関する記述だ。DigiCert は、ドメイン検証フローを統合し、複数の方法でランダム値を再利用する変更をデプロイした際に問題が露呈したと述べた。CNAME 検証を使用する際に、システム内の 1 つのパスにアンダースコアが含まれていなかった。エンジニアリングとコンプライアンス間の縦割り、シリアル番号を含まない証明書問題レポートを軽視したこと、エンジニアリングの厳格さの欠如などの根本原因を特定した。

この率直さは重要である。なぜなら、Web PKI インシデントは狭いコンプライアンス上の欠陥として扱われることが多いからだ。検証プレフィックスの欠落はコードバグと表現できるが、DigiCert 自身のレポートはそれを組織システムの失敗と位置づけた。コンプライアンス上重要なエンジニアリングは、コンプライアンス解釈とは別の精神的領域に存在することはできない。シリアル番号のない証明書問題レポートも、依然として本物の警告でありうる。統合プロジェクトは、古いワークフロー境界から受け継いだ欠陥を表面化させながら、システムを改善できる。

同じ Bugzilla の記録には、チーム間で必ずしも必要な連携が取れていなかったこと、そしてそれを当てにしている世界がそれを容認できないことを認める DigiCert のリーダーシップの発言が含まれている。これは法的な判断ではないが、強力な制度的承認である。公開信頼された認証局は、単なる別の SaaS ベンダーではない。その検証コードは、ブラウザ、オペレーティングシステム、ウェブサイト、政府機関、銀行、病院、ユーザーが、CA の内部ワークフローを見ることなく依存する主張を行う。

DigiCert はまた、影響を受けたパスが OEM 検証システムに限定され、CertCentral と CIS ではないと述べた。この境界は重要である。これにより、インシデントをすべての DigiCert 検証チャネルの失敗として誇張することが防がれる。しかし、この境界は制御上の疑問も提起する。なぜ 1 つの検証システムパスで異なるコンプライアンス動作があったのか、そしてなぜデータモデルが事後に準拠ケースと非準拠ケースを区別するのに十分な詳細を保持していなかったのか。

過大計上の決定は理解できる。CA がどの証明書がアンダースコア欠落で発行されたかを特定できない場合、リライングパーティの信頼のためには、可能性のあるすべての証明書を失効させる方が、非準拠の可能性のある証明書を生かしておくより安全である。しかし、過剰な失効は加入者の混乱とサポート負担を増大させる。これが、証明書発行データにおけるフォレンジック精度の不足のコストである。

したがって、CA にとっての説明責任の教訓は二つある。第一に、検証実装はベースライン要件に対する厳格なテストカバレッジを必要とする。第二に、発行システムは正確な修正をサポートするのに十分な証拠記録を保持しなければならない。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 システム、メールゲートウェイ、アイデンティティプロバイダー、API ゲートウェイ、モバイルアプリバックエンド、SaaS 統合、またはベンダー管理プラットフォームに証明書をインストールしているかもしれない。証明書を注文した担当者は退職しているかもしれない。DNS 検証の連絡先はリセラーかもしれない。証明書はスプレッドシートで追跡されているか、まったく追跡されていないかもしれない。交換には、深夜の変更承認やベンダーチケットが必要かもしれない。スクリプトにとっては 24 時間は長いが、脆弱な組織にとっては短い時間だ。

これが「SME サービス継続性」というマニフェストラベルが当てはまる理由である。このインシデントは、セキュリティ制御の修正を通じて可用性を脅かした。証明書は数学的には小さくても、運用上は中心的でありうる。交換なしに有効期限切れまたは失効すると、ブラウザやクライアントは接続を拒否し、API は失敗し、ユーザーは警告を目にし、「証明書インフラ」に見えなかったサービスが利用できなくなる。

加入者の説明責任は現実のものだ。公開サービスを運営する組織は、どの証明書を持っているか、どこにデプロイされているか、どの CA が発行したか、いつ期限切れか、どう交換するか、誰が変更を承認するか、自動化が存在するかを把握すべきである。しかし、CA の説明責任もまた現実だ。失効が必須であることを知っている CA は、緊急交換のために検証、インベントリ、通知、カスタマーツールを設計すべきであり、通常の更新だけのためではない。

リセラーとカスタマーチャネルは障害表面の一部だった

Bugzilla の議論には、リセラーが加入者に失効情報を提供しない可能性や、電子メールのみの通知が混乱を招いたという懸念が含まれていた。DigiCert は後に、ユーザーに警告するためにコンソール内メッセージを追加したが、短期間に電子メール以外で連絡することは困難だったと述べた。これは大きな結果をもたらす実務上の詳細である。

認証局はしばしば、アカウント階層、リセラー、企業調達チーム、マネージドサービスプロバイダー、クラウド仲介者を通じて運営される。ライブエンドポイントを管理する加入者は、CA の電子メールを受信するアカウント保持者ではないかもしれない。リセラーが通知を受け取り、転送する必要があるかもしれない。中央のセキュリティチームが CA アカウントを所有し、アプリケーション所有者がデプロイを管理するかもしれない。マネージドサービスが顧客に代わって秘密鍵と証明書を保持するかもしれない。すべての引き継ぎは、24 時間の失効ウィンドウ内で時間を消費する。

これにより、失効通知は制御手段であり、礼儀ではない。緊急通知は、技術担当者、アカウント担当者、リセラー担当者、機械可読エンドポイントに届くべきである。影響を受ける証明書のシリアル、ドメイン、製品、交換手順、期限、不作為の結果を特定すべきである。アカウントコンソール、API、電子メール、ステータスチャネルを通じて利用可能であるべきだ。加入者が完全な影響インベントリをエクスポートしやすくすべきだ。

DigiCert の失効インシデント通知は、CISA がリンクし、Mozilla の議論でも言及されており、顧客向け通知の役割を果たした。DigiCert のステータスポータルstatus.digicert.comも、CISA により更新タイムラインのために参照された。これらのページは、アーカイブアクセスが不完全であっても、公的機関やルートプログラムの議論がインシデント中に顧客を誘導したため重要である。

コミュニケーションはまた、失効が任意であるという誤った約束を生み出さないようにしなければならなかった。ある Bugzilla 参加者は、遅延を求める顧客のリクエストという考え方を批判した。なぜなら、強制失効が交渉可能であることを示唆する可能性があるからだ。DigiCert 自身も後に、遅延リクエストフォームを作りたくないと述べた。なぜなら、遅延失効は許容されておらず、そのようなフォームは許容されると伝える可能性があるからだ。この緊張は現実のものだ。CA は重要インフラのリスクについて聞く必要があるが、規則はプライベートな会話に参加しないリライングパーティを保護するために存在する。

より良い答えは沈黙ではない。準備された、ポリシーに整合したコミュニケーションである。加入者は、CA が延長交渉なしに失効させる可能性があることを事前に知るべきだ。迅速に交換するための自動化を備えるべきだ。CA は正確なインベントリとマルチチャネル通知を持つべきだ。ルートプログラムは、例外的な要求がプライベートな取引にならないように、公開インシデントの議論を十分に可視化すべきだ。

法的圧力が強制失効の弱いエッジを露呈した

遅延失効レポートによると、DigiCert は、顧客が失効に対する一時的差止命令を申請したという通知を受けた。公開訴訟記録Alegeus Technologies LLC v. DigiCertは、加入者の継続性圧力が CA の義務と衝突しうることを示すため、インシデント記録の一部である。後の Bugzilla コメントでは、法的問題は当事者間で解決されたとされた。

この法的紛争を過度に評価すべきではない。一時的な裁判所提出は、DigiCert の正否や、顧客が失効を阻止する永続的な権利を有するという最終判断ではない。それはインシデント中の圧力の証拠である。ダウンタイムに直面する加入者は、失効が害を引き起こすと信じる場合、法的ツールに手を伸ばす可能性がある。ルートプログラムの義務に直面する CA は、加入者契約と公開信頼規則の下で失効する権限を守る必要があるかもしれない。

これは Web PKI にとって構造的な問題である。世界中のリライングパーティは、CA が誤発行証明書を迅速に失効させることに依存している。加入者は自身のサービスの継続に依存している。裁判所、契約、緊急提出はローカルでありうるが、ブラウザの信頼はグローバルである。ある加入者が法的救済を得たために CA が遅延する場合、リスクはその加入者だけに隔離されない。それは公開信頼記録の一部となる。

したがって、加入者契約と企業契約は明示的であるべきだ。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 のコンプライアンス修正が長引く顧客のダウンタイムに変わりうる。

同じ教訓は管理監督にも当てはまる。証明書交換は、レジリエンス演習としてリハーサルされるべきであり、一人のインフラ所有者が処理する静かな更新作業として扱われるべきではない。取締役会やリスク委員会はすべてのシリアル番号を検査する必要はないが、重要な公開サービスが年次更新シーズン外で証明書を交換できるかどうか、例外リクエストが法務チームや運用チームに迅速に届くかどうか、そして組織が失効がユーザーに到達する前に完了を証明できるかどうかを知るべきである。その意味で、DigiCert のエピソードは、多くの加入者が時計が動き始めてから初めて発見した机上訓練でもあった。

影響を受けた証明書は信頼の問題であり、必ずしも悪用の発見ではなかった

公開記録は、非準拠の検証と大量失効の認定をサポートしている。ここで使用した情報源からは、攻撃者が DigiCert のバグを悪用して主要サービスの証明書を取得したという広範な認定をサポートしていない。Bugzilla 参加者は、DigiCert が悪用を調査したかどうかを尋ね、ユーザーが任意のサブドメインを作成できるサービスを含む可能性のあるリスクシナリオについて議論した。これらの質問は重要だったが、質問は発見ではない。

この境界は重要である。悪用を誇張することは無責任である。リスクを過小評価することも間違っている。ドメイン制御検証の目的は、関連ドメインを管理していない当事者への発行を防ぐことである。検証方法が必要な境界を緩和する場合、既知の攻撃者が使用していなくても、そのパスで発行された証明書を疑わしいものとして扱わなければならない。公開信頼は、リライングパーティがすべての発行イベントを調査できないからこそ、規則順守に依存する。

CCADB 公開サイトは、ルートストアと CA が使用する透明性インフラのコンテキストを提供し、crt.shや Certificate Transparency ログは、コミュニティが発行された証明書を調査するのに役立つ。Bugzilla スレッドで、コミュニティメンバーは DigiCert が提供した証明書リストを証明書透明性データと照合して分析した。これは Web PKI の強みである。公開エビデンスが外部レビューのために存在する。発行前の正しい検証が発行後の透明性に取って代わるわけではないことを再認識させるものでもある。

インシデントレポートでは、DigiCert はリスクセット内のすべての証明書を失効させると述べており、そのセットは過大計上されている可能性が高い。これは保守的な信頼判断である。しかし、保守的な信頼判断は可用性コストを課す。したがって、Web PKI は両面で投資しなければならない。より良い検証制御を通じて誤発行を減らし、より良い交換自動化を通じて混乱を減らす。

この区別はエンドユーザーにとっても重要である。失効した証明書の警告を見たブラウザユーザーは、根底にある証明書が積極的に悪用されたのか、非準拠のパスで発行されたのか、あるいは保守的な過大計上に巻き込まれたのかを知らない。ユーザーは単にサービスの問題を見る。だからこそ、説明責任は失効にとどまることができない。セキュリティシグナルが、ユーザーが警告をクリックスルーする別の理由になるのではなく、意味を持ち続けるように、顧客コミュニケーションと迅速な修正を含まなければならない。

ルートプログラムは監督者であり、顧客の稼働時間の運用者ではなかった

Mozilla、Chrome、Apple、Microsoft のルートプログラムは、公開信頼 CA のエコシステムを形成している。Mozilla のルートストアポリシー、Chrome のルートプログラムポリシー、Apple のCertificate Transparency および信頼できる証明書プログラム情報、Microsoft の信頼されたルートプログラム要件は、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 は、すべての加入者の証明書デプロイを管理していたわけではない。すべてのリセラーハンドオフ、すべての企業変更委員会、すべてのアプライアンス制限、すべてのクラウド顧客のアーキテクチャ、すべての病院のメンテナンスウィンドウを管理していたわけではない。また、単独でベースライン要件を管理していたわけでもない。要件を遵守し、遵守しなかった場合に説明する責任があった。

加入者は、インベントリ、所有権、自動化、デプロイアーキテクチャ、更新テスト、ベンダーエスカレーション、変更管理の準備を管理していた。公開 TLS 証明書を 1 日以内に交換できない加入者は、即時のトリガーが DigiCert の責任であるかどうかにかかわらず、可用性リスクを抱えている。次のトリガーは、キー漏洩、短期証明書ポリシー、緊急不信イベント、秘密鍵の露出、有効期限エラーかもしれない。

リセラーとマネージドサービスプロバイダーは、CA 通知とエンドポイントオペレータ間の引き継ぎを管理していた。通知を受け取ったが転送しなかった場合、またはライブシステムにマッピングできなかった場合、それらは停止表面の一部となった。クラウドプロバイダーは、自社が運用するサービスのマネージド証明書層とカスタマーコミュニケーションを管理していた。CISA のような公的機関は、公開警告と顧客ガイダンスを管理していたが、CA のシステムは管理していなかった。

エンドユーザーはほとんど何も管理していなかった。ブラウザとクライアントに依存して証明書の信頼を強制し、CA に正しく検証させ、サービスオペレータに証明書を交換させ、ルートプログラムに CA の説明責任を負わせていた。証明書が失効しサービスが失敗した場合、ユーザーの選択肢は、サービスを停止するか、クライアントがバイパスを許可する場合はリスクを受け入れるか、待つかだった。この非対称性こそが、負担が機関にある理由である。

次のインシデントのためのより良いエビデンスと管理策

より良いインシデント後の管理策セットは、検証設計から始まる。すべての CA は、サポートする各ベースライン要件検証方法に直接マッピングされる実行可能なテストを維持すべきである。方法の文言がアンダースコアプレフィックス付きラベルを要求する場合、テストはそれなしでは失敗すべきである。複数の製品や OEM システムが同じ方法を実装する場合、それらはコンプライアンスレビュー済みの検証ライブラリを共有するか、同等の動作を証明する必要がある。

後に DigiCert がgithub.com/digicert/domain-control-validationで公開し、パッケージ情報がMaven Centralで、ドキュメントがjavadoc.ioで公開されたことは、ここで関連する。公開実装資料は、顧客やコミュニティが検証動作を理解するのに役立つが、公開コードだけでは本番構成を証明せず、組織的リスクを排除するものでもない。

第二に、発行記録はコンプライアンス上重要な事実を保持すべきである。CA は、すべての有効な証明書について、どの検証方法が使用されたか、どのシステムパスがそれを実行したか、どの DNS レコードが観察されたか、必要なプレフィックスが存在したか、いつ検証が行われたか、どのアカウントまたはリセラーが関与したか、どの証明書がその検証に依拠したかを回答できるべきである。この情報は、即席のビジネスインテリジェンス作業を必要とせず、インシデント圧力下で照会可能であるべきだ。

第三に、失効通知は機械可読であるべきだ。加入者は、API、ダッシュボード、自動化フックを通じて、影響を受けるシリアルと交換要件を引き出せるべきだ。電子メールは必要だが不十分である。コンソールバナーは役立つが、毎日ログインしないオペレータを見逃すかもしれない。リセラーは、通知を迅速に伝達する契約上の義務と技術的メカニズムを持つべきだ。

第四に、加入者は証明書の部品表（BOM）を維持すべきである。公開証明書とプライベート証明書の場所、更新責任者、自動化状況、キーストレージ、依存サービス、交換ランブック、緊急連絡先を含むべきだ。証明書インベントリは、年次更新シーズン外で証明書を交換することによってテストされるべきである。プレッシャーの下で証明書を一度も交換したことがないランブックは、単なる希望に過ぎない。

第五に、ルートプログラムと CA/Browser Forum は、私的な例外文化が常態化することを許さずに、遅延失効に関する公開議論を継続すべきである。ルールが進化するなら、透明性をもって進化すべきである。進化しないのであれば、CA と加入者はそれらを満たすために運用を構築しなければならない。

永続的な教訓

DigiCert の 2024 年失効インシデントは、信頼と稼働時間がいかに衝突するかに関するコンパクトな教訓である。検証パスが必須のアンダースコアを見逃した。CA はすべての準拠ケースと非準拠ケースを正確に分離できなかった。規則は迅速な失効を要求した。顧客は十分な自動化を欠いていた。いくつかの重要サービス事業者は混乱に直面した。法的異議申し立てが現れた。ルートプログラムは協議されたが、規則を免除することはできなかった。CISA は一般に警告した。DigiCert は最終的に影響を受けた TLS 証明書を 5 日間で失効させ、組織的原因を認めた。

この物語における攻撃者が存在したとしても、公開記録の要点ではない。記録は制度的制御についてである。DigiCert は検証と失効を管理した。ルートプログラムは信頼監視を管理した。加入者はデプロイの準備を管理した。リセラーとクラウドプロバイダーは通信パスを管理した。ユーザーは結果を負った。

実用的基準は明確である。認証局は、サポートするすべての検証方法が要求通りに正確に実装されていること、証明書記録が正確な修正のために十分な詳細を保持していること、緊急失効が英雄的なデータ収集を必要とせずに実行できることを証明できるべきである。加入者は、自動化を通じて迅速かつ繰り返し公開証明書を交換できるべきである。ルートプログラムは、インシデント報告を、信頼決定が見えるように十分に公開し続けるべきである。

Web PKI の信頼性は、ルールの不快な部分にかかっている。誤発行または非準拠の証明書は、運用上苦痛であっても、速やかに信頼を離れなければならない。答えは、失効が常に無痛であるふりをすることではない。次の強制失効が、期限までの世界的な慌ただしい争奪戦ではなく、管理されたメンテナンスワークフローになるように、証明書運用を構築することである。