中間証明書は、Webサイトの証明書と、端末が信頼するルート証明書をつなぐ証明書です。ブラウザはこのつながりなどを確認します。必要な証明書が足りない、期限が切れているといった場合は、接続時に警告が出ることがあります。
昨日まで見られたサイトで、急に「安全な接続ができません」と表示された。そんなとき、「証明書に問題があります」と言われても、何が起きたのか分かりにくいですよね。
まずは、証明書が一枚だけで確認されるわけではない、というところから見ていきましょう。
中間証明書とはサイトとルート証明書をつなぐもの
HTTPSでサイトへ接続するとき、ブラウザは通信相手を確かめます。その確認に使うのが、サイトから提示される「サーバー証明書」です。ドメイン名と、暗号通信の相手を確認するための公開鍵などが記録されています。
ただし、誰かが「私はこのサイトです」と書いた証明書を見せるだけでは、信頼できません。誰が発行したのか、その発行元を信頼できるのかも確認する必要があります。
発行元をたどる「証明書チェーン」
証明書を発行する組織を認証局といいます。ブラウザやOSは、信頼の出発点にする認証局の情報を、あらかじめ持っています。その出発点となるのがルート証明書です。
サイトの証明書からルート証明書まで、発行元の署名をたどる途中で使うのが中間証明書。このつながりを「証明書チェーン」と呼びます。ここでの署名は、発行元が作ったものか、内容が書き換えられていないかを確かめるデジタルの記録です。
ドメイン名と公開鍵などを示す
発行元をたどる途中の証明書
端末側が信頼の出発点として扱う
証明書を確認するつながりの例です。通信の通り道ではありません。中間証明書が複数になることもあり、期限なども確認します。
| 証明書 | この仕組みでの役割 |
|---|---|
| サーバー証明書 | 接続先のドメイン名と公開鍵などを示す |
| 中間証明書 | サイト側の証明書から、信頼の出発点までのつながりを示す |
| ルート証明書 | ブラウザやOSが、検証の出発点として信頼する |
ここで重要なのは、サイトがルート証明書を送ってきたから信頼するのではないという点です。接続する側が、そのルートを信頼していることが必要です。
なぜ中間に証明書を置くの?
認証局では、特に重要なルートの秘密鍵を厳重に保管し、日常のサイト向け証明書の発行を中間の認証局で行う構成が使われます。秘密鍵は、その認証局の署名を作るための重要な情報です。
Let’s Encryptも、ルートの鍵をオフラインで保管し、中間の認証局からサイト向け証明書を発行すると説明しています。また、中間証明書は一枚とは限らず、複数のつながり方がある場合もあります。Let’s Encryptの証明書チェーンの説明
図の三段階は基本をつかむための例です。「インターネット上の三つの施設を、通信が順番に通る」という意味ではありません。
証明書エラーは期限切れ・失効・設定不足などで起きる
サイトの証明書の期限が残っていても、中間証明書の問題で検証に失敗することがあります。セコムも、中間証明書とサーバー証明書の有効期限は別であり、中間側の期限切れに注意が必要だと案内しています。セコムの中間CA証明書に関する説明
似た言葉ですが、「期限切れ」と「失効」は違います。
| 状態 | 何が起きているか |
|---|---|
| 有効期限切れ | 証明書に定められた有効期間が終わった |
| 失効 | 期限内でも、鍵の漏えいなどの理由で有効なものとして扱わないようにした |
| 必要な中間証明書の不足 | サイト側の設定などにより、信頼のつながりを確認する材料が足りない |
| 信頼する認証局の情報の違い | 接続側のOS・ブラウザ・アプリが、そのルートを信頼していないなどの違いがある |
実際の判定方法や、失効情報が反映されるタイミングは、ブラウザやアプリによって異なります。どの環境でも同時に同じエラーが出るとは限りません。
証明書エラーだけで、攻撃されたとは決められない
警告には、サイト側の設定不足や端末の時計のずれなど、いくつもの原因があります。逆に、原因を調べる前に「ただの設定ミスだから大丈夫」と決めることもできません。
証明書の確認は、通信相手を確かめるための仕組みです。警告は、その確認を進められないなどの問題を知らせています。警告が消えてサイトを開けることと、問題の原因を取り除くことは区別しましょう。
なお、証明書の検証が通っても、そのサイトで売っている商品の品質や、運営者の誠実さまで保証されるわけではありません。SSL/TLSが守る通信の範囲と、サービス自体を信頼する判断は別です。
中間証明書の問題で更新が必要になるのはなぜ?
証明書には期限があり、認証局の構成や、端末が信頼する認証局の情報も変わります。安全に接続し続けるためには、サイト側と接続する側の両方で、必要な情報を保つことが大切です。
サイト側は、証明書を一式で確認する
サイト運営者は、サーバー証明書だけでなく、その証明書に合った中間証明書も設定します。更新したサイトの証明書と、以前の中間証明書を組み合わせれば常に動く、とは限りません。
設定を担当する人は、証明書の発行元やサーバー会社の案内に沿って、必要な組み合わせを確認します。ブラウザで一度開けただけでは、ほかの端末やアプリでも正しく接続できる証明にはなりません。
利用する側は、OSやアプリの公式更新を確認する
接続する側が古い情報を持っているために、現在使われている証明書のつながりを確認できない場合もあります。OSやブラウザの公式更新で、信頼する証明書の情報が更新されることがあります。
一方、アプリや、Node.jsのようにプログラムを動かす仕組みは、ブラウザとは別の証明書情報や設定を使う場合があります。「ブラウザを更新したから、すべてのプログラムの問題も直った」とは判断せず、対象製品の案内を確認します。Node.jsの証明書情報に関する公式資料
更新は原因に応じて行うもので、どんな証明書エラーも端末の更新だけで解決するわけではありません。
証明書エラーを無視せず公式案内を確認する
一般の利用者が警告を見たときは、次の順番で確認できます。
- 警告が出た接続では、ログイン情報やカード情報を入力しない。 警告を飛ばす操作を急がない。
- サイトのURL、エラーの文面やコード、発生した時刻を控える。
- 端末の日付・時刻・タイムゾーンが正しいか、公式の更新があるかを確認する。
- サイトの公式なお知らせや問い合わせ先、職場なら管理担当者へ確認する。
Mozillaも、安全な接続の失敗にはサイト・端末・ネットワークなどの原因があり、時計の誤りが証明書の判定に影響すると説明しています。Firefoxの接続警告と確認事項
時計を確認するのは、正しい日時へ直すためです。証明書の期限内に見せかけようと、日付を過去へ戻す対処ではありません。
「検証を無効にすれば直る」は、原因の修正ではない
証明書の検証を無効にしたり、出所の分からない証明書を信頼するよう追加したりすると、通信相手を確かめるための確認を弱めてしまいます。エラーを消す目的だけで行わないでください。職場の管理された端末で証明書の設定が必要な場合は、担当部署の正式な案内を確認します。
暗号化は大切ですが、「誰との通信を暗号化しているか」を確かめることも大切です。中間証明書は、その確認を支える一枚です。
本稿の公式資料の確認日は2026年10月22日です。個別の失効・更新のお知らせは、対象の認証局や製品の最新案内を確認してください。
次に証明書の警告を見たら、**「安全に進むための確認が、どこかで止まっている」**と考えてみてください。無理に通り抜けるより、エラーの内容を控えて確認先へ伝えるほうが、原因の解決につながります。




