Cryptography

Public Key Infrastructure

PKI(公開鍵基盤)

Category: Cryptography / Updated: 2026-05-26

📖

Overview

PKI(Public Key Infrastructure:公開鍵基盤)とは、公開鍵暗号技術を基盤として、デジタル証明書の発行・管理・検証を行う信頼の枠組みです。インターネット上で「通信相手が本物であること」を保証する仕組みであり、HTTPS通信、電子メールの暗号化、電子署名、コードサイニングなど、現代のデジタル社会における信頼基盤を支えています。

PKIの中核を担うのが認証局(CA:Certificate Authority)です。認証局は申請者の身元を確認した上でデジタル証明書を発行し、その証明書に含まれる公開鍵が確かにその所有者のものであることを保証します。ブラウザやOSには信頼されたルート認証局の一覧があらかじめ組み込まれており、この信頼チェーンを通じて証明書の正当性が検証されます。

PKIはX.509標準に基づいて運用されており、世界中で約150以上のルート認証局が信頼リストに登録されています。Let's Encryptの登場により、2016年以降はHTTPS対応サイトが急増し、現在ではWebトラフィックの95%以上がHTTPSで暗号化されています。

🔬

Details

PKIの構成要素

  • 認証局(CA):証明書の発行・署名を行う信頼の核。ルートCAと中間CAの階層構造をとる
  • 登録局(RA):証明書申請者の身元確認を行い、CAに証明書発行を依頼する窓口
  • 証明書リポジトリ:発行済み証明書やCRL(証明書失効リスト)を公開するディレクトリ
  • エンドエンティティ:証明書を利用するユーザー、サーバー、デバイスなど

証明書チェーン(信頼の連鎖)

PKIは階層型の信頼モデルを採用しています。ルートCAは自身の証明書(自己署名証明書)を持ち、その秘密鍵で中間CAの証明書に署名します。中間CAはさらにエンドエンティティ(Webサーバーなど)の証明書に署名します。ブラウザはこの署名チェーンをルートCAまで遡って検証することで、エンドエンティティの正当性を確認します。

証明書の種類

  • DV(Domain Validation)証明書:ドメイン名の所有権のみを確認。最も簡易で安価
  • OV(Organization Validation)証明書:組織の実在性を確認。企業サイト向け
  • EV(Extended Validation)証明書:最も厳格な審査。金融機関などで使用
  • ワイルドカード証明書:*.example.comのようにサブドメインを一括カバー
  • SANs証明書:複数のドメイン名を1枚の証明書でカバー

証明書の失効管理

秘密鍵の漏洩や証明書の誤発行が発生した場合、証明書を失効させる必要があります。失効確認の仕組みとしてCRL(Certificate Revocation List)OCSP(Online Certificate Status Protocol)があります。CRLは失効証明書の一覧をリストとして配布する方式で、OCSPはリアルタイムに個別の証明書の状態を問い合わせる方式です。現在ではOCSPステープリングにより、Webサーバーが事前にOCSP応答を取得してクライアントに提供する方式が主流です。

Certificate Transparency(CT)

2013年にGoogleが提唱したCertificate Transparencyは、認証局が発行するすべての証明書を公開ログに記録する仕組みです。これにより、不正に発行された証明書を早期に検知できるようになりました。現在、主要ブラウザはCTログへの登録を必須としています。

🛡️

Security Measures

  • 01
    証明書の自動更新体制の構築:Let's Encryptなどを使用する場合、certbotなどのツールで自動更新を設定し、証明書の期限切れによるサービス停止を防止してください。証明書の有効期限を監視するアラートも設定しましょう。
  • 02
    秘密鍵の厳格な管理:サーバー証明書の秘密鍵はアクセス権限を最小限に設定し、バックアップも暗号化して保管してください。重要システムではHSMの使用を検討しましょう。
  • 03
    Certificate Transparency監視:自組織のドメインに対して発行された証明書をCTログで監視し、不正な証明書発行を早期に検知する体制を整備してください。
  • 04
    CAA(Certification Authority Authorization)レコードの設定:DNSにCAAレコードを設定し、自ドメインの証明書を発行できる認証局を制限してください。
  • 05
    中間証明書の正しい設定:Webサーバーにはサーバー証明書だけでなく、中間CA証明書も正しくインストールしてください。チェーンが不完全だとブラウザで警告が表示されます。
  • 06
    HSTS(HTTP Strict Transport Security)の有効化:HTTPSの強制とダウングレード攻撃の防止のため、HSTSヘッダーを設定してください。HSTSプリロードリストへの登録も推奨します。
⚠️

Incidents

📋 DigiNotar認証局の侵害事件(2011年)

2011年7月、オランダの認証局DigiNotarがハッキングされ、google.comを含む500以上のドメインに対する不正な証明書が発行されました。この偽証明書はイラン政府によるGmailユーザーの通信傍受に使用されたとされています。事件後、すべての主要ブラウザがDigiNotarのルート証明書を信頼リストから削除し、DigiNotarは破産に追い込まれました。PKI全体の信頼モデルの脆弱性を露呈した歴史的事件です。

📋 Symantec証明書の信頼取り消し(2017-2018年)

2017年、Googleの調査により、世界最大の認証局Symantec(旧VeriSign)が証明書発行プロセスに重大な不備があることが発覚しました。テスト目的で不適切にEV証明書を発行したり、ドメイン所有者の確認を怠るなどの問題が累計3万件以上確認されました。これを受けてGoogle Chromeは段階的にSymantec発行の証明書を信頼対象から除外し、2018年10月に完全に失効させました。影響を受けたサイトは数十万に及びました。

📋 Let's Encrypt証明書の大量失効(2020年)

2020年3月、Let's Encryptはドメイン認証処理(CAA再チェック)のバグにより、約300万枚の証明書を失効させる必要があると発表しました。影響を受けた証明書は全体の約2.6%にあたり、5日以内に再発行・更新が必要でした。多くのサイト管理者は自動更新スクリプトの再実行で対応しましたが、手動管理のサイトでは一時的なサービス影響が発生しました。

🔗

Related Terms