中間証明書

認証局は、ルート鍵でウェブサイトの証明書に署名することはありません。認証局は中間証明書に署名し、ルート鍵をオフラインに保管したうえで、中間証明書から発行します。中間証明書は、ルート証明書の有効期間である20年ではなく、数週間で交換できます。サーバーが中間証明書の送信を忘れた場合、ブラウザーはその欠落を覆い隠しますが、より厳格なクライアントは覆い隠さないため、Chromeでは正常に見えるサイトがアプリでは失敗することがあります。

仕組み

中間証明書は、トラストアンカーではない認証局の証明書です。CAをtrueに設定したbasicConstraints拡張を持ち、これによりさらに別の証明書に署名することが許可され、それ自体はルート証明書または別の中間証明書によって署名されています。検証はサーバーの証明書から上方向へたどり、各署名をその1つ上の証明書に含まれる鍵と照合し、ローカルのトラストストアにすでに存在するものに到達した時点で停止します。

発行をこのように分けることで、3つの利点が得られます。ルート鍵は、スクリプト化され立会人のいるセレモニーのときだけ取り出されるオフラインのモジュールに保管されたままになります。侵害された中間証明書は、どの端末のルートストアにも触れることなく失効させ、再発行できるため、被害を限定できます。また、認証局は製品ラインを分離できるため、安価な自動化層での問題が、監査済みの層に及ぶことはありません。

クロス署名は、新しい認証局をそもそも利用可能にするための工夫です。1つの鍵で2つの中間証明書を持てます。1つは自組織のルート証明書によって署名されたもの、もう1つは古い端末にすでに入っている確立されたルート証明書によって署名されたものです。Let's Encryptはこの仕組みに何年も依存していました。ISRG Root X1が、更新の配信が停止されたAndroidのバージョンに含まれていなかったため、IdenTrustによってクロス署名されたチェーンを配信していたのです。この補助手段は、その後ろにあったルート証明書より長く存続しました。そのルート証明書は2021年9月30日に有効期限が切れ、Let's Encryptは2024年6月6日についにクロス署名されたチェーンの配信を停止しました。

チェーンの組み立ては、運用者が間違えやすい部分です。サーバーは自身の証明書と、その上にあるすべての中間証明書を送信し、クライアントがすでに持っているルート証明書の手前で止めるべきです。ブラウザーは、認証局情報アクセス拡張のURLから欠けている証明書を取得したり、キャッシュされたコピーを再利用したりして、送信漏れを隠します。決済ライブラリ、モバイルアプリ、コマンドラインクライアントは通常どちらも行わず、信頼できないチェーンであると報告するだけです。

どこで見られるか

BIP70は中間証明書を決済メッセージ自体に含めていました。pki_dataフィールドにはX509Certificates構造が入っており、その最初の項目は加盟店自身の証明書で、それに続いてルート証明書に到達するために必要な中間証明書が入り、ルート証明書はウォレットがすでに保持していると想定されていたため省略されていました。これはTLSサーバーが送信する順序とまったく同じで、それがプロトコルバッファに移されたものです。

ビットコインの外では、中間証明書は、あるプログラムでは接続が成功し別のプログラムでは失敗するたびに存在を露呈します。APIエンドポイントが取引スクリプトに証明書エラーを返す一方でウェブサイトは正常に読み込まれる取引所は、ほぼ常にチェーンから中間証明書を落としています。ブラウザーの無言の修復作業を行わないツールでテストすることが、ボットに先んじてそれを見つける方法です。

中間証明書vsルート証明書

ルート証明書と中間証明書はどちらも認証局の証明書であり、違いは誰が署名したかと鍵がどこにあるかです。ルート証明書は自己署名であり、その力はベンダーの包含リストから得ています。中間証明書はその上にある署名から力を得ており、つまり発行元の認証局は、どこでもソフトウェアの更新を行うことなく、午後のうちに失効させることができます。日々の運用では、署名のほとんどすべてを中間証明書が行い、ルート証明書はほとんど行いません。その非対称性こそが、この層が存在する理由そのものです。