電子証明書とPKIとは ― 証明書チェーンとCRL・OCSP

HTTPSのサイトを開くたびに、ブラウザはサーバの電子証明書を確かめています。電子証明書は、公開鍵とその持ち主の結び付きを、認証局（CA）がデジタル署名で保証したデータです。

PKI（Public Key Infrastructure）は、この証明書の発行・検証・失効の仕組み全体を指します。証明書が要るのは、公開鍵が誰にでも作れて、誰にでも配れるからです。「これは example.com のサーバの公開鍵です」と名乗られても、鍵だけでは本物かどうか確かめられません。

そこで、信頼できる第三者のCAが「この公開鍵は example.com のものだ」と署名します。この仕組みがないと、攻撃者が自分の公開鍵を本物のサーバのものだと偽る中間者攻撃を防げません。

電子証明書は、デジタル証明書や公開鍵証明書とも呼びます。証明書の仕様RFC 5280は、利用者とCAのほかにもPKIの構成要素を挙げています。CAの仕事の一部を任される登録局（RA）や、証明書と失効の情報を置く場所です。

RFC 5280が定めるX.509形式の証明書は、中身が決まった項目に分かれています。検証では、次の表の項目を使います。

CAが署名するのは、表のうち署名を除いた項目をまとめたデータです。署名によって、CAは公開鍵と持ち主の結び付きを保証します。署名の作り方と検証の仕組みは、暗号の基礎の記事で説明したデジタル署名と同じです。

RSAやECDSAで署名する場合、CAはこの項目のデータからハッシュ値を計算します。そのハッシュ値をもとに、秘密鍵で署名します。ハッシュ値の性質は、ハッシュ関数の記事で説明しています。共通鍵で作るMACとデジタル署名の違いは、MACとデジタル署名の違いの記事で比べています。

証明書は、CAの証明書と、CAではない持ち主の証明書に分かれます。サーバ証明書とクライアント証明書は、CAではない持ち主の証明書です。CAの証明書のうち、チェーンの出発点がルート証明書で、途中に入るのが中間CA証明書です。

ルートとサーバ証明書の間に、中間CAが何段入るかは決まっていません。RFC 5280は、0個以上と書いています。中間CA証明書を使う形では、ルートの下に中間CAがあり、中間CAがサーバ証明書に署名します。

検証の出発点として信頼するCAを、トラストアンカー（信頼の基点）と呼びます。最上位のCAも、利用者自身の証明書を発行したCAも、トラストアンカーに選べます。どれを選ぶかは、方針で決めます。

クライアント証明書は、利用者や端末の側を確かめるときに使います。RADIUSの記事で説明したEAP-TLSでは、サーバと端末の両方が証明書を出し合います。IPsecの記事で説明したとおり、IPsecにも、証明書で相手を確かめる方式があります。

利用者の確認に公開鍵を使う仕組みには、パスキーもあります。パスキーでは証明書を発行せず、登録のときに公開鍵をサイトへ直接渡します。

証明書チェーンは、サーバ証明書から信頼の基点まで、発行者と主体者でつながる証明書の並びです。RFC 5280では、証明書パスと呼びます。ブラウザが最初から持っているCAの公開鍵は、限られています。そのため、チェーンをたどって公開鍵の持ち主を確かめます。

検証で確かめる主なことは、次のとおりです。

• 並びの最初の証明書を、トラストアンカーが発行している
• 各証明書の発行者が、一つ上の段の証明書の主体者になっている
• 各証明書の署名を、一つ上の段の公開鍵で検証できる
• 各証明書が、いまの時刻で有効期間の内にあり、失効していない

RFC 5280は、結果が同じなら手順は問わないとしています。次の図は、サーバ証明書から基点へたどる順に、検証を1段ずつ示します。

途中のどこかで失敗すると、その証明書は信頼されません。たとえば、自分で署名しただけの自己署名証明書をサーバ証明書に使ったとします。この証明書は信頼の基点の一覧にないため、検証に通りません。TLSの接続の中で、この検証がどこで行われるかはHTTPSの記事にあります。

検証に失敗したときにブラウザが出す警告の読み方は、SSL/TLSの記事にまとめています。

失効は、有効期間の途中で、CAが証明書を使えない扱いにすることです。理由の例は、秘密鍵の漏えいやその疑いです。持ち主の名前の変更や、持ち主とCAの関係の変化も理由になります。従業員が退職した場合は、関係の変化にあたります。

期限切れとは別の話で、期限が来る前に使えなくします。そのため、署名とは別に、失効しているかを確かめる手段が必要です。CAには、自分が発行した証明書の失効状態を示す責任があります。方法の代表が、CRLとOCSPです。

CRL：失効した番号の一覧を取り寄せる

CRL（Certificate Revocation List）は、CAが署名して公開する、失効した証明書の一覧です。一覧に載るのは、証明書のシリアル番号と失効した日です。一覧には、発行した日時と、次の一覧を出す期限の日時が付きます。

ブラウザは、一覧を取り寄せて、確かめたい証明書のシリアル番号が載っているかを探します。入手先は、証明書のCRL配布点の拡張に書かれています。一覧に署名があるので、信頼できないサーバから受け取っても、改ざんは見抜けます。

弱点は、失効の反映が遅れることです。一覧は毎時、毎日、毎週のように定期的に出されます。失効を報告した直後は、次の一覧が出るまで、確かめる側に届きません。

OCSP：1枚ずつ問い合わせる

OCSP（Online Certificate Status Protocol）は、証明書の失効状態を、その場で問い合わせるプロトコルです。ブラウザは、確かめたい証明書の識別情報をOCSPレスポンダに送ります。答えが来るまで、ブラウザはその証明書の受け入れを保留します。

答えには署名が付き、状態は3つのどれかです。goodは、いま失効していないことを示します。revokedは失効済み、unknownはレスポンダがその証明書を知らないことを示します。入手先は、証明書の権限情報アクセスの拡張に書かれていて、HTTPで問い合わせられます。

OCSPは、失効の報告から配布までの遅れを大きく減らせます。一方で、確かめる側は、答えるサービスを信頼する必要があります。unknownが返ったときは、CRLなど別の情報源を試すかどうかを、ブラウザ側で決められます。

• RFC 5280（X.509証明書とCRLのプロファイル。証明書の項目、証明書パスの検証、CRL）
• RFC 6960（OCSPの要求と応答）