要約

  • Let's Encrypt は 2020 年 2 月 29 日、複数名を含む証明書要求で DNS CAA レコードを再確認する Boulder の処理に不具合があったと公表した [1]。
  • RFC 8659 は、CAA をドメイン名の保有者がどの認証局に証明書発行を認めるかを示す DNS リソースレコードとして定義している [2]。
  • 問題は Let's Encrypt が CAA を一般に対応していたかどうかではない。再利用された検証に含まれる各名前が、発行前に新しい確認を受けたかどうかである [1]。
  • Let's Encrypt の公式ページは、このサービスを Internet Security Research Group が提供する認証局と説明している。BTW の本番ディレクトリでは既存の internet-society エンティティを使うが、事実上の主語は Let's Encrypt/ISRG サービスであり続ける [3]。

何が起きたか

Let's Encrypt のインシデント告知によれば、2020 年 2 月 29 日に Boulder の欠陥が見つかった。Boulder は通常、購読者がドメイン名を管理していることを検証するときに CAA レコードを確認する。初回確認後も一定期間その検証が使えるため、発行直前に CAA を再確認する必要が生じることがある。Let's Encrypt は、検証が古い場合には発行前 8 時間以内に CAA を確認する必要があると説明した [1]。

不具合の形は具体的だった。CAA 再確認が必要な複数のドメイン名を含む証明書要求で、Boulder は 1 つの名前を選び、それを複数回確認していた。各対象名を個別に確認していなかったため、1 つ以上の名前が期待された新しい DNS 認可確認を受けないまま要求が通る可能性があった。Let's Encrypt は、03:08 UTC に不具合を確認し、03:10 UTC に発行を停止し、05:22 UTC に修正を配備してから発行を再開したと述べた [1]。

この時系列は重要である。認証局の説明責任は「コードを修正した」という一文だけでは証明できない。影響を受けた可能性のある証明書を特定し、購読者に通知し、置き換えを可能にし、失効を完了する必要がある。公開記録は欠陥の特定、発行経路の修正、証明書ライフサイクルの整理を含んでいた [1]。

CAA は DNS の制御である

RFC 8659 は、CAA をドメイン保有者が認可する認証局を指定する DNS レコードと位置付け、意図しない証明書誤発行のリスクを下げる追加制御だと説明している [2]。したがって CAA は、ドメイン運用者が公開する DNS 状態と、認証局の発行判断との境界である。

リスクと説明責任の観点では、証明書ブランドよりも運用権限の連鎖が重要である。ドメイン所有者が CAA を公開し、DNS 基盤が認証局から見える状態を返し、認証局ソフトウェアがその状態を解釈し、購読者の自動化が大規模な更新を期待する。これらを単に「検証済み」とまとめると、証拠の境界が弱くなる。

ディレクトリ上の境界

この記事の直接の対象は、公式情報に記載された Let's Encrypt と ISRG サービスである。entity:internet-society は本番に存在する公開済みエンティティであり、過去の Let's Encrypt 証明書信頼記事でも使われているため、ディレクトリ上の結合として用いる。これは Internet Society が Boulder の技術判断を行ったという意味ではない。直接の ISRG エンティティが必須なら、この候補は発行前に停止すべきである。

必要な証拠

防御可能な終結には、どの名前が新しい CAA 確認を必要としたか、どの DNS 応答を使ったか、どのソフトウェア経路が判断したか、どの証明書が対象になったか、購読者にどう通知したか、再発防止をどう検査したかが必要である。これがなければ、公的な信頼鎖の中で修正は私的な主張にとどまる。

Sources

  1. https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591
  2. https://www.rfc-editor.org/rfc/rfc8659
  3. https://letsencrypt.org/about/