初心者必見！SSLと中間証明書の仕組みや役割を徹底解説

はじめに

はじめに

ウェブサイトのアドレスが「https://」で始まると、安全に通信できると感じますよね。その安全性を支える仕組みの一つがSSL/TLS証明書です。本記事は、証明書の中でも「中間証明書」と呼ばれる要素に焦点を当てて解説します。

本記事の目的

中間証明書が何をするのか、どんな仕組みで信頼をつなぐのか、導入するときに気を付ける点は何かを、専門用語をなるべく抑えて具体例を交えながら説明します。技術担当者だけでなく、運用担当や興味のある方にも読んでいただける内容です。

なぜ中間証明書が身近なのか

たとえば、あなたが通販サイトにログインするとき、サイト側の証明書だけでなく中間証明書がブラウザに渡され、最終的に信頼された“ルート”へつながります。発行者が直接ルート証明書で署名する代わりに、中間証明書を介することで運用上の安全性と柔軟性を高めます。

記事の構成

第2章で定義と役割を、 第3章で詳細な仕組みを、 第4章で利点と問題点を、 第5章で具体的な設定方法を扱います。次章から順に読み進めると分かりやすい構成です。

次章では、中間証明書の定義と役割をやさしく説明します。

中間証明書の定義と役割

概要

中間証明書は、ルート認証局（ルートCA）と利用者（ウェブサイトやアプリなど）の証明書の間に入るデジタル証明書です。簡単に言うと、ルートCAが直接発行する代わりに、中間証明書が利用者向けの証明書を発行する“代理”の役割を果たします。

主な役割

• 証明書の発行：中間CAがエンティティ（サーバーやソフトウェア）向けの証明書を発行します。これによりルートCAは日常的な署名から離れます。
• 信頼の連鎖の確立：利用者の証明書は中間証明書、さらにその上のルート証明書へとつながり、ブラウザやOSはこの連鎖を辿って信頼を確認します。
• ルート鍵の保護：ルートCAの秘密鍵は厳重に保管し、普段は使いません。中間証明書が代わりに署名することで、ルート鍵の漏洩リスクを下げます。

具体的な例

会社組織に例えると、ルートCAが取締役会だとすると、中間CAは部長や課長のような役割です。部長が現場へ指示を出す代わりに、課長が日常の決定を行います。ウェブサイトの証明書は課長が出す許可証に当たります。

運用上の注意点

中間証明書にも有効期限と失効リストがあります。適切に管理しないと信頼の連鎖が途切れ、利用者側でエラーが出ます。証明書の配置や更新を定期的に確認することが重要です。

中間証明書の仕組み

鍵の生成とCSR作成

中間CAはまず自分の鍵ペア（秘密鍵と公開鍵）を作成します。次に公開鍵と識別情報を使ってCSR（証明書署名要求）を作ります。CSRには組織名や有効期間候補などが含まれます。具体例として、会社Aが中間CAを作るときは秘密鍵を安全な場所に保管し、CSRをルートCAへ送ります。

ルートCAによる署名と発行

ルートCAは受け取ったCSRの内容を確認し、問題なければCSRに署名して中間証明書を発行します。署名により中間CAの公開鍵と識別情報が信頼されるようになります。ルートCAの秘密鍵で署名するため、ルートの信頼性がそのまま中間CAに伝わります。

証明書チェーンと検証の流れ

サーバーやサービスはエンドエンティティ証明書（例：webサイト証明書）を提示します。多くの場合、サーバーは自分の証明書と中間証明書を順に送ります。ブラウザやOSは受け取ったチェーンをたどり、各証明書の署名と有効期限を検査します。最終的にチェーンの先にあるルート証明書が信頼された証明書ストアにあると確認できれば、通信は信頼されます。

追加の検査項目

検証では署名の整合性、有効期限、取り消し（CRLやOCSP）をチェックします。順序が正しくないと検証に失敗するため、サーバー側では中間証明書を正しい順に配置して送ることが重要です。

まとめの代わりに

以上が中間証明書が作られ、実際に使われるまでの仕組みです。具体的な操作やコマンドは第5章で説明します。

利点と問題点

利点

• セキュリティの向上
• 中間証明書を使うと、最上位のルート証明書の秘密鍵を毎日使わずに済みます。例えば、ルートは安全な保管庫にしまい、運用は中間証明書で行うことでルート鍵の漏えいリスクを下げます。
• 発行管理の柔軟性
• 組織ごとや用途ごとに中間を分けられます。例：本番用と開発用で別の中間を置けば、開発で問題が起きても本番側だけ無効化できます。
• 運用上の利点
• 証明書の発行ポリシーや有効期間を中間ごとに変えられ、監査ログや自動化を集中管理できます。

問題点

• 設定ミスでの障害
• サーバに中間証明書チェーンを正しく置かないと、ブラウザやクライアントが「中間が見つからない」として接続エラーを出します。
• 管理の複雑化
• 中間が増えると鍵管理や発行ポリシーの運用負荷が増します。誤発行や期限切れの見落としが起きやすくなります。
• 中間の漏えいリスク
• 中間の秘密鍵が漏れると、その中間で発行された全ての証明書が危険になります。したがって、鍵の保護は厳重にする必要があります。

対策（実務的な注意点）

• 中間鍵は専用のHSMや限定されたサーバで保管する。
• サーバ証明書を配布するときは完全な証明書チェーン（中間を含む）を一緒に配置する。
• 有効期間を短めにし、自動更新と監視を導入する。
• 発行ポリシーと監査ログを整備して、誤発行を早期に検知する。

中間証明書の設定方法

中間証明書はWebサーバーにインストールして、証明書チェーンを正しく組むことで機能します。ここでは、手順をわかりやすく説明します。

1) 証明書の入手と形式

• 発行元（CA）から中間証明書を受け取ります。形式は通常PEM（.crt/.pem）です。

2) 証明書チェーンの作成（例）

• サーバー証明書（あなたのサイトの証明書）と中間証明書を正しい順で連結します。一般的な順序は「サーバー証明書→中間証明書（複数ある場合は上位へ）」です。
• 例: cat yoursite.crt intermediate.crt > fullchain.pem

3) サーバー別の設定例

• Apache: SSLCertificateFile /path/to/fullchain.pem と SSLCertificateKeyFile /path/to/privkey.pem を指定します。
• Nginx: ssl_certificate /path/to/fullchain.pem; と ssl_certificate_key /path/to/privkey.pem; を指定します。
• IIS/Windows: 証明書を「個人」ストアにインポートし、サイトバインドで選択します。

4) ファイルの権限と所有権

• 秘密鍵は厳重に保護します。所有者を限定し、他ユーザーは読み取り不可にしてください。

5) サービス再起動と確認

• 設定後にWebサーバーを再起動します。openssl s_client -connect example.com:443 -showcerts やオンラインのSSLチェッカーでチェーンが正しく表示されるか確認してください。

6) 更新と自動化

• 中間証明書やサーバー証明書の期限を監視します。自動更新ツール（例: Let’s Encryptのcertbot等）を使うと手間が減ります。したがって、更新手順を文書化しておくと安心です。