中間証明書とは何か？PKIと証明書チェーンの仕組みと実務運用ガイド

2025年11月20日 最終更新日時 : 2025年11月20日 エバープレイ編集部

中間証明書とは — 概要

中間証明書（Intermediate Certificate、Intermediate CA 証明書）は、公開鍵基盤（PKI: Public Key Infrastructure）の中でルート証明書（Root CA）とエンドエンティティ証明書（サーバーやクライアントの証明書）の間に位置する証明書です。中間証明書はルートCAまたは上位の中間CAによって署名され、下位の証明書を署名する権限（署名用の拡張 keyCertSign）を持ちます。これはセキュリティと運用の観点から重要な役割を担います。

なぜ中間証明書が必要か — 目的と利点

  • ルート鍵の保護: ルートCA の秘密鍵は非常に機密性が高く、通常はオフラインで保管されます。頻繁に証明書を発行するためにルート鍵をオンラインにするのは危険なので、中間CA を用い実際の発行作業は中間鍵で行います。
  • 責任分離と運用管理: 中間CA を用途別（SSL/TLS、コード署名、S/MIME など）や組織別に分けることで発行ポリシーを分離し、管理を簡素化します。
  • 失効およびローテーションの容易化: 中間鍵が漏洩した場合、ルート鍵を使わずに当該中間CA を失効させることで影響範囲を限定できます。
  • 互換性維持（クロスサイン）: 他の上位CA によって中間CA がクロスサインされることで、異なるルートストアを持つクライアントへの互換性を確保できます。

チェーン・オブ・トラスト（証明書チェーン）

証明書チェーンは、エンドエンティティ証明書から始まり、1つ以上の中間証明書を経て、最終的にルート証明書へ至る一連の署名関係です。ブラウザやOSはこのチェーンをたどり、最終的に信頼されたルート証明書に到達できるかを検証して信頼を判断します。

ポイント:

  • サーバーは通常、証明書チェーン（エンドエンティティ証明書 + 必要な中間証明書）をクライアントに提示します。ルート証明書は含めません（クライアント側の信頼ストアに存在するため）。
  • チェーンが途中で欠けている（中間証明書が欠如）と、クライアントは「信頼できない証明書」として警告を出す場合があります。
  • Path building と path validation は RFC 5280 に規定されたプロセスで、証明書の有効期間、拡張、署名アルゴリズム、有効な用途（Key Usage / Extended Key Usage）、CRL/OCSP による失効状態などを検査します。

ブラウザ・OS と中間証明書の扱い

主要なブラウザやOSは「信頼されるルート証明書ストア」を持ち、そこに格納されたルートCA に対してのみ絶対的な信頼を置いています。中間証明書は通常サーバー側が提供するか、クライアントがキャッシュしている場合があります。クロスサインにより、ある中間CA が複数のルートに対して有効になることもあります（互換性向上のため）。

サーバーでの中間証明書の設定（よくあるミス）

一般的なサーバー設定での注意点:

  • Apache: 古い設定では SSLCertificateChainFile を使っていましたが、最近は SSLCertificateFile にサーバー証明書の後に中間証明書を結合したファイル（いわゆる fullchain）を指定するのが一般的です。
  • Nginx: ssl_certificate にフルチェーン（サーバー証明書 + 中間証明書）を設定し、ssl_certificate_key に秘密鍵を指定します。中間証明書を送らないと多くのクライアントで検証エラーになります。
  • IIS/Windows: 中間証明書は「中間証明機関」ストアにインポートするか、PFX に中間証明書を含めてインポートします。
  • よくあるミス: 中間証明書を省略してしまう。これにより一部のクライアント（古いOS/ブラウザ）で「信頼されない証明書」の警告が出ます。

確認・トラブルシューティングのためのコマンド例

代表的な OpenSSL コマンド（例）:

openssl s_client -connect example.com:443 -showcerts
openssl x509 -in cert.pem -text -noout
openssl verify -CAfile chain.pem cert.pem

s_client の出力で送信された証明書群を確認し、openssl verify でチェーンの検証を行うことで、中間証明書が正しく配置されているかを検証できます。

失効確認 — OCSP と CRL、OCSP ステイプル

中間証明書やエンドエンティティ証明書の失効確認は、主に CRL（Certificate Revocation List）と OCSP（Online Certificate Status Protocol）で行われます。OCSP はサーバーがクライアントの代わりに発行元に問い合わせる方式（リアルタイム）で、OCSP ステイプリング（Stapling）はサーバーが自ら OCSP 応答を取得してクライアントに添付することで、クライアント側の遅延とプライバシー問題を低減します。中間CA 自体に対する失効も同様に管理されます。

中間証明書に関するセキュリティ上の考慮点

  • 秘密鍵の保護: 中間CA の秘密鍵も高い保護が必要です。可能なら HSM（Hardware Security Module）で管理します。
  • ログと透明性: Certificate Transparency（CT）ログは公開証明書の検出と監査に使われます。多くのブラウザが公開認証局による証明書の透明性を重視しています。
  • 短期証明書と自動化: 近年は短期間有効（例: 90日）の証明書と自動更新（ACME/Let’s Encrypt など）が普及していますが、中間CA を適切に管理しないと自動化の失敗でサービス障害を招きます。
  • 鍵漏洩時の対応: 中間鍵が漏洩した場合は当該中間CA を失効（CRL/OCSP に登録）して再発行を行い、影響を受ける発行済み証明書を更新する必要があります。

実務的なベストプラクティス

  • サーバーにフルチェーン（サーバー証明書 + 中間証明書）を正しく配置する。
  • 中間CA の秘密鍵は HSM やオフライン保管で保護し、アクセス制御と監査を行う。
  • OCSP ステイプリングを構成してクライアントに迅速な失効情報を提供する。
  • 定期的に証明書チェーンの検証（自動監視）を行い、期限切れやチェーン欠如を検出する。
  • クロスサインや互換性の違いに注意し、主要クライアント（古いOSや組み込み機器）での検証を行う。
  • 証明書透明性（CT）やブラウザ要件の変化を追い、対応を怠らない。

Let’s Encrypt の例

Let’s Encrypt の場合、発行されたサーバー証明書は中間証明書による署名の下にあります。ユーザーは通常、fullchain.pem（証明書 + 中間証明書）をサーバーに設置します。Let’s Encrypt は過去にクロスサインチェーンやルート移行を行ったため、チェーンの互換性に関する注意が必要です（クライアントによっては古いルートを参照するケースなど）。

まとめ

中間証明書は PKI の設計上、セキュリティと運用性を両立させるために不可欠な要素です。ルート鍵の保護、責任分離、失効対応の容易化、互換性確保など多くの利点を持ちますが、サーバーへの適切な設置や失効情報の運用、秘密鍵の管理といった実務的な注意点を怠るとサービス障害やセキュリティ事故につながります。証明書チェーンの構成・検証・監視を自動化し、最新のブラウザ要件やベストプラクティスに従うことが重要です。

参考文献

カテゴリー
IT
前の記事
Metallica徹底解説：名盤・ライブ・影響・時代の変遷を読み解くNew!!
2025年11月20日
次の記事
Metallica レコードを極める：初回プレス・180g盤の比較とおすすめアルバム総まとめNew!!
2025年11月20日