LASSIC Media らしくメディア
証明書チェーンの仕組み｜SSL証明書の信頼をたどる流れを解説
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 証明書チェーンは、サーバー証明書の正しさを、発行元の認証局を上位へたどって確かめる仕組みです。
- ルート認証局は全サイトに直接署名せず、日々の発行を中間認証局に任せ、ルート認証局の鍵を使う機会を減らしています。
- 中間証明書の設定漏れや有効期限切れは、環境によって症状の出方が変わる不具合につながります。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
ブラウザで開くと問題なく表示されるのに、決済サービスとのAPI連携（システム同士でデータをやり取りする仕組み）だけが証明書エラーで止まる。証明書を更新したら、古いスマートフォンからだけアクセスできなくなった——。HTTPS化したWebサイトやシステム同士の通信では、こうした不具合が起こりがちです。原因を探るときに押さえておきたいのが証明書チェーンです。証明書チェーンとは、サーバー証明書が信頼できるかを判断するために、発行した認証局の証明書を上位へ順にたどり、信頼の起点であるルート証明書までつなげた連鎖のことです。
証明書チェーンを知っておくと、エラーが出たときにどこを確かめればよいか見当を付けやすくなります。ただし、証明書チェーンが確かめるのは通信相手が本物かどうかで、暗号化の方式そのものとは別の話です。本記事では、発注担当者やプロジェクトマネージャーに向けて、認証局が階層に分かれている理由、検証の流れ、よくある不具合、そして外部に委託するときに確認したい点を整理します。
目次
証明書チェーンとは
ブラウザやOSは、通信を始めるときにサーバーから証明書を受け取ります。しかし、証明書を見せられただけでは、それが本物かどうかを確かめようがありません。そこで、証明書に付いている署名を発行元の認証局までさかのぼり、ブラウザやOSにあらかじめ組み込まれたルート証明書に行き着くかどうかで正しさを判断します。この確認の道筋は「認証パス」や「信頼の連鎖（チェーン・オブ・トラスト）」とも呼ばれます。
この連鎖が成り立つのは、認証局（証明書を発行し、その正しさを保証する機関）が階層構造をとっているためです。ブラウザのアドレスバーに出る鍵マークは、通信が暗号化されていることに加え、この検証を通った証明書が使われていることを示します。
なぜ認証局を階層に分けるのか
証明書チェーンが何段階かに分かれているのは、ルート認証局の鍵を守り、問題が起きたときの影響を小さく抑えるためです。もしルート認証局が世界中のWebサイトに直接署名する運用だったら、署名に使う秘密鍵が漏えいしたとき、被害はインターネット全体に及びかねません。署名する回数を減らすほど、鍵が外部にさらされる機会も減らせます。
そこで実際には、ルート認証局は日々の発行には使わずに厳重に保管し、日々の証明書の発行は中間認証局に任せる二段構えをとります。ルート認証局が署名するのは、中間認証局の証明書を発行するときだけです。ある中間認証局で不正な発行や鍵の漏えいが起きても、その中間認証局の証明書だけを無効にすれば済み、ルート証明書を作り直す必要はありません。
証明書の中には、認証局を通さず自分自身で署名する「自己署名証明書」もあります。開発環境での検証など限られた用途で使うもので、第三者の機関が発行したものではありません。社外向けのWebサイトで使うと、ブラウザは信頼できる連鎖につながっていないと判断して警告を出します。
検証はどう進むのか
検証は、Webサイトのサーバー証明書から出発し、ルート証明書に向かって署名をたどっていく作業です。流れを図にまとめました。
まず、ブラウザやOSはサーバーから受け取ったサーバー証明書を確認します。この証明書には、どの認証局が発行したかが記録されています。次に、その認証局の証明書である中間証明書をたどり、同じように発行元を確かめて、さらに上位へさかのぼります。上位の証明書が、端末やブラウザにあらかじめ組み込まれている信頼済みのルート証明書と一致すれば、検証は完了です。途中で一つでも署名が正しくなかったり、信頼済みのルート証明書にたどり着けなかったりすると、その通信相手は信頼できないと判定されます。
ルート証明書・中間証明書・サーバー証明書の3つは、発行する者も役割も異なります。表にまとめました。
| 証明書の種類 | 発行者 | 主な役割 |
|---|---|---|
| ルート証明書 | ルート認証局が自己署名 | 信頼の起点。あらかじめブラウザやOSに組み込まれる |
| 中間証明書 | ルート認証局が中間認証局へ発行 | ルート証明書とサーバー証明書をつなぐ |
| サーバー証明書 | 中間認証局がWebサイト運営者へ発行 | Webサイトそのものの身元を示す |
ブラウザは、署名をたどる確認とあわせて、証明書が期限内に取り消されていないかも確かめます。認証局は、漏えいなどの理由で無効にした証明書の一覧を提供しており、個別に問い合わせられる仕組みもあります。こうした失効確認の方法は、OCSPやCRLと呼ばれます。署名の連鎖をたどる確認と、失効していないかの確認は、役割の違う2つのチェックです。
つまずきやすい点
もっとも起こりやすいのが、サーバーに中間証明書を設定し忘れることです。サーバー証明書を申請したら、対応する中間証明書もあわせてインストールする必要があります。ChromeやSafariなどの主要なブラウザは、足りない中間証明書をAIA（証明書に書かれた発行元の参照先）という仕組みで別に取得し、検証を続けられる場合が少なくありません。一方、サーバー同士のAPI通信で使うプログラム（HTTPクライアント）や、モバイルアプリに組み込まれた通信ライブラリの一部は、この自動取得に対応していません。
その結果、「ブラウザで開くと表示できるのに、決済API連携やバッチ処理（決まった時刻にまとめて動く処理）からのアクセスだけが証明書エラーで止まる」という不具合が起きます。利用者の画面では問題が出にくく、システム同士の連携で先に症状が出るため、原因を特定するまでに時間がかかりがちです。
古いAndroid端末でも似た問題が出ることがあります。端末に組み込まれた信頼済みルート証明書の一覧はOSのバージョンごとに固定されていて、後から更新されにくいためです。認証局が新しいルート証明書に切り替えた直後は、古いOSの端末がまだ新しいルートを信頼できません。そのため、サーバーにどの中間証明書を設置したかによって、古い端末で表示できるかどうかが変わることがあります。
認証局がルート証明書を切り替えるときは、古いルートを信頼している端末への配慮として、新旧どちらのルートからも同じ中間証明書をたどれるようにする「クロス署名」という方法が使われることがあります。ただし、クロス署名はいつまでも続くものではありません。Let’s Encryptが2024年に新しい発行チェーンへ移行した際の案内では、2024年6月に古いルートによるクロス署名の提供をやめると説明し、新しいルートをもともと信頼していない古いOS（Android 7.0）は、その時点ですでに互換性がない例として挙げられています。*6 ルート証明書の切り替えが予告されたら、自社が対象とする端末とOSで表示を確かめておきます。
期限切れ・時刻のずれ・設置の順序
よく見られるのが、証明書の有効期限切れです。サーバー証明書だけでなく、中間証明書やルート証明書にも有効期間があり、どれか一つでも切れていれば、連鎖全体が信頼できないと判定されます。更新の時期を一か所でまとめて管理できていないシステムほど、この見落としが起きやすくなります。
見落とされがちなのが、サーバーやクライアントの時刻のずれです。検証では、現在の時刻が証明書の有効期間に収まっているかを照合します。機器の時刻が大きくずれていると、有効な証明書でも期限切れとして扱われます。バッチ処理用のサーバーやIoT機器（ネットワークにつながる機器）のように、時刻を合わせる設定がおろそかになりがちな機器で起こりやすい問題です。
証明書を設置する順序を誤ることもあります。証明書チェーンは、サーバー証明書、中間証明書の順に並べて設置する必要があり、ソフトウェアによっては順序が違うだけで検証に失敗します。サーバーの入れ替えや移行の際に、順序が崩れていないかを確かめる工程を入れておくと、切り替え時の見落としを防ぎやすくなります。
ここまでの不具合を、症状・よくある原因・確認と対処の方法に分けて表にまとめました。
| 症状 | よくある原因 | 確認・対処 |
|---|---|---|
| ブラウザは表示できるがAPI連携だけ失敗する | 中間証明書の設置漏れ（AIAによる取得に対応しないクライアント） | 中間証明書を含むチェーン全体を設置し、外部の検証ツールで確認する |
| 古いOSの端末だけアクセスできない | 端末の信頼済みルート証明書の一覧が古く、新しいルート証明書やクロス署名に対応していない | 対象の端末とOSで表示を確認し、対応するOSを見直す |
| ある時点から突然エラーになる | サーバー証明書、または中間・ルート証明書の有効期限切れ | 有効期限をまとめて監視し、期限が近づいたら通知する仕組みを整える |
| 一部の機器だけ日付に関わるエラーになる | サーバーやクライアントの時刻のずれ | 時刻を合わせる設定を確認し、ずれを定期的に点検する |
| 社内システムだけ警告が出る | 内部PKI（社内で運用する認証局）のルート証明書が対象の端末に配布されていない | 内部PKIのルート証明書を配布・管理する手順を整える |
外部に委託するときに確認しておきたい点
証明書チェーンの検証そのものは、ブラウザやOS、通信ライブラリが行います。発注担当者やプロジェクトマネージャーが確かめたいのは、運用として何を確認し、どう監視する体制になっているかです。確認したい点は、次の5つに整理できます。
- 証明書の更新と期限の監視
- ACMEによる自動更新
- 中間証明書のバンドル配置
- 内部PKIを運用する場合の体制
- 開発会社と自社の責任の分担
一つ目は、更新と監視の仕組みです。有効期限が切れると、Webサイトやシステム間の通信が突然使えなくなり、対外的な信頼にも影響します。期限が近づいたら担当者に通知が届く仕組みがあるかを開発会社に確かめ、監視の対象にはサーバー証明書だけでなく、中間証明書とルート証明書の期限まで含めておきます。
二つ目は、自動更新の仕組みです。近年は、ACME（証明書の発行と更新を自動でやり取りする手順）を使い、Let’s Encryptなどの認証局から証明書を自動で取得・更新する方法が広がっています。ACMEは標準の仕様として公開されています。*7人が更新する運用では、担当者の異動や繁忙期に作業そのものが漏れるおそれがあります。自動化しておけば、担当者ごとに更新の手順が違うといった属人化も避けやすくなります。
三つ目は、中間証明書のバンドル配置です。サーバーには、サーバー証明書と中間証明書をまとめた「バンドル」を正しい順序で設置する必要があり、設定が正しいかは外部の検証ツールで確かめられます。納品時のレビュー項目として、外部の検証ツールでの確認と、バンドルに含める証明書を契約書や仕様書に書いておくと、見落としを防ぎやすくなります。
四つ目は、内部PKIを運用する場合の体制です。社内システム同士の通信に、外部の認証局を使わず自前の認証局を運用する企業もあります。この場合は、社内で発行したルート証明書を、対象の社内端末やサーバーにあらかじめ配布しておく必要があります。配布が漏れた社内端末では、社内システムにアクセスしたときに警告が出ます。社外向けサイトの不具合とは原因が違うので、分けて確認します。運用に人を割きにくいなら、外部の認証局に切り替えることも検討できます。
五つ目は、責任の分担です。証明書の取得・更新・監視のうち、どこまでを開発会社が担い、どこからを自社が担うのかを、契約や運用の文書ではっきりさせておきます。分担があいまいなまま運用が始まると、期限が近づいたときに「どちらが更新するのか」で対応が遅れかねません。社内に証明書の管理を専任で担う人を置きにくい場合は、期限切れの通知や中間証明書の設定確認を、運用の仕組みとして委託先に組み込んでもらう方法もあります。
まとめ：証明書チェーンで確かめておきたい3つの点
HTTPSの運用を委託するうえで、証明書チェーンについて確かめておきたい点は3つに整理できます。第一に、中間証明書を正しい順序で設置し、外部の検証ツールでチェーン全体を確かめること。第二に、サーバー証明書だけでなく中間証明書とルート証明書の期限も監視し、ACMEによる自動更新を組み込めるか検討すること。第三に、証明書の取得・更新・監視のどこまでを委託先が担うかを、契約で決めておくことです。この3点を踏まえておけば、「ブラウザでは見られるのに、API連携だけが突然止まった」という事態を避けやすくなります。証明書の運用体制に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
無料の証明書と有料の証明書で、証明書チェーンの仕組みは違いますか
検証の仕組みに違いはありません。どちらもサーバー証明書から中間証明書、ルート証明書へと署名をたどって検証されます。価格帯による違いは、主に証明書に記載される身元確認の厳密さやサポート体制にあります。
証明書の有効期限は、誰が管理するのが現実的ですか
更新を委託先と自社のどちらが担うかと、確認の頻度を、契約や運用の文書にあらかじめ書いておくのが現実的です。自動更新を組み込むか、期限が近づいたら通知が届く体制にしておけば、担当者が異動しても対応しやすくなります。内部PKIを運用している場合は、外部の認証局とは別に、社内のルート証明書についても同じ確認が要ります。
中間証明書の設定漏れには、どうすれば気づけますか
外部の検証ツールで、チェーン全体を実際に確かめる方法があります。サーバーの入れ替えや証明書の更新のたびに設定が崩れることもあるため、変更のつど確認しておくと見落としを防げます。ブラウザで表示できることだけで判断せず、API連携やバッチ処理からの接続も確かめておきます。
証明書運用・システム開発のご相談はLASSICへ
元請（プライムベンダー）として、要件整理からご提案・開発・保守までお手伝いします。まずはお気軽にご相談ください。
Remoguとリラシクなら、証明書の運用監視やサーバーインフラの設計に加わるITエンジニアも探せます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IETF「RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile」（https://www.rfc-editor.org/rfc/rfc5280.html）。出典：証明書と失効リスト（CRL）の仕様、証明書の検証の考え方を参照（2026年9月確認）
- *2 参考：Let’s Encrypt「Chains of Trust」（https://letsencrypt.org/certificates/）。出典：ルート証明書と中間証明書の構成を参照（2026年9月確認）
- *3 参考：株式会社日本レジストリサービス（JPRS）「ルート証明書・中間CA証明書について」（https://jprs.jp/pubcert/service/certificate/）。出典：ルート証明書と中間CA証明書の説明を参照（2026年9月確認）
- *4 参考：MDN Web Docs「トランスポート層セキュリティ (TLS)」（https://developer.mozilla.org/ja/docs/Web/Security/Defenses/Transport_Layer_Security）。出典：TLSの概要を参照（2026年9月確認）
- *5 参考：IPA（独立行政法人情報処理推進機構）「TLS暗号設定ガイドライン（暗号設定対策編）」（https://www.ipa.go.jp/security/crypto/guideline/ssl_crypt_config.html）。出典：TLSの設定に関するガイドラインを参照（2026年9月確認）
- *6 参考：Let’s Encrypt「Deploying Let’s Encrypt’s New Issuance Chains」（https://letsencrypt.org/2024/04/12/changes-to-issuance-chains）。出典：2024年の新しい発行チェーンへの移行と、古い端末との互換性についての説明を参照（2026年9月確認）
- *7 参考：IETF RFC 8555「Automatic Certificate Management Environment (ACME)」（https://datatracker.ietf.org/doc/html/rfc8555）。出典：ACMEの仕様を参照（2026年9月確認）
