SSL証明書チェーンとは？仕組みを解説

SSL証明書チェーンとは？

SSL証明書チェーン（信頼の連鎖、証明書パスとも呼ばれます）は、ウェブサイトのSSL/TLS証明書を信頼されたルート認証局（CA）につなぐ、順序付きのデジタル証明書の一覧です。チェーン内の各証明書は上位の証明書によってデジタル署名されており、サーバーから、ブラウザがすでに信頼しているルートCAまで、検証可能な信頼の経路を作ります。

推薦状の連鎖のようなものだと考えてください。サーバー証明書は「私はexample.comです」と言い、中間CAは「example.comの証明書を保証します」と言い、ルートCAは「その中間CAを保証します」と言います。ブラウザはルートCAをすでに信頼しているため、署名をたどることでサーバーも信頼します。

HTTPSサイトにアクセスすると、ブラウザはこのチェーンを数ミリ秒でたどります。すべての輪が正しければ、警告なしでページが表示されます。輪が欠けている、期限切れ、または信頼されていない場合は、代わりにNET::ERR_CERT_AUTHORITY_INVALIDのようなセキュリティ警告が表示されます。

チェーンに含まれる3種類の証明書

どのチェーンにも3種類の証明書がありますが、サーバーが送る中間証明書は1枚とは限りません。

ルート証明書

ルート証明書はチェーンの最上位にある信頼の起点です。自己署名、つまり認証局が自分自身の証明書に署名したものです。ルート証明書はブラウザとOSにあらかじめインストールされており、この集まりをトラストストアと呼びます。

Chrome独自のルート一覧には約100のルートが含まれます（Chrome Root Store）。Mozilla、Apple、Microsoftもそれぞれ独自の一覧を持っています。DigiCert、Let's Encrypt（ISRG）、Sectigo、GlobalSign、Google Trust Servicesなどの組織がルートを運用しています。ルート鍵は非常に価値が高いため、CAはハードウェアセキュリティモジュール内でオフライン保管し、中間証明書への署名にのみ使います。

中間証明書

中間証明書は、ルートとサーバー証明書の間に位置します。ルートCAが中間証明書に署名し、その中間CAがエンドエンティティ（サーバー）証明書に署名します。ほとんどのCAは1〜2枚の中間証明書を使います。

Webサーバーは、TLSハンドシェイク中にリーフ証明書と一緒に中間証明書も送信する必要があります。Chromeは不足している中間証明書をダウンロードでき、Firefoxは中間証明書を事前に持っていますが、アプリ、APIクライアント、古いAndroid端末はどちらもできないため、それらではチェーンが途切れます。

リーフ証明書（サーバー証明書）

リーフ証明書（エンドエンティティ証明書、サーバー証明書とも呼ばれます）は、ウェブサーバーにインストールされている証明書です。ドメイン名、公開鍵、有効期間、発行者情報（署名した中間CA）が含まれています。

これはTLSハンドシェイク中にブラウザが最初に受け取る証明書です。ブラウザはその後、チェーンを上にたどり、信頼されたルートに到達するまで各署名を検証します。

信頼の連鎖の仕組み

ブラウザがHTTPS経由でウェブサイトに接続すると、TLSハンドシェイクがミリ秒で行われるチェーン検証プロセスを開始します：

• サーバーが証明書を送信 — リーフ、続いて中間証明書。
• ブラウザが経路を組み立てる — リーフから、自身の一覧にあるルートまで。中間証明書が不足している場合、Chromeは証明書に書かれたアドレス（AIA）からダウンロードし、Firefoxは事前に持っている中間証明書を使います。それ以外の多くのクライアントは単に失敗します。
• 署名を確認 — 各証明書は、上位の証明書の鍵で署名されている必要があります。
• ルートを確認 — 経路はブラウザの一覧にあるルートで終わる必要があります。未知のルートは失敗します。
• 有効性を確認 — すべての証明書が有効期間内で失効しておらず、リーフがアドレスバーのドメイン名をカバーしている必要があります。

実際のチェーン：大手12サイトが送っているもの

2026年10月27日に、大手12サイトのチェーンを取得しました（openssl s_client -showcerts、2か所から）。リーフだけを送ったサイトはなく、古い端末でも既知のルートにたどり着けるよう、相互署名された証明書を追加で送っているサイトもありました。サーバーが送る内容は、TLSのバージョン、クライアントのECDSA対応、応答したCDNの拠点によって変わることがあります。たとえばfacebook.comは、TLS 1.2では3枚の証明書を送りました。

検証後に何が起こるか

すべてのチェックに合格すると、接続が進みます。中間証明書であっても、1つでも失敗すると、ブラウザは「この接続ではプライバシーが保護されません」のような警告を、NET::ERR_CERT_AUTHORITY_INVALIDなどのコードとともに表示します。（証明書を調べる前、TLSハンドシェイクの段階での失敗には別のコードが表示されます：ERR_SSL_PROTOCOL_ERRORやERR_SSL_VERSION_OR_CIPHER_MISMATCH。）

これが、リーフ証明書だけでなくチェーン全体が重要な理由です。期限切れの中間証明書は、クライアントが別の経路を組み立てられない限り、期限切れのサーバー証明書と同じようにHTTPSを壊します。

中間証明書が存在する理由

ルートCAは理論的にはすべてのサーバー証明書に直接署名し、中間証明書を完全に省略することもできます。しかし、そうしない3つの重要な理由があります：

• セキュリティの分離 — ルートCAの秘密鍵は物理的に安全な金庫内のHSMでオフラインに保管されます。数百万の個別サーバー証明書ではなく、中間証明書の署名にのみ使用されます。これにより、ルート鍵が侵害されるリスクが大幅に低減されます。
• 被害の封じ込め — 中間CAが侵害された場合、その中間CAの証明書のみが影響を受けます。ルートCAは侵害された中間を失効させ、新しいものを発行できます。これまでに発行したすべての証明書を無効にすることなく対応できます。
• 運用の柔軟性 — CAは異なる目的に異なる中間証明書を使用します：DV証明書用、EV用、異なる地域や鍵アルゴリズム（RSA vs ECDSA）用に別々のものを使います。

SSL証明書チェーンの確認方法

コマンドラインツールからブラウザでの確認まで、ウェブサイトの証明書チェーンを調べる方法は3つあります。

方法1：OpenSSL（コマンドライン）

opensslコマンドは、証明書チェーンを検査する最も詳細な方法です。ターミナルで次のコマンドを実行してください：

# List each certificate the server sends (s: subject, i: issuer)
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E ' [si]:'

# Then read the verdict
openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep -m1 'Verify return code'

方法2：ブラウザの証明書ビューア

主要なブラウザはどれも、組み立てたチェーンを表示します（不足していた中間証明書をブラウザ自身が取得した場合は、サーバーが送ったものと異なることがあります）。

• Chrome：アドレスの左にあるアイコンをクリック →「この接続は保護されています」→「証明書は有効です」を選び、「詳細」タブで証明書の階層を確認します
• Edge：鍵アイコンをクリック → 「Connection is secure」 → パネル上部の証明書アイコン
• Firefox：鍵アイコンをクリック → 「安全な接続」 → 「詳細を表示」 → 「証明書を表示」。チェーン内の各証明書にそれぞれタブがあります
• Safari（18.4以降）：メニューバーで「Safari > 接続セキュリティの詳細」を選びます（Apple）。iPhoneでは、アドレスフィールドの左側をタップ → 「Privacy & Security」 → 「Connection Security Details」

方法3：DNS Robot SSLチェッカー

ネットワークの外から最も手早く確認できるのが、当社のSSLチェッカーです。サーバーが送信するチェーン、Mozilla・Chrome・Apple・Microsoftの各ルート一覧がそれを信頼するかどうか、チェーンが不完全な場合の警告、各証明書の有効期限を表示します。Cloudflare配下のサイトでは公開CTログから証明書を読み取るため、サーバーが送信するチェーン自体は確認されません。

よくある証明書チェーンエラーと修正方法

証明書チェーンの問題は、HTTPSエラーの最も頻繁な原因の1つです。遭遇する可能性が最も高いエラーとその解決方法を紹介します。

中間証明書の欠落

エラーメッセージ：「unable to get local issuer certificate」（curl、Python、PHP）、「unable to verify the first certificate」（Node.js）、または「incomplete certificate chain」

原因： サーバーがリーフ証明書だけを送っています。Chromeは中間証明書を自分でダウンロードして補うことが多い（Appleの検証機能も同様）ため、ブラウザでは問題なく見えても、Linuxのcurl、Python、Java、決済コールバック、多くのアプリでは失敗します。

修正方法： リーフと一緒に中間証明書を送信します。Let's Encryptなら、サーバーの設定をcert.pemではなくfullchain.pemに向けます。他のCAの場合は、その中間証明書をダウンロードし、自分の証明書の後ろに続けて1つのファイルにまとめます。

cat your-domain.crt intermediate.crt > fullchain.crt

チェーン内の自己署名証明書

エラーメッセージ：「self-signed certificate in certificate chain」（OpenSSLエラー19）

原因： チェーンの終点が、クライアントの信頼しないルートになっています。社内や非公開のCA、または独自のルートで通信を再署名するプロキシやウイルス対策ソフトなどが該当します。クライアントが信頼するルートを送るのは無害で、ただ不要なだけです。

修正方法： 公開サイトには公的CAの証明書を使うか、必要なクライアントに非公開ルートをインストールします。サーバーのチェーンからルートを外すのは整理にはなりますが、このエラーは直りません。

証明書の順序が間違っている

エラーメッセージ： 一部のクライアントでチェーン検証が失敗する、または証明書が信頼されないと報告される。

原因： チェーンファイル内の証明書の順序が間違っています。TLS 1.3ではサーバー自身の証明書を先頭にし、残りも順番に並べるよう求めつつ、クライアントには他の順序も許容するよう定めています（RFC 8446 §4.4.2）。古いクライアントや厳格なクライアントでは許容されないことがあります。

修正方法： リーフ証明書を先頭にし、その後に、リーフに署名した中間証明書から順に並べます。

チェーン内の期限切れ証明書

エラーメッセージ：「certificate has expired」 — しかし、リーフ証明書の有効期限は問題なさそうに見えます。

原因： チェーンの上位にある証明書が期限切れになっています。最も有名な例は、Let's Encryptのルートに相互署名していたIdenTrustのDST Root CA X3が2021年9月30日に期限切れとなり、ISRG Root X1を信頼しない端末（およびOpenSSL 1.0.xのクライアント）がLet's Encryptのサイトで失敗し始めたことです。

修正方法： CAから最新の中間証明書をダウンロードし、古いものと置き換えます。その後、当社のSSLチェッカーで更新後のチェーンを確認してください。

証明書チェーンのベストプラクティス

• 中間証明書は必ず送信する — ブラウザがチェーンを補ってくれると期待しないでください。アプリやAPIクライアントは補ってくれません。
• ルートは任意 — クライアントは自分のコピーを使うため、信頼されているルートを送ってもバイト数が増えるだけです。古い端末向けの相互署名ルートは意図的な例外です。
• 順序を守る — 先頭がリーフ、続いてリーフに署名した中間証明書から上へ向かって並べます。
• 更新を自動化する — 2026年3月以降に発行される証明書の有効期間は最長200日で、2027年3月には100日に短縮されます。Let's Encryptは2027年2月に64日の証明書へ移行します。
• 更新や移行のたびに確認する — CAは更新の間に中間証明書を切り替えることがあります。そのたびにSSLチェッカーでサイトを確認してください。
• すべての名前を確認する — www、ネイキッドドメイン、各サブドメインは、それぞれ別の証明書とチェーンで配信されることがあります。サブドメインファインダーなら、公開された証明書ログから、証明書がカバーしてきた名前を一覧できます。