PKI（公開鍵基盤）

読み：ぴーけーあい　／　英語表記：Public Key Infrastructure

セキュリティ

公開鍵とその所有者の対応を電子証明書で確認できるようにするための基盤である。認証局による証明書の発行を中心に、証明書の検証・更新・失効と鍵の管理を組み合わせ、公開鍵を用いた認証や電子署名を支える。

イマシルちゃんの解説

相手から公開鍵を受け取っても、それが本当に接続したい相手のものかは、鍵だけでは分からないよ。
途中で攻撃者の鍵にすり替えられると、偽物を本物だと思って通信してしまうかもしれないんだ。
そこで使うのが、公開鍵と持ち主の対応を確認できるようにするPKIという基盤だよ。
証明書を発行する機関であるCAが、確認した内容に電子署名を付けるんだ。
受け取った側は、あらかじめ信頼しているCAにつながるかを調べるよ。
証明書の期限や取り消しも管理することで、安心して鍵を使えるように支えるんだ。

より深い解説

公開鍵が本物かという問題

公開鍵暗号では公開鍵と秘密鍵の組を使う。しかし暗号方式が正しくても、受け取った公開鍵が攻撃者のものなら、意図した相手の認証にはならない。鍵の数学的な性質とは別に「この鍵を誰に結び付けてよいか」を確認する必要がある。

PKIはPublic Key Infrastructureの略であり、その対応を扱う仕組み全体である。代表的な構成ではCA（Certification Authority）が電子証明書を発行し、証明書の内容に電子署名を付ける。利用者は発行者の公開鍵で署名を検証する。

ここでCAが示すのは、発行時の確認方針に基づく鍵と対象の対応である。証明書があるだけで、そのWebサイトの商取引や掲載内容まで安全だと保証されるわけではない。X.509証明書を用いるインターネットPKIの基本構成はRFC 5280に定められている。

発行する側と使う側の分担

証明書を発行するには、申請を受け付けて確認する仕事と、その結果に署名する仕事が必要になる。これらは同じ組織内で行うことも、役割を分けることもある。

役割	主に担当すること
CA	確認済みの内容から証明書を発行し、証明書の状態を管理する
`RA`（Registration Authority：登録局）	CAから委ねられた申請者の確認や登録業務を行う
証明書の対象となる利用者・サーバ	自分の秘密鍵を管理し、発行された証明書を利用する
証明書を信頼する側	信頼できる発行元か、目的に合うか、期限や失効状態に問題がないかを検証する

証明書や失効情報を配布するリポジトリも必要になる。証明書は公開してよい情報を含む一方、対応する秘密鍵は保護しなければならない。証明書を取り出せる場所と、秘密鍵を保管する場所は同じ役割ではない。

確認の厳しさや利用条件を定める文書をCP（Certificate Policy：証明書ポリシー）、実際の運用方法を説明する文書をCPS（Certification Practice Statement：認証局運用規程）と呼ぶ。機器を設置するだけでなく、誰に何を確認して発行するかまで決めて初めて運用できる。RFC 3647はこうした運用方針の枠組みを扱う。

鍵の作成から証明書の発行まで

Webサーバの管理者が鍵ペアを作り、証明書を申請する例を考える。

管理者は公開鍵と秘密鍵を生成し、秘密鍵をサーバや専用の保管装置で保護する。
公開鍵や申請する名前を含むCSR（Certificate Signing Request：証明書署名要求）を作る。PKCS #10形式では、対応する秘密鍵で要求内容に署名する。
CA側が申請の署名を検証し、発行方針に従って対象のドメインを管理する権限などを確認する。
CAが証明書に署名して発行する。管理者は対応する秘密鍵と組み合わせてサービスへ設定する。

申請の署名を検証できることと、申請されたドメイン名の正当な管理者であることは別の確認である。自分で作った鍵を使って署名できても、他人のドメインを名乗ってよい根拠にはならない。

この例で秘密鍵を申請書へ入れてCAに送る必要はない。発行された証明書と秘密鍵が対応しなければ、サーバはその証明書を使った認証処理を行えない。要求形式はRFC 2986、ドメインの管理権限の確認と発行を自動化する流れはRFC 8555で確認できる。

信頼の連鎖をたどる

実際には、すべてのサーバ証明書を一つの最上位CAが直接発行するとは限らない。ルートCAが中間CAの証明書を発行し、中間CAがサーバ証明書を発行する構成がある。こうして発行者の署名を順に検証できる関係を証明書チェーンと呼ぶ。

ただし、署名がつながっていれば誰でも信頼できるわけではない。攻撃者も自分のCAを作って証明書を発行できる。検証の出発点として、利用者側が事前に信頼した公開鍵などの情報が必要になる。これをトラストアンカーと呼び、一般的な環境ではOSやブラウザが持つルート証明書などがその役割を担う。

ルート証明書が自己署名であることは、それだけで信頼できる理由にはならない。自己署名は自分の鍵で署名したという性質にすぎず、信頼するかどうかは配布・登録の方針で決まる。RFC 5914は信頼の起点となる情報を扱う。

社内用のプライベートCAなら、管理する端末へ信頼の起点を配布できる。その証明書を持たない社外端末では同じ信頼関係が成立しない。一方、公に利用されるCAはブラウザなどの採用方針に従って広く信頼される。どちらも同じ暗号処理を使い得るが、誰が最初の信頼を設定するかが異なる。

接続先と証明書を照合する

署名の検証に成功しても、その証明書が今接続したい相手のものとは限らない。例えば portal.example.com へ接続したのに、別のドメイン用の正しい証明書が返った場合は名前が一致しない。

TLSのサーバ名確認では、証明書のSAN（Subject Alternative Name：サブジェクト代替名）に記載された名前と、接続時に期待している名前を照合する。DNS名ならdNSName、IPアドレスならiPAddressという種類を区別する。現行のRFC 9525は、この拡張領域を使った照合を規定している。

実際の検証では次の条件を組み合わせる。どれか一つだけを確認して終えてはいけない。

観点	確認する内容
発行元	証明書の署名を検証でき、信頼の起点へつながるか
時間	現在時刻が有効期間内にあるか
名前	接続先として期待するDNS名やIPアドレスと一致するか
用途と制約	Key Usage・Extended Key UsageやCAの制約に適合するか
失効状態	取り消された証明書ではないかを運用方針に従って確認できるか

Key Usageは署名などの鍵の使い道を示し、Extended Key Usageはサーバ認証やクライアント認証などの利用目的を示す。CA用の証明書かどうかを示すBasic Constraintsもある。有効期間内の証明書でも、サーバ認証に使えない用途ならその接続に採用できない。

証明書を持つことと秘密鍵を持つこと

電子証明書は他人へ渡すための情報なので、正しい証明書のコピーを入手しただけでは本人と証明できない。通信相手が、それに対応する秘密鍵を実際に使えることも確認する必要がある。

例えば証明書を使うTLS 1.3の認証では、サーバがCertificateVerifyメッセージでハンドシェイクに関連する情報へ署名する。クライアントは証明書内の公開鍵で検証し、接続中の相手が秘密鍵を持つことを確認する。証明書に付いたCAの署名と、接続時にサーバが作る署名は、誰が何に署名したかが異なる。RFC 8446の認証処理にこの違いが現れる。

また、PKI自体がアプリケーションデータを暗号化して運ぶわけではない。TLSなどの通信プロトコルが、証明書を使った認証と鍵共有を組み合わせて通信を保護する。PKIと暗号化通信を同じ技術として扱わないことが大切である。

有効期間の途中で取り消す

秘密鍵が漏えいした場合や、証明書の記載内容に問題が見つかった場合には、有効期限を待たずに証明書を失効させる。元の証明書を回収して書き換えるのではなく、発行者側が失効状態を知らせる。

代表的な仕組みは二つある。CRL（Certificate Revocation List）は、失効した証明書のシリアル番号などをまとめた署名付きリストを配布する方式である。OCSP（Online Certificate Status Protocol）は、対象となる証明書の状態を問い合わせるためのプロトコルである。

問い合わせの結果が good でも、接続先の名前や証明書チェーンまで正しいと保証されるわけではない。状態確認は検証全体の一部であり、応答の署名と鮮度も調べる必要がある。応答の意味はRFC 6960に定められている。

状態確認先へ接続できないときに、通信を止めるか継続するかは製品と運用方針によって異なる。したがって、失効情報の配布先を利用端末から到達できる場所へ置くことも設計の一部である。サーバが取得した署名付きの状態情報をTLS接続時に添える、OCSPステープリングという方法もある。認証のたびに端末から確認先へ問い合わせる負担を減らせるが、添える情報の更新は必要になる。

発行後も管理を続ける

証明書の期限切れは、暗号方式が破られなくても通信を止める。発行時には利用箇所と担当者を記録し、更新する時期だけでなく、更新後にサービスが新しい証明書を提示しているかまで確認する。ロードバランサでTLSを終端する構成なら、その装置側の設定も対象になる。

ACMEは証明書の申請や発行などを自動化するプロトコルである。自動更新を採用しても、確認用の通信が遮断された場合や認証情報が期限切れになった場合には失敗し得る。更新処理の実行結果と、実際の接続で見える証明書の両方を監視する。

CAの秘密鍵が漏えいすると、不正な証明書の発行など広い範囲へ影響する。専用装置のHSM（Hardware Security Module）で鍵を保護する構成や、最上位CAを通常はネットワークから切り離す構成を検討する。証明書の配布先・失効情報・鍵保護を含む設計項目はMicrosoftのPKI設計資料に整理されている。

障害や設計問題をどう考えるか

例えば「新しい端末だけが社内サーバを信頼できない」という現象では、サーバ証明書の期限だけでなく、社内CAの証明書が端末へ配布されているかを調べる。「一部の端末だけ失敗する」なら、中間証明書を以前の通信で保存していた端末だけ成功している可能性もある。サーバが必要な中間証明書を提示できているかを確認する。

「秘密鍵の漏えい後に証明書を更新したのに、不正利用への対処が終わらない」という条件なら、更新と失効の違いを考える。新しい証明書を置くだけでは古い証明書を有効期間の途中で取り消したことにならない。古い鍵を使う証明書の失効と、失効情報の配布まで必要になる。

障害対応では、発行・配布・提示・検証・失効確認のどの段階に問題があるかを分ける。警告表示を無効にして接続できたとしても、公開鍵と接続先の対応を確認する仕事を省略しただけなら、原因を解決したことにはならない。