SC科目B（午後）のPKI・CA・サーバ証明書・証明書チェーンとCSR

ブラウザでhttps://pay.exampleを開いたとき、何を根拠に接続先を信じるのでしょうか。この記事では架空の支払システムを一貫した例に、鍵の生成、CSR、CAによる発行、証明書チェーン、TLSでのサーバ認証、更新と事故対応まで追います。

科目Bでは『証明書がある』だけで安全と答えられません。どの鍵で何に署名したか、どこに信頼が置かれたか、SANの名前や用途が合うか、サーバが秘密鍵を持つかを分けて判断します。pay.example、CA名、番号、日付、証明書の表示はすべて教材用の架空例です。

1. PKIと7つの中心用語

Public Key Infrastructure（PKI）は、公開鍵を主体の名前へ結び付け、発行・配布・検証・失効を運用する仕組みです。公開鍵暗号だけでは『この公開鍵がpay.exampleのものか』は分かりません。その結び付きを証明書とCAの信頼関係で確かめます。

この例のR1は架空のルートで、読者の実際のブラウザに入っているという意味ではありません。信頼ストアにないR1へ署名がつながっても、通常の公開Web接続では自動的に信頼できません。

図の矢印は認証局の階層を表します。R1の自己署名を数学的に確かめるだけでは、R1を信頼する根拠になりません。R1を事前に信頼すると決めたクライアントの設定が信頼の出発点です。

この三つの秘密鍵は別々です。CSRの署名が有効でもCAの署名はまだなく、CAの署名が有効でも接続中のサーバの秘密鍵所持はまだ分かりません。どの検証結果かを記述式の答案で明示します。

2. 鍵の生成からCSRと発行まで

運用担当者はpay.example用の鍵ペアを生成します。公開鍵はCSRと証明書に載せ、秘密鍵はサービス管理範囲で保護します。秘密鍵をCAへ送る必要はありません。鍵が漏れたら、証明書の有効期間内でも第三者がその鍵を使い得ます。

2-1. CSRに入るもの、入らないもの

PKCS #10形式のCSRは、subject、公開鍵、任意の属性を含む要求本体と、その要求本体に対する申請者の署名でできています。SANは拡張要求として含める構成があります。CSRの署名は対応する秘密鍵の所持を示しますが、ドメインの管理権限や法人の実在を単独では証明しません。

申請対象: https://pay.example
CSRのsubject: CN=pay.example
CSRの公開鍵: K-pay-public
要求するSAN: DNS:pay.example
CSR署名: K-pay-privateで要求本体へ署名

CSRに含めないもの:
  K-pay-private、CAの署名、発行済み証明書の
  シリアル番号・有効期間

ここでのCNは申請書内の名前の例です。後でブラウザが接続先のDNS名を照合する根拠は、発行された証明書のsubjectAltName（SAN）です。CNの文字列だけでWebサイト名の検証を通す設計は避けます。

2-2. CAは何を審査し、何を発行するか

公開Web向けCAは、申請されたDNS名について認められた手段で管理権限を確認し、CSRの公開鍵・署名と発行ポリシーを確認します。発行方式がDVならドメイン管理権限の確認が中心です。組織の属性を証明する方式では、それに応じた別の審査も必要です。

CAは自分の秘密鍵で、公開鍵と名前、有効期間、用途などを結び付けたサーバ証明書へ署名します。I1が発行するこの例では、pay.exampleの証明書にI1の署名があります。I1の証明書にはR1の署名があり、R1はブラウザ側の信頼ストアにあります。

図のDNS確認はCAの審査の一例で、DNSに値があるというだけでは審査完了とは言えません。CAの指定した方法・対象名・期限に従った確認が要ります。またCSRに対する申請者の署名と、発行済み証明書に対するCAの署名は別物です。

2-3. CSR、自己署名証明書、発行済み証明書の違い

CSRは証明書の元になる申請ですが、CAは要求されたSANや有効期間を無審査で確定しません。最終的に何が発行されたかは、CSRではなく受け取った証明書を開いて確認します。CSRを作った同じ秘密鍵に対応する公開鍵が発行済みLeafへ入っているかも確認します。

3. 証明書の項目と署名の関係

次はpay.example用の発行済み証明書を人が読める形にした架空の抜粋です。実際の証明書はASN.1 DERで符号化され、PEMはそれをBase64で表した形式です。この表示は署名バイト列や実際の鍵を省いています。

Leaf: pay.example
  subject=CN=pay.example
  issuer=Example Issuing CA I1
  serialNumber=01AB
  notBefore=2026-09-01T00:00:00Z
  notAfter=2026-11-01T00:00:00Z
  SAN=DNS:pay.example
  BasicConstraints=CA:FALSE
  KeyUsage=digitalSignature
  ExtendedKeyUsage=serverAuth
  SPKI=K-pay-public
  signature=Sign(K-I1-private, Leaf内容)

Intermediate: Example Issuing CA I1
  issuer=Example Root CA R1
  BasicConstraints=CA:TRUE,pathLenConstraint:0
  KeyUsage=keyCertSign,cRLSign
  signature=Sign(K-R1-private, I1内容)

CAが署名したのは『この公開鍵を指定した名前・用途へ結び付ける』という証明書の内容です。サーバの秘密鍵そのものをCAが保証したわけではありません。TLS接続時には、サーバがその秘密鍵を今使えることを別に示します。

4. ブラウザは証明書チェーンをどう検証するか

サーバは通常、Leafと必要な中間CA証明書を提示します。ルートR1はクライアントの信頼ストア側にあるため、通常はサーバから送る必要がありません。中間CAを送らない構成では、一部のクライアントが補完できても、別のクライアントでは経路を作れず失敗し得ます。

4-1. TLS 1.3のサーバ認証と二種類の署名

CertificateメッセージでLeafとI1を受け取ったブラウザは、証明書のCA署名と名前・用途・期間を確認します。CertificateVerifyは、サーバがLeafの公開鍵に対応する秘密鍵でTLSハンドシェイクに署名する処理です。CA署名の検証だけでは、目の前のサーバが秘密鍵を持つとはまだ分かりません。

ClientHelloのSNIは、同じサーバ上でどの名前の証明書を選ぶかの手掛かりです。SNIにpay.exampleと書いたこと自体は認証ではありません。ブラウザはURLから期待したpay.exampleとLeafのSANを自分で照合します。

4-2. 経路検証と名前照合のチェック項目

1. Leaf、I1、信頼アンカーR1へ至る候補経路を組む。AIAで中間証明書を取得できる実装もあるが、取得できる前提でサーバ側の中間CA送信を省略しない。

2. LeafのissuerとI1のsubject、I1のissuerとR1の識別情報を対応させ、Leafの署名をI1公開鍵、I1の署名をR1公開鍵で検証する。名前やSKI・AKIの一致だけでは署名検証にならない。

3. 最終的に到達するR1がクライアントの信頼ストアで信頼アンカーとして許可されているか確認する。自己署名というだけの別のR1は受け入れない。

4. LeafとI1の有効期間、受け入れる署名方式、重要な拡張の処理、I1のCA:TRUE・keyCertSign、pathLenConstraintなどの経路制約を確認する。

5. LeafのSANのDNS:pay.exampleと、URLから得た期待名pay.exampleを照合する。CNだけの一致を使わず、別ドメインや不適切なワイルドカードを許さない。

6. LeafがTLSサーバ認証に使える用途か確認する。EKUにserverAuthがある例ではそれを要求し、KeyUsageもTLSでの使い方と整合させる。

7. 失効状態の確認を、クライアント・組織が定めたOCSP・CRLなどの方式と失敗時方針に従って行う。応答取得失敗を常に『有効』と同一視しない。

8. CertificateVerifyとFinishedを確認し、サーバがLeafの秘密鍵を使えることとTLSのハンドシェイクが改変されていないことを確かめてから通信を続ける。

実際のクライアント内部では検証の順序や経路構築が異なります。上の項目は調査時の確認表です。別の交差署名経路がある場合、同じLeafから複数の候補経路を組めますが、最終的にはそのクライアントが許可する信頼アンカーへ達する必要があります。

信頼アンカーは、通常はローカルの信頼ストアにある公開鍵と名前などを入力として扱います。サーバから届いた自己署名ルート証明書をそのまま信頼ストアへ追加して検証を通す方法は、攻撃者が任意のルートを提示できる状態を作ります。企業内PKIなら、管理者が別途検証して配布した社内ルートだけを所定の用途へ信頼させます。

4-3. SAN、ワイルドカード、IPアドレスを混同しない

ワイルドカード証明書は管理する名前の範囲を広げますが、秘密鍵が漏れればその範囲で影響が広がります。証明書に許された名前と、アプリが提供してよいサービスの範囲は別です。

4-4. 何が証明され、何は証明されないか

5. どの設定ミスがどの攻撃につながるか

証明書関連の攻撃は、攻撃者が通信を中継できるか、別の鍵を持つか、クライアントの設定を変えられるかで成立条件が異なります。以下では『条件→誤実装→影響→対策』を分けます。

5-1. チェーン検証を無効化する

攻撃者がネットワーク上で接続を中継でき、クライアントが証明書エラーを無視して通信する設定なら、攻撃者は自分で作った自己署名証明書を見せられます。暗号化された接続自体は成立しても、相手の認証が失われ、入力内容を攻撃者に渡し得ます。信頼アンカーまでの経路と署名の検証を省かないことが対策です。

5-2. ホスト名照合を省く

攻撃者が別ドメインother.exampleの正規証明書とその秘密鍵を持ち、pay.exampleへの通信を中継できるとします。クライアントがCA署名だけ見てSANとURLを照合しなければ、別サイト用の有効な証明書で偽サーバを受け入れます。pay.exampleを期待名としてDNS:pay.exampleへ照合します。

5-3. 中間CAの資格・用途を見ない

攻撃者が通常の終端証明書とその秘密鍵を持ち、下位のpay.example証明書を勝手に作っても、その終端証明書にはCAとして発行する資格がありません。クライアントがBasicConstraintsのCA:TRUEやkeyCertSignを無視すると、不正な経路を受け入れ得ます。署名が計算上正しくても、発行権限と経路制約を確認します。

5-4. 信頼ストアを勝手に変えられる

攻撃者が端末の管理権限を得て自分のルートCAを信頼ストアへ追加できれば、その鍵で作るpay.example用証明書は『信頼済みルートへの経路』に見えます。この場合、経路検証だけでは改変済みの信頼設定を見抜けません。ルート追加の権限を制御し、配布設定と端末変更履歴を調べます。

5-5. 秘密鍵が漏れる、CAが誤発行する

K-pay-privateが漏れた疑いがあれば、攻撃者は期限内のLeafと対応する鍵でサーバを偽装し得ます。CAによる別鍵の誤発行では、被害者の本物の秘密鍵が漏れていなくても偽サーバに使える証明書が成立し得ます。前者は鍵交換と失効、後者はCAへの調査・失効依頼と発行監視が必要です。

Certificate Transparency（CT）の公開記録は、公開Web用証明書の予期しない発行を見つける材料になります。ただしCTに記録されたというだけで発行が正当とは言えず、CTは証明書を失効させる機能でもありません。

5-6. DNSの行き先だけを変える

攻撃者がpay.exampleのDNS応答や接続先IPだけを変えて自分のサーバへ誘導しても、正しく検証するクライアントへはpay.exampleに合う有効な証明書と秘密鍵を提示する必要があります。DNS改ざんだけでTLSの名前確認を突破したとは言えません。鍵漏えい、CAの誤発行、信頼設定の改変、検証無効化の有無を別に調べます。

ただし攻撃者がCAのドメイン確認に使うDNSやWebの応答を操作できれば、別鍵でpay.exampleの証明書を誤って発行させる経路も考えられます。発行申請の履歴とCTの記録、DNS変更履歴を照合し、不要な証明書はCAへ失効を依頼します。

これらの表示だけでは攻撃と断定できません。更新漏れ、時刻ずれ、証明書の配布ミスも同じ症状を作ります。調査では提示された証明書の内容、クライアントの信頼設定、サーバごとの配布状態を照合します。

6. 更新・失効・復旧で決めること

有効期限が近づいたら、ドメイン確認の更新、CSRと鍵の準備、Leafと中間CAの正しい配布、複数サーバへの展開を計画します。新しい証明書を置いただけでは十分ではなく、実際の接続でSAN、チェーン、TLSでの秘密鍵利用を確認します。旧証明書と新証明書が重なる期間も管理します。

OCSPは証明書の状態を問い合わせる仕組み、CRLはCAが公開する失効リストです。失効状態の取扱いはクライアント・ブラウザ・企業方針で異なります。OCSPへの接続失敗を『失効していない証明書』と同じ証拠として扱えません。失効が広がるまでの時間も考えます。

OCSP応答のgoodは、その応答において失効と記録されていないという状態であり、ドメインや秘密鍵が安全だという新たな証明ではありません。revokedは失効、unknownは応答者が対象を特定できない状態です。応答の署名、対象の発行者・シリアル番号、有効な時刻も確認します。

OCSP staplingを使うサーバは、取得したOCSP応答をTLS接続時に添付できます。ただし全クライアントが常に同じ失効確認を行うわけではありません。事故対応では、失効申請だけで利用停止が全端末へ即時に広がったと断定せず、鍵交換と配布状況も確認します。

秘密鍵漏えい時は、旧鍵の利用を止めてCAへ旧証明書の失効を速やかに申請します。新しい鍵ペアを安全な場所で生成し、新しいCSRで発行した証明書へサーバを切り替えます。漏れた鍵・バックアップ・他サービスでの再利用、関連するセッションと通信の影響も調べます。鍵を再利用した更新では漏えい問題を解消できません。

再開前は、清浄なクライアントでpay.exampleへの正常接続、別名・未知ルート・旧証明書の拒否、I1の同送を試します。失効確認の結果はクライアントごとに差があるため、その方針も明示します。漏えい後に作られた不審なセッションや申請を残さないことも確認します。

TLS 1.3で前方秘匿性が成立した過去通信は、長期サーバ鍵の漏えいだけで直ちに復号できるとは限りません。一方、攻撃者が鍵を悪用できる間の新しい接続やサーバ侵害に伴うセッション窃取は別の問題です。『鍵が漏れたので過去の全通信が必ず復号された』と断定しません。

7. 科目B（午後）の記述演習

各問は、観測した条件から言えること、足りない証拠、適用する対策を区別して答えてください。

演習1：CSRの署名

条件：pay.exampleと書かれたCSRの署名は、そのCSR内の公開鍵で検証できた。問い：何が確認でき、CAは次に何を調べるか。

解答：対応する秘密鍵の所持と要求本体の整合性を確認できます。CAは別にpay.exampleの管理権限と発行方針を確認します。誤答『CSR署名があるのでドメイン所有者』は、鍵所持とドメイン権限を混同しています。

演習2：中間CAの欠落

条件：サーバはLeafだけ送り、I1を送らない。ある端末は接続でき、別端末はunknown issuerになる。問い：何を直すか。

解答：サーバが正しいI1証明書をLeafとともに提示し、各端末でR1への経路を確認します。誤答『全端末へLeafを信頼ルートとして追加』は信頼境界を広げます。

演習3：署名は正しいがSANが違う

条件：I1までの署名は正しいが、LeafのSANはDNS:other.exampleだけ。URLはhttps://pay.example。問い：受理できるか。

解答：受理できません。期待するDNS:pay.exampleがSANにありません。CNやCA署名だけで代用しません。誤答『信頼CAが署名したので正しいサイト』は宛先の名前照合を欠きます。

演習4：Leafが下位証明書を発行

条件：攻撃者は自分のLeaf秘密鍵でpay.example用の下位証明書へ署名した。LeafにはCA:FALSEが付く。問い：どの検証で止めるか。

解答：発行者として使われたLeafのBasicConstraintsとKeyUsageを調べ、CA:TRUEとkeyCertSignを満たさない経路を拒否します。誤答『署名が計算できれば通す』は発行権限を見ていません。

演習5：ルートCAが追加された

条件：一台の端末だけ攻撃者のルートCAが信頼ストアに増え、その端末では偽pay.exampleへの接続が成功する。問い：何を調査するか。

解答：信頼ストア変更履歴、管理権限、配布ポリシー、提示証明書と接続先を確認し、不正ルートを除去します。誤答『経路検証が成功したので問題ない』は信頼アンカー自体の改変を見落とします。

演習6：秘密鍵の漏えい

条件：K-pay-privateのコピーが不明な共有領域で見つかった。証明書の期限はまだ先。問い：再開に必要な対応を答える。

解答：新鍵と新CSRで再発行・配布し、旧証明書の失効を申請します。鍵の配置先、悪用された接続、関連セッションを調べ、正常・拒否接続を試します。誤答『期限まで使える』は鍵漏えいを無視しています。

8. 一次資料

RFC 5280：X.509証明書と証明書経路検証

RFC 2986：PKCS #10 CSR

RFC 9525：TLSサービス名とSANの照合

RFC 8446：TLS 1.3 CertificateとCertificateVerify

RFC 6960：OCSP

RFC 9162：Certificate Transparency

CA/Browser Forum：公開Web向けTLS証明書のBaseline Requirements