LASSIC Media らしくメディア

WebサイトへのアクセスをHTTPS化すると、通信の中身は暗号化されます。ただし、それだけでは足りません。暗号化の前提として、「接続している相手が本物かどうか」を確かめる仕組みが組み込まれているのです。アドレスバーに鍵マークが出ていても、証明書の設定に抜けがあると、利用者の環境によっては警告が出たり、システム同士の通信だけが失敗したりすることがあります。こうした不具合は、公開した直後ではなく、認証局側の仕様変更や証明書の更新タイミングをきっかけに表面化することも少なくありません。

この確認の中心にあるのが、証明書チェーンという考え方です。暗号化の方式そのもの（共通鍵暗号と公開鍵暗号の違い）や、システムの権限設計（認証と認可の違い）は、それぞれ別のテーマとして扱われるべき論点です。本記事では取り上げません。ここでは、サーバー証明書の正しさをどう確かめるか、その連鎖の仕組みに絞って、発注担当者やプロジェクトマネージャーが押さえておきたい勘所を整理します。

証明書チェーンとは

証明書チェーンとは、Webサイトのサーバー証明書が信頼できると判断するために、その証明書を発行した認証局の証明書を上位へ順にたどって、信頼の起点（ルート証明書）までつなげた連鎖のことです。

似た響きの概念に「共通鍵暗号と公開鍵暗号の違い」や「認証と認可の違い」がありますが、これらは暗号化の方式や権限の設計を扱うテーマです。本記事はそれらとは別の論点として、通信相手の証明書が本物かどうかをどう確かめるかに絞って解説します。

ブラウザやOSは、通信を始める際にサーバーから証明書の提示を受けます。しかし、証明書を見せられただけでは、それが本物かどうかは分かりません。そこで、証明書に付いている署名を発行元の認証局までさかのぼり、あらかじめ信頼している起点に行き着くかどうかで、正しさを判断するのです。

この一連の確認の道筋を指して「証明書チェーン」と呼びます。「認証パス」や「信頼の連鎖（チェーン・オブ・トラスト）」と呼ばれることもあり、呼び方が違っても指している仕組みは同じだと考えて差し支えないでしょう。認証局（証明書を発行し、その正しさを保証する機関）が階層構造をとることが、この連鎖の前提になっています。

ブラウザのアドレスバーに表示される鍵マークは、通信が暗号化されていることに加え、この検証を通過した証明書が使われていることを示すサインです。マークの有無だけを見て可否を判断するのではなく、その裏側でどのような確認が行われているかを理解しておくと、開発会社との会話がかみ合いやすくなるでしょう。発注担当者にとっては、目に見えない検証の中身そのものよりも、崩れたときにどれほどの影響が生じるかを知っておくことに実務上の価値があります。

二段構えでルート認証局を守る仕組み

証明書チェーンが、なぜわざわざ何段階かに分かれているのか。答えは、ルート認証局が持つ鍵を守り、問題が起きたときの影響を狭く抑えるためです。

仮にルート認証局が世界中のWebサイトへ直接署名する運用だったとしたら、何が起こるでしょうか。その署名に使う秘密鍵が漏えいすれば、被害はインターネット全体に及びかねません。署名という行為の発生回数を減らすほど、鍵が外部へさらされる機会も減らせます。

そこで実際の仕組みでは、ルート認証局は普段の運用を止めた状態で厳重に保管し、日々の証明書発行は「中間認証局」に任せる二段構えを採ります。ルート認証局が自ら手を動かすのは、中間認証局の証明書に一度署名するときだけです。

この構成には、もう一つの利点があります。ある中間認証局で不正な発行や鍵の漏えいが起きても、その中間認証局の証明書だけを失効させれば済み、ルート証明書自体を作り直す必要がありません。失効の影響範囲を、問題が起きた中間認証局の単位に閉じ込められる点こそ、二段構えの値打ちだと言えるでしょう。

実務では、この階層がさらに複数段になっている場合もあります。段数が増えるほど、上位の鍵を直接使う機会は減り、影響範囲を細かく区切りやすくなる一方、検証にたどるべき経路も長くなる点は覚えておきたいところです。

証明書のなかには、認証局を介さず自分自身で署名する「自己署名証明書」もあります。開発環境での検証など限られた用途で使われるものですが、外部の第三者機関が発行したものではないのです。そのため社外向けのWebサイトで使うと、ブラウザは信頼できる連鎖の外にあると判断し、警告を表示します。社外向けのサービスでは、信頼された認証局が発行した証明書を使うことが前提になるのです。発注時にこの二段構えの存在を知っておくと、証明書の価格差や発行元の違いについて、開発会社からの説明を理解しやすくなるでしょう。

サーバー証明書からルート証明書への検証の流れ

証明書チェーンの検証は、Webサイトのサーバー証明書から出発し、ルート証明書に向かって署名をたどっていく作業です。下の図は、その流れを表したものになります。

まず、ブラウザやOSはサーバーから受け取ったサーバー証明書を確認します。この証明書には「どの認証局が発行したか」が記録されており、次にその認証局の証明書、つまり中間証明書をたどります。

中間証明書についても、同じように「どの認証局が発行したか」を確認し、さらに上位の証明書へとさかのぼります。この上位が、あらかじめ端末やブラウザに組み込まれている信頼済みのルート証明書と一致すれば、そこで検証は完了です。

途中でどれか一つでも署名の整合性が崩れていたり、信頼済みのルート証明書へたどり着けなかったりすると、その通信相手は信頼できないと判定されます。ルート・中間・サーバーの三者は、役割がそれぞれ異なるのです。表で整理しました。

署名をたどる確認とあわせて、証明書が期限内に取り消されていないかどうかも見られています。認証局は、漏えいなどの理由で無効にした証明書の一覧を提供しています。個別に問い合わせられる仕組み（OCSP、CRLと呼ばれる失効確認の方法）もあり、ブラウザはこれも参照するのです。署名の連鎖をたどる確認と、失効していないかどうかの確認は、役割の異なる2つのチェックだと捉えておくとよいでしょう。

この検証の仕組みを理解しておくと、システムの構成を決める場面でも役立ちます。社内バッチやAPIサーバーから外部サイトへ接続する場合は、通信ライブラリの対応状況にも注意が要ります。証明書チェーンやOCSPの参照にどこまで対応しているかを、選定の時点で確認しておくとよいでしょう。

よくある不具合と見落としがちな設定漏れ

証明書チェーンの検証は自動で進みますが、途中の設定に抜けがあると、環境によって症状の出方が変わる不具合につながります。代表的なつまずきどころを見ていきましょう。

もっとも起こりやすいのが、サーバー側で中間証明書の設定を忘れるケースです。サーバー証明書の申請時には、対応する中間証明書もあわせてインストールする必要があります。Chrome・Safariなどの主要ブラウザは、不足している中間証明書をAIA（Authority Information Access。証明書に記載された発行元の参照先）という仕組みで別途取得し、検証を続けられる場合が少なくありません。一方、サーバー間のAPI通信で使われるHTTPクライアントや、モバイルアプリに組み込まれた通信ライブラリの一部は、この自動取得に対応していないのです。その結果、「ブラウザで開くと表示できるのに、決済API連携やバッチ処理からのアクセスだけが証明書エラーで止まる」という不具合が起こります。

古いAndroid端末で似た問題が出ることもあります。端末に組み込まれている信頼済みルート証明書の一覧は、OSのバージョンごとに固定されており、後から更新されにくいという事情があるためです。認証局が新しいルート証明書へ切り替えた直後は、旧OSの端末がまだ新しいルートを信頼できず、設置されている中間証明書の内容によって表示が左右されることがあります。

認証局がルート証明書を切り替える際には、旧ルートを信頼している古い端末への配慮が必要になります。新旧どちらのルートからも同じ中間証明書をたどれるようにする「クロス署名」という手法が使われることがあるのです。Let’s Encryptが2024年に新しい発行チェーンへ移行した際の案内では、この配慮にも限界があると説明されています。対象のOSがそもそも新しいルート証明書自体を信頼できない場合は、クロス署名の有無にかかわらず互換性が失われる例が挙げられているのです。ルート証明書の切り替えが予告された際は、自社が対象とする端末・OSの範囲で表示を確かめておくことが望ましいでしょう。

自己署名証明書との違いも押さえておきたい点です。自己署名証明書を社外向けのWebサイトに使うと、ブラウザは信頼できる連鎖の外にあると即座に判断し、分かりやすい警告画面を表示します。一方、中間証明書の設定漏れやルート切り替えの互換性不足は、環境によって症状の出方が異なり、利用者からの問い合わせで初めて発覚することも珍しくないのです。気づきやすさの差を理解しておくと、監視すべき対象の優先順位を付けやすくなります。

ほかにもよく見られるのが、証明書の有効期限切れです。サーバー証明書だけでなく、中間証明書やルート証明書にも有効期間があり、どれか一つでも切れていれば連鎖全体が信頼できないと判定されてしまいます。更新のタイミングを一元管理できていないシステムほど、この見落としが起きやすいでしょう。

さらに見落とされがちなのが、サーバーやクライアント側の時刻のずれです。証明書の検証では、現在時刻が有効期間の範囲内にあるかどうかを照合するため、機器の時刻が大きくずれていると、有効な証明書であっても期限切れとして扱われてしまいます。バッチサーバーやIoT機器のように、時刻同期の仕組みが手薄になりがちな機器で起こりやすい問題と言えます。

証明書を設置する順序を誤るケースも見られます。証明書チェーンは、サーバー証明書に続けて中間証明書という順に並べて設置する必要があります。ソフトウェアによっては、この順序が違うだけで検証に失敗するものがあるのです。サーバーの入れ替えや移行作業の際に、順序が崩れていないかを確認する工程を組み込んでおくと、切り替え時の見落としを防ぎやすくなります。

これらの不具合に共通するのは、「利用者のブラウザでは問題が表面化しにくく、システム同士の連携やAPI呼び出し、特定の端末で先に症状が出る」という点です。監視の対象を利用者向けの画面だけに絞っていると、発見が遅れる原因になります。代表的な症状と原因、確認・対処の関係を表に整理しました。

発注・レビューで押さえておきたい点

証明書チェーンの検証そのものは、ブラウザやOS、通信ライブラリが担う領域です。発注担当者やプロジェクトマネージャーが押さえておきたいのは、運用として何を確認し、どう監視する体制になっているかという点になります。押さえておきたい観点は、大きく五つに整理できます。

1. 更新・監視の仕組みと期限アラート
2. 自動更新（ACME）の仕組みの活用
3. 中間証明書のバンドル配置
4. 内部PKIを運用する場合の体制
5. 契約・体制での責任分界点

更新・監視の仕組みと期限アラートが用意されているか

証明書の有効期限が切れると、Webサイトやシステム間通信が突然利用できなくなり、対外的な信頼にも影響します。期限が近づいたら担当者へ通知が届くアラートの仕組みが備わっているか、開発会社に確かめておきたいところです。監視の対象は、サーバー証明書だけでなく中間証明書・ルート証明書の期限まで含めておく点が要になります。

自動更新（ACME）の仕組みを組み込めるか

近年は、ACME（Automatic Certificate Management Environment。証明書の発行・更新を自動でやり取りする標準プロトコル）を使い、Let’s Encryptなどの認証局から証明書を自動取得・自動更新する仕組みが広がっています。手作業での更新は、担当者の異動や繁忙期に作業そのものが漏れるリスクを伴うものです。自動更新の仕組みを組み込めるかどうかは、証明書関連の運用を内製するか外部に任せるかを判断するうえでの分かれ目になるでしょう。ACMEは、証明書の検証・発行・更新の手続きを標準化したプロトコルとして仕様化されており、Let’s Encrypt以外の認証局でも採用が広がっています。標準化された手順に沿って自動化しておけば、担当者ごとに更新の手順が違うといった属人化も避けやすくなります。

中間証明書のバンドル配置が正しいか

サーバーには、サーバー証明書と中間証明書をまとめた「バンドル」を、正しい順序で設置する必要があります。設定が正しいかどうかは、外部の検証ツールで確かめられます。納品時のレビュー項目として、この確認作業とバンドルの中身を契約や仕様書に明記しておくと、見落としを防ぎやすくなるでしょう。

内部PKIを運用する場合の留意点

社内システム同士の通信に、外部の認証局を使わず自前の認証局（内部PKI）を運用する企業もあります。この場合、内部で発行したルート証明書を、対象となる社内端末やサーバーへあらかじめ配布しておく作業が必要です。配布が漏れた端末では、社外向けのWebサイトとは異なる原因で警告が出るため、社内向けか社外向けかを切り分けて確認する視点が欠かせません。運用に人手を割きにくい場合は、外部の認証局へ切り替える選択肢もあわせて検討する価値があるでしょう。

契約・体制での責任分界点を明確にする

証明書の取得・更新・監視のうち、どこまでを開発会社が担い、どこから先を自社が担うのかは、契約や運用ドキュメントで明確にしておく必要があります。役割があいまいなまま運用が始まると、期限が近づいた際に「どちらが更新するのか」で対応が遅れる事態にもつながりかねません。

これらの確認には、認証局の階層構造への理解と、サーバーの設定・監視体制についての知識の両方が要ります。自社で証明書のライフサイクル管理を専任で担う体制が組みにくい場合もあるでしょう。更新漏れが起きたときの影響範囲を把握したうえで、外部パートナーとの役割分担を検討する選択肢も現実的です。専門の運用パートナーへ任せれば、期限切れの通知や中間証明書の設定確認を仕組みとして組み込め、担当者の異動があっても見落としの芽を早い段階で摘み取りやすくなります。ACMEによる自動更新や内部PKIの運用まで含めて相談できる相手を選んでおくと、証明書まわりの意思決定をまとめて任せやすくなるでしょう。

まとめ

• 証明書チェーンは、サーバー証明書の正しさを認証局の署名を上位へたどって確かめる仕組みである。
• ルート認証局は普段の運用を止めて保管し、日々の発行を中間認証局に任せる二段構えを採る。
• 検証はサーバー証明書、中間証明書、ルート証明書の順にたどり、信頼済みのルートに行き着けば成立する。
• 中間証明書の設定漏れ・有効期限切れ・時刻のずれは、環境によって症状が変わる不具合につながりやすい。
• 発注・レビューでは、更新監視の仕組みと中間証明書の配置、自動更新の有無を確認することが要点となる。
• ACMEによる自動更新や内部PKIの運用可否も、体制づくりを判断するうえでの検討材料になる。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• Wikipedia日本語版「公開鍵証明書」
• Let’s Encrypt「Chains of Trust」
• 株式会社日本レジストリサービス（JPRS）「ルート証明書・中間CA証明書について」
• MDN Web Docs「トランスポート層セキュリティ (TLS)」
• IPA（独立行政法人情報処理推進機構）「TLS暗号設定ガイドライン（暗号設定対策編）」
• Let’s Encrypt「Deploying Let’s Encrypt’s New Issuance Chains」
• IETF RFC 8555「Automatic Certificate Management Environment (ACME)」

Tweet