初心者必見！SSLとBundleの基礎知識を徹底解説する方法

2025 11/30

2025/11/30

はじめに

目的

この章は、本シリーズの導入としてSSL（暗号化通信）に関する「CA Bundle（認証局バンドル）」の位置づけと本記事で扱う内容を簡潔に説明します。読者が続きを読み進める際の道しるべにしてください。

対象読者

サーバー運用者、Web開発者、あるいはSSL設定を理解したいエンジニアを想定します。専門家でなくても理解できるよう、具体例を交えて説明します。

CA Bundleとは何か（かんたん説明）

CA Bundleは、SSL証明書を信頼するために必要な複数の証明書をまとめたものです。例えると、鍵を確認するための“信用の鎖”（信頼チェーン）で、順番どおりに並べる必要があります。

本記事の構成

第2章で基本概念、第3章で重要性、第4章で取得方法、第5章で手動作成手順、第6章で生成の制限、第7章でSpring Bootへの実装を詳述します。各章で実例やコマンドを示しますので、実務で役立ててください。

読み方のアドバイス

まず第2章を読み、概念を押さえてから手順に進むと理解が深まります。実際の設定はバックアップを取りながら行ってください。

CA Bundleの基本概念

CA Bundleとは

CA Bundleは、認証局（CA）が発行したルート証明書と中間証明書をまとめた単一ファイルです。サーバーのSSL証明書（リーフ証明書）と一緒に配信することで、クライアント側が接続先の証明書を最終的に信頼できるようにします。形式は主にPEM（テキスト形式）です。

信頼のチェーン（階層）

SSLの信頼は階層構造で成り立っています。最上位がルート証明書、次に中間証明書、最後にリーフ証明書です。クライアントはリーフからさかのぼり、最終的に自分が信頼するルートまでたどれれば接続を許可します。中間証明書が抜けると途中でチェーンが断たれます。

具体例：接続の流れ

サーバーはリーフ証明書とCA Bundleを送ります。 2. クライアントは受け取った中間証明書を使ってルートへつなぎます。 3. ルートが信頼できれば接続が確立します。

CA Bundleがない場合の影響

最新の主要ブラウザは多くのルートを内蔵しますが、古いブラウザや組み込み機器は中間証明書を期待します。Bundleがないと「証明書不明」や接続エラーが発生することがあります。

配置先の例

Webサーバー（Apache、Nginx）やメールサーバーで指定します。設定ファイルでサーバー証明書とBundleを分けて指すことが一般的です。

CA Bundleが重要な理由

要点

CA Bundleはサーバー証明書とルートまでの中間証明書をまとめたものです。特に古いブラウザや廃止されたOS・ライブラリでは、中間証明書を自分で持っていないためBundleが必須です。

中間証明書が欠けるとどうなるか

欠落するとブラウザやクライアントが信頼チェーンを完成できず、SSL接続エラー（証明書不信、鍵交換失敗など）になります。モバイルアプリや古い組み込み機器でよく見られます。

証明書の順序が重要な理由

Bundle内の順序は、通常サーバー証明書→中間証明書→（さらに上位の中間）→ルートの流れで配置します。順序が逆だったり抜けがあると、多くのクライアントが正しく検証できません。実際には順序が誤っていると”chain building”で失敗します。

実務でのチェック・対処

1) オンラインのSSL検査ツールやopenssl s_clientでチェーンを確認します。 2) 中間を追加したり順序を修正して再デプロイします。 3) 古いクライアント向けには完全なBundleを提供してください。

CA Bundleの取得方法

公式サイトからのダウンロード

多くの認証局（CA）は、ルート証明書や中間証明書を公式サイトで配布しています。紛失した場合はまず発行元のダウンロードページを確認してください。発行時に配布されるZIPやリンクにCA Bundleが含まれることが多いです。

発行時に提供されたファイルを確認

証明書発行のメールや管理画面で、chainやbundleという名前のファイルが添付されていないか確認します。これがあればそのまま利用できます。

ブラウザやサーバーから取得する方法

ブラウザの証明書表示機能で中間／ルート証明書をエクスポートできます。サーバーから直接取る場合は、openssl s_clientで接続して表示された証明書群を保存する方法があります（例: openssl s_client -connect example.com:443 -showcerts）。

手動で結合する（簡単な手順）

中間証明書（closest intermediate）を上に、さらに上位の中間を順に並べる。2. 末尾にルート証明書を置く。順序は重要です。例: cat intermediate1.pem intermediate2.pem root.pem > ca-bundle.crt

検証と注意点

作成後はopenssl x509やopenssl verifyで確認してください。OSやアプリによって求める形式や順序が異なるため、配布元の指示に従うと安心です。

CA Bundleの手動作成手順

前提

すべての証明書がPEM形式（—–BEGIN CERTIFICATE—– で始まる）であることを確認してください。
ルート証明書と中間証明書のファイル名を把握しておきます（例: root.pem、intermediate1.pem、intermediate2.pem、intermediate3.pem）。

手順（テキストエディタで行う方法）

各証明書ファイルをテキストエディタで開きます。改行やヘッダー/フッターが欠けていないか確認します。
新しいファイルを作成します（例: ca-bundle.pem）。
正しい順序でコピーします。順序は中間証明書3 → 中間証明書2 → 中間証明書1 → ルート証明書です。上位の発行者が下に来るように並べます。
各証明書の間に一行の改行を入れて保存します。

手順（コマンドラインの簡単な例）

以下はテキスト操作の代替例です。ファイル名は実際のものに置き換えてください。
cat intermediate3.pem intermediate2.pem intermediate1.pem root.pem > ca-bundle.pem

サーバーへのアップロードと設定

作成した ca-bundle.pem をサーバーの適切な場所へアップロードします（例: /etc/ssl/certs/）。
サーバーのSSL設定でBundleファイルのパスを指定します（使用しているソフトウェアに応じて設定箇所が異なります）。
権限を適切に設定します（例: 所有者をroot、パーミッションを640など）。
サービスを再起動して設定を反映させます。

確認方法と注意点

openssl s_client を使い、証明書チェーンが正しく構築されているか確認します:
openssl s_client -connect your.domain:443 -showcerts
ルート証明書は通常サーバーにインストールしないことが多い点に注意してください。クライアント側がルートを信頼している前提で配布します。
証明書の順序を間違えると接続エラーの原因になります。順序と改行を必ず確認してください。

CA Bundleの生成について

概要

CA BundleはCSRジェネレータなどのツールで自動生成できません。証明書のチェーン情報は認証局（CA）が発行・管理するため、取得や組み合わせは人手かCA側の配布に頼ります。

なぜ自動生成できないか

CSRは公開鍵と識別情報を認証局に送るためのもので、CA自身が署名して中間証明書やルート証明書を結び付けます。つまり、Bundleに入る正しい中間証明書はCAが決めるため、CSRツールだけで安全かつ正確に作れません。

取得方法（復習）

CAから直接受け取る（メールやサポート経由）
CAの公式サイトからダウンロードする
手動でマージする

手動での作成手順（具体例）

CAから受け取った中間証明書とルート証明書を準備します。
証明書の内容を確認します：openssl x509 -in intermediate.crt -text -noout
正しい順序で結合します。一般的には中間証明書を先に、ルート証明書を最後に置きます（例：cat intermediate.crt root.crt > ca-bundle.crt）。
サーバ用には通常、サーバ証明書の後にBundleを連結して用います（cat server.crt ca-bundle.crt > fullchain.crt）。

検証と運用上の注意

作成後はopenssl verify -CAfile ca-bundle.crt server.crtでチェーンを確認してください。
ルート証明書は多くの場合クライアント側に既にあるので、省略されても問題ないケースがあります。しかし、環境により必要になることがあるため配慮してください。
保管はアクセス制限し、更新時は古いBundleと差し替える手順を明確にしてください。

Spring BootにおけるSSL Bundleの実装

概要

Spring Boot 3系で導入されたSSL Bundleは、SSLに関する設定を単一の管理単位としてまとめる仕組みです。設定を再利用しやすくし、複数のコネクタやマイクロサービス間で同じ設定を適用できます。3.1ではSslStoreBundle、SslManagerBundle、SslBundleという抽象化レイヤーが加わりました。

各レイヤーの役割（簡潔に）

SslStoreBundle：キーストア／トラストストアの場所やパスを管理します。
SslManagerBundle：SSLコンテキストや鍵の読み込みなど実行時の準備を行います。
SslBundle：上位の束で、複数のマネージャやストアを組み合わせてアプリ全体に提供します。

実装の流れ（実務向け）

キーと証明書を用意し、キーストアを作成します（例：keytool）。
application.yml／propertiesでバンドルの設定を定義します（パス、パスフレーズ、プロトコルなど）。
@Configurationクラスで必要なBundleをBean化します。Storeを作り、ManagerでSSLContextを構築し、Bundleでまとめます。
作成したBundleをコネクタ（サーバ側）やHTTPクライアントに適用します。複数のコネクタで同じBundleを参照すれば設定を共有できます。