PKI（公開鍵基盤） - 暗号化全般

PKIとは

PKI（Public Key Infrastructure：公開鍵基盤）は、公開鍵暗号を基盤としたセキュリティインフラストラクチャです。証明書の発行、配布、検証、失効を管理する仕組みで、HTTPS通信、電子署名、メール暗号化など、現代のセキュアな通信の基盤となっています。

PKIが解決しているのは、突き詰めると「見知らぬ相手の公開鍵を、どうやって安全に本人のものだと確認するか」という問題です。対称鍵暗号だけの世界では、通信したい相手ごとに事前共有鍵を安全に配送する必要があり、参加者がn人いればおよそn(n-1)/2組の鍵管理が発生します。公開鍵暗号はこの鍵配送問題を「公開鍵は誰にでも渡してよい」という発想で解決しますが、今度は「その公開鍵は本当に名乗っている本人のものか」という新しい問題（なりすまし・中間者攻撃のリスク）が生まれます。PKIは、信頼された第三者機関（認証局）が公開鍵と身元情報を結びつけて署名することで、この「本人性の証明」を仕組み化したものです。

PKIの主要コンポーネントには、認証局（CA）、登録局（RA）、証明書リポジトリ、証明書失効リスト（CRL）、オンライン証明書状態プロトコル（OCSP）などがあります。ブラウザやOSがHTTPSサイトに鍵マークを表示できるのは、この仕組み全体が裏側で正しく機能しているためです。

PKIの仕組み（信頼の連鎖と検証プロセス）

PKIの動作は、次の4段階の流れで理解すると分かりやすくなります。

1. 鍵ペア生成：サーバーやユーザーが秘密鍵と公開鍵のペアをローカルで生成する（秘密鍵は外部に出さない）
2. CSR（証明書署名要求）の発行：公開鍵と組織名・ドメイン名などの識別情報をまとめ、CSRとしてCAに提出する
3. CAによる審査と署名：CA（またはRA）が申請者の実在性・ドメイン所有権を審査し、問題なければCAの秘密鍵でCSRの内容に署名し証明書を発行する
4. 検証者側での検証：ブラウザ等のクライアントは、証明書に付いたCAの署名を、あらかじめ端末に組み込まれた「信頼されたルート証明書」の公開鍵で検証する

実運用では、ルートCAが直接エンドエンティティ証明書（サーバー証明書など）に署名することはほとんどありません。ルートCAの秘密鍵は普段オフラインで金庫やHSM内に厳重保管し、日常の証明書発行は「中間CA」に委譲します。検証時には、サーバー証明書 → 中間CA証明書 → ルートCA証明書という順に署名を遡って確認する「証明書チェーン（chain of trust）」が形成されます。チェーンのどこか1か所でも署名検証に失敗すれば、ブラウザは「この接続ではプライバシーが保護されません」といった警告を表示します。

鍵長・アルゴリズムの安全性（2026年時点の目安）

証明書に使う公開鍵の強度は、NISTのSP 800-57（鍵管理に関する推奨事項）などを参考に選定するのが実務上の定石です。おおむね次のような水準が目安とされています。

アルゴリズム	2026年時点で推奨される目安の鍵長	備考
RSA	最低2048bit、長期利用は3072bit以上を推奨	1024bitは事実上非推奨・多くのCAが発行停止済み
ECDSA（楕円曲線）	P-256（secp256r1）以上、高セキュリティ要件はP-384	RSA-3072相当の強度をより短い鍵長・高速な演算で実現
ハッシュ関数（署名用）	SHA-256以上	SHA-1は衝突攻撃の実証以降、主要ブラウザ・CAが2017年前後から段階的に廃止
ルートCA鍵	RSA 4096bit または ECDSA P-384	有効期間が長い（10〜25年程度）ため、より高い強度を選ぶのが一般的

実装上の注意点として、鍵長さえ長ければ安全というわけではありません。実務では以下の点も同時に確認するのが定石です。

• 秘密鍵の保護：ファイルとして平文保存せず、HSM（ハードウェアセキュリティモジュール）やクラウドのKMSで保護する
• 乱数生成の質：鍵ペア生成時の乱数生成器（RNG）が暗号論的に安全であることを確認する（脆弱なRNGによる鍵の予測可能性は過去に複数の実例がある）
• 証明書の拡張属性：Basic Constraints、Key Usage、Extended Key Usage、Subject Alternative Name（SAN）などの拡張フィールドを用途に応じて正しく設定する（SAN未設定の証明書は近年の主要ブラウザで警告・拒否される）
• 署名アルゴリズムの選定：MD5・SHA-1ベースの署名は既に非推奨。新規発行はSHA-256以上を用いる

関連する主要RFC・標準規格

• RFC 5280：X.509証明書とCRLのプロファイルを定めた基本仕様
• RFC 6960：OCSP（証明書のオンライン失効確認プロトコル）
• RFC 8555：ACME（証明書発行・更新の自動化プロトコル。Let's Encryptで採用）
• RFC 3647：証明書ポリシー（CP）・認証局運用規定（CPS）の記述フレームワーク
• CA/Browser Forum Baseline Requirements：パブリックCAが証明書発行時に遵守すべき業界標準ルール

PKIの構成要素

• 認証局（CA）：証明書を発行・署名する信頼された組織
• 登録局（RA）：証明書申請者の身元を確認
• 証明書：公開鍵と所有者情報を結びつけるデジタル文書
• CRL/OCSP：失効した証明書を管理する仕組み
• トラストストア：信頼されたルート証明書の格納場所

AIエンジニアとしての実体験

AIエンジニアとして、社内のマイクロサービス間通信でmTLS（相互TLS認証）を実装する際、PKIの構築が必要でした。以下は社内PKIの構築例です：

# ルートCAの作成
openssl genrsa -out ca.key 4096
openssl req -x509 -new -nodes -key ca.key -sha256 -days 3650 \
    -out ca.crt -subj "/CN=Internal Root CA"

# 中間CAの作成
openssl genrsa -out intermediate.key 4096
openssl req -new -key intermediate.key -out intermediate.csr \
    -subj "/CN=Internal Intermediate CA"
openssl x509 -req -in intermediate.csr -CA ca.crt -CAkey ca.key \
    -CAcreateserial -out intermediate.crt -days 1825 -sha256

# サーバー証明書の発行
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr \
    -subj "/CN=api.internal.example.com"
openssl x509 -req -in server.csr -CA intermediate.crt \
    -CAkey intermediate.key -CAcreateserial -out server.crt \
    -days 365 -sha256

PKIのメリット・デメリット

メリット

• 鍵配送問題の解決とスケーラビリティ：対称鍵のように参加者ごとに事前共有鍵を配る必要がなく、公開鍵は公開しても安全という前提で設計されているため、利用者数が増えても鍵管理の組合せ爆発が起きにくい
• 身元確認（認証）：EV/OV証明書などでは、CAが組織の実在性を審査するため、フィッシングサイトとの区別に一定の効果がある
• 否認防止（non-repudiation）：電子署名やコード署名では、秘密鍵で署名した本人が「署名していない」と後から否認しにくい仕組みを提供する
• 汎用性の高さ：TLS/HTTPSだけでなく、S/MIMEメール暗号化、コード署名、802.1X（EAP-TLS）による社内ネットワーク認証、IPsec/IKEv2のVPN認証など、幅広い用途に同じ枠組みを転用できる
• 失効の仕組みがある：秘密鍵が漏洩しても、CRLやOCSPを通じて該当証明書を無効化でき、対称鍵の総入れ替えに比べて被害範囲を限定しやすい

デメリット・注意点

• 運用の複雑さとコスト：CP/CPS（証明書ポリシー・運用規程）の整備、RAによる審査プロセス、HSMの調達・運用など、正しく設計・運用するには専門知識と継続的な人的コストが必要
• 単一障害点（信頼のルート）リスク：ルートCAの秘密鍵が漏洩すると、そのCA配下で発行された証明書すべての信頼性が損なわれ、影響範囲がインターネット規模になり得る（過去には中間CAの侵害によって不正な証明書が発行された事例が業界で報告されている）
• 失効の伝播遅延：CRLはサイズが肥大化しやすく配信に時間がかかる場合があり、OCSPはリアルタイム性がある反面、CAへの問い合わせがクライアントの通信内容（アクセス先）をCA側に漏らしうるプライバシー上の懸念がある。これを緩和するためOCSP Staplingやショートリブド証明書化が進められている
• 証明書のライフサイクル管理負荷：有効期限切れによる障害は現在も頻発するインシデントの一つで、自動更新の仕組み（ACME等）を導入していない環境ほどリスクが高い。加えて、CA/Browser Forumでは不正利用や鍵の陳腐化を防ぐ目的で、パブリックTLS証明書の最大有効期間を段階的に短縮する方針（数年かけて数十日程度まで短縮していく合意）が進んでおり、今後は手動更新の運用モデルが実務上ますます成立しにくくなる見込み
• 失効漏れ・信頼判断の甘さ：クライアント側の実装によってはCRL/OCSPの取得に失敗した際に「失効していない」とみなす（フェイルオープン）設定になっている場合があり、想定した安全性が得られないケースがある

混同されやすい用語・類似技術との違い

PKIは範囲が広い概念のため、隣接する用語と混同されがちです。実務でよく混同される用語との違いを整理します。

用語	PKIとの関係・違い
TLS/SSL	TLSは通信を暗号化する「プロトコル」。証明書によるサーバー認証にPKIの仕組みを利用しているが、TLS自体はPKIの一部ではなく、PKIという基盤を「使う側」の技術
認証局（CA）	CAはPKIを構成する一要素（証明書を発行する主体）。PKIはCA・RA・証明書・失効管理・トラストストアなどを含む仕組み全体を指す、より広い概念
Web of Trust（PGP/GPG方式）	PKIが中央集権的な階層構造（ルートCAを頂点とする信頼のツリー）であるのに対し、Web of Trustは利用者同士が互いの鍵に署名し合う分散型の信頼モデル。GPGのメール暗号化などで使われるが、TLS証明書のような広範な自動検証の仕組みには一般に用いられない
KMS（鍵管理システム）	KMSは鍵そのものの生成・保管・ローテーションを担うシステム（AWS KMSやHashiCorp Vaultなど）。PKIは「誰の公開鍵か」を証明する信頼の枠組みであり、KMSはその鍵をどう安全に保管・運用するかという運用基盤。両者は補完関係にあり、PKIの秘密鍵をKMS/HSMで保護する構成がよく取られる
DNSSEC	DNSSECもデジタル署名で信頼の連鎖（DNSルート→TLD→ドメイン）を作る点はPKIと類似するが、対象がDNSレコードの改ざん検知に特化しており、証明書の発行・失効管理といったPKI一般の枠組みとは別の標準体系（RFCも別系統）で運用される

企業内PKIの設計

階層構造の設計

一般的なPKI階層は3層で構成されます：

1. ルートCA：オフラインで保管、最上位の信頼アンカー
2. 中間CA：日常的な証明書発行を担当
3. エンドエンティティ証明書：サーバー、クライアント、コードサイニング用

証明書ライフサイクル管理

• 発行：CSRの検証と証明書の発行
• 配布：安全な証明書の配布
• 更新：期限前の自動更新
• 失効：鍵漏洩時の即時失効

最新動向（2026年）

自動化の進展と証明書の短命化

ACME（Automatic Certificate Management Environment、RFC 8555）プロトコルにより、証明書の発行・更新が自動化されています。Let's Encryptの成功を受け、企業内PKIでもACME対応の内製CA（step-ca、smallstepなど）やHashiCorp Vault PKI Secrets Engineを使った自動発行基盤の採用が広がっています。背景には、CA/Browser Forumがパブリック証明書の最大有効期間を段階的に短縮していく方針で合意していることがあり、今後は手動でのCSR発行・証明書更新という運用モデル自体が現実的ではなくなっていく方向にあります。実務では、証明書の有効期限を「人が覚えておく」運用から、ACMEクライアントやCI/CDパイプラインに組み込んだ自動更新へ移行するのが定石です。

ゼロトラストアーキテクチャとの結びつき

ゼロトラストセキュリティモデルでは、社内ネットワークにいることを根拠に信頼せず、すべての通信・すべてのデバイスで証明書ベースの相互認証（mTLS）を求める考え方が一般的になっています。SPIFFE/SPIRE（Secure Production Identity Framework For Everyone）のような、マイクロサービス間で短命な証明書を自動発行・自動ローテーションする仕組みも、PKIの考え方をゼロトラスト時代のワークロード認証に応用したものです。

耐量子計算機暗号（PQC）への移行準備

量子コンピュータの実用化リスクを見据え、NISTは2024年にポスト量子暗号の標準として、鍵交換用のFIPS 203（ML-KEM、旧CRYSTALS-Kyber）、署名用のFIPS 204（ML-DSA、旧CRYSTALS-Dilithium）、FIPS 205（SLH-DSA、旧SPHINCS+）を正式発行しました。米NSAが定める政府機関向けの暗号スイート「CNSA 2.0」も、2030年代前半までを目安にPQCアルゴリズムへの全面移行を求めています。PKIの世界では、既存のRSA/ECDSA署名とPQC署名を併用する「ハイブリッド証明書」の検討がIETF・CA/Browser Forumで進んでおり、主要ブラウザではTLSの鍵交換部分（証明書の署名アルゴリズムとは別レイヤー）でML-KEMベースのハイブリッド鍵交換を試験的に有効化する動きも出ています。証明書の署名アルゴリズム自体をPQCへ切り替える対応は、2026年時点ではまだ移行期の初期段階と捉えておくのが実務上は無難です。

トラブル事例と対策

実務ポイント（監査・ガバナンス）

企業内PKIを設計・運用する際、技術的な構築だけでなく次のようなガバナンス面も合わせて整備しておくと、後々の監査対応やインシデント対応がスムーズになります。

• CP/CPSの文書化：証明書ポリシー（Certificate Policy）と認証局運用規定（Certification Practice Statement）をRFC 3647のフレームワークに沿って文書化しておくと、社内外の監査・取引先審査で説明責任を果たしやすい
• 第三者監査の枠組み：パブリックCAはWebTrust for CAやETSI EN 319 411といった監査基準への準拠が求められる。企業内PKIでも、同様の観点（鍵管理・アクセス制御・ログ保全）でセルフチェックしておくと信頼性が高まる
• 鍵のバックアップとリカバリ計画：ルートCA鍵の紛失は事業継続に直結するため、鍵の分割保管（Shamir's Secret Sharingなど）や複数拠点でのバックアップ手順をあらかじめ定めておく
• 証明書インベントリの可視化：社内に発行済みの証明書がどれだけ存在し、いつ失効するかを一元管理できていない組織は多い。証明書ライフサイクル管理（CLM）ツールや自作の棚卸しスクリプトで可視化することが、有効期限切れ障害の予防に直結する

関連用語

• 認証局（CA）
• X.509証明書
• TLS証明書
• 証明書チェーン
• CSR（証明書署名要求）
• HSM（ハードウェアセキュリティモジュール）
• 公開鍵暗号
• 耐量子計算機暗号（PQC）

外部リンク・参考資料

• RFC 5280 - X.509 PKI証明書とCRLプロファイル（IETF）
• CA/Browser Forum（Baseline Requirements等の業界標準を公開）
• NIST SP 800-57 Part 1 Rev.5（鍵管理の推奨事項）
• NIST Post-Quantum Cryptography Project
• Let's Encrypt ドキュメント（ACMEの実装例）

📝 関連ブログ記事

【2026年最新】OpenSSLの深刻な問題とは？

PKI構築のご相談

企業内PKIの設計・構築、証明書管理自動化など、お気軽にお問い合わせください。