証明書チェーン

チェーンが存在するのは、最も価値の高い鍵をオフラインのままにしておけるようにするためです。ルート証明書は少数の中間証明書に署名したあと金庫に戻り、中間証明書がサーバーへの署名という日常的な作業を担います。検証は逆方向にたどり、渡された証明書から、端末がすでに持っていたものへと進みます。リンクが1つでも欠けていたり、有効期限が切れていたり、認識できなかったりすると、検証は失敗します。

仕組み

典型的なチェーンは3つの位置からなり、サーバーが送信するのはそのうち2つだけです。

最下位にあるのはリーフ証明書で、特定のドメイン名の集合に対して発行されます。その上に1つ以上の中間証明書が位置し、その目的はルート証明書を日常的な使用から隔離することです。最上位にあるのはルート証明書で、自己署名されており、利用者がそのサイトを訪れるはるか前から端末のトラストストアに入っています。サーバーはリーフ証明書と中間証明書を送信します。ルート証明書を送ってもバイト数が増えるだけで何も証明できないからです。ルート証明書は、利用者がすでに持っている場合にのみ意味を持ちます。

検証は一覧をまっすぐ上へたどるものではありません。1つの証明書が複数の発行者によって署名されることがあり、これはクロス署名と呼ばれる慣行で、クライアントは複数の候補パスに直面し、自分が保持するルート証明書で終わるパスを1つ見つけなければならないことがあります。同じウェブサイトが新しいノートパソコンでは読み込まれ、古いスマートフォンでは失敗するのはこのためです。パスが異なるのは、トラストストアが異なるからです。

最も明快な例は今もLet's Encryptの移行です。同社自身のルート証明書であるISRG Root X1は、X1をまだ追加していない端末でもパスを構築できるよう、古いDST Root CA X3によってクロス署名されていました。DST Root CA X3は2021年9月30日に有効期限が切れました。X1を保持する端末は誰も気づかないうちにパスを切り替えましたが、7.1.1より古いAndroidのバージョンや複数のレガシーなTLSライブラリは切り替えず、接続は世界中でひとつの午後のうちに途切れました。何もハッキングされておらず、鍵も漏れていませんでした。ある日付が過ぎていたのです。

どこで見られるか

チェーンの問題は仰々しく見えますが、ほとんどはありふれたものです。

最もよくあるサーバーの設定ミスは、中間証明書の入れ忘れです。ブラウザは、以前の訪問時の中間証明書をキャッシュしたり、証明書内のURLから取得したりして、しばしばこれを覆い隠します。そのためサイトは管理者には動作し、コマンドラインツールやスマートフォンでは失敗し、この設定ミスは追跡するのが記憶に残るほど厄介なバグになります。

ビットコインを管理する人にとって、チェーンエラーの有益な読み方は診断です。取引所がある端末では証明書エラーを出し、別の端末では動作する場合、違いはほとんど常に端末側にあります。システム時計の誤り、新しいルート証明書を受け取れないほど古いオペレーティングシステム、あるいは接続に割り込むアンチウイルス製品です。攻撃を想定する前に端末を修正し、警告をクリックして先に進み、入ろうとすることは決してしないでください。

ハードウェアウォレットのアテステーションは、はるかに小さい規模で同じ形を使います。ベンダーのルート証明書、場合によっては1つの中間証明書、そして端末自体に保持された証明書です。

証明書チェーンvsルート証明書

チェーンはパスであり、ルート証明書はそのパスが終わらなければならない場所です。チェーン内のルート証明書以外のすべての証明書は、その上の何かが署名したからこそ信頼されるのに対し、ルート証明書は端末に同梱されている一覧に載っているから信頼され、自分自身に署名します。したがってその一覧にルート証明書を追加することは、他のどの証明書を受け入れるよりもはるかに大きな判断であり、企業ネットワークや通信傍受ツールが求めているのはまさにそれなのです。