SSL証明書のエラーで、こういうメッセージを見たことはないでしょうか。

unable to get local issuer certificate
self signed certificate in certificate chain
certificate verify failed: unable to get issuer certificate

いずれも「発行元をたどれない」と言っています。

そして厄介なのが、ブラウザでは問題なく見えるのに、コマンドやプログラムからは繋がらないというケースです。「証明書は有効期限内なのに、なぜ？」となります。

原因を理解するには、証明書が1枚ではないことを知る必要があります。

証明書はルート → 中間 → サーバーという鎖（チェーン）になっています。
そして途中の1枚が欠けると、鎖はつながりません。

この記事では、証明書チェーンの仕組みと、実務で起きるトラブルの原因を整理します。

Contents
  1. なぜ証明書は複数枚あるのか
  2. 3種類の証明書
  3. 【最頻出】中間証明書の設定漏れ
  4. 企業ネットワークではもう1つ原因がある
  5. 自己署名証明書とは
  6. 設定漏れを確認する方法
  7. よくある質問
  8. 参考にした主な調査・資料
  9. まとめ

なぜ証明書は複数枚あるのか

そもそも「証明書を信頼する」とは、どういうことでしょうか。

パソコンやスマートフォンには、あらかじめ信頼できる認証局（CA）のリストが組み込まれています。しかし——

「certification paths, are required because a public key user is only initialized with a limited number of assured CA public keys.」
（証明書パスが必要なのは、利用者が限られた数の確実なCA公開鍵しか最初から持っていないためである）
——RFC 5280

手元にあるのは「限られた数」だけです。世界中のすべてのWebサイトの証明書を、あらかじめ端末に持っておくことはできません。

そこで「信頼している相手が保証しているなら信頼する」という連鎖を使います。これが証明書チェーンです。

3種類の証明書

種類 誰のものか どこにあるか
ルート証明書 認証局の最上位 端末やブラウザに最初から入っている
中間証明書 ルートから権限を委ねられた認証局 Webサーバーが送ってくる
サーバー証明書 そのWebサイト自身 Webサーバーが送ってくる

信頼は上から下へ受け渡されます。

  1. 端末はルート証明書を最初から信頼している
  2. ルートが中間証明書に署名している → だから中間も信頼できる
  3. 中間がサーバー証明書に署名している → だからサーバーも信頼できる

この出発点を、RFC 5280はtrust anchor（トラストアンカー）と呼んでいます。

「trust anchor information, describing a CA that serves as a trust anchor for the certification path」
（証明書パスの信頼の起点となるCAを示すトラストアンカー情報）

どうやってつながりを確認するのか

証明書には「誰が発行したか（issuer）」と「誰のものか（subject）」が書かれています。検証する側は、これを突き合わせます。

「Name chaining is performed by matching the issuer distinguished name in one certificate with the subject name in a CA certificate.」
（名前の連鎖は、ある証明書の発行者名を、CA証明書の主体者名と一致させることで行われる）
——RFC 5280

「この証明書の発行者は誰か」→「その発行者の証明書はどれか」を繰り返し、最終的にトラストアンカーへたどり着けば検証成功です。

【最頻出】中間証明書の設定漏れ

実務でもっとも多いのが、このトラブルです。

中間証明書は、Webサーバー側が送る必要があります。ルート証明書は端末が持っていますが、中間証明書は持っていないためです。

ところが、サーバーの設定でサーバー証明書だけを設定してしまうと——

持っているもの 状態
ルート証明書 端末にある ✓
中間証明書 どこにもない ✗
サーバー証明書 サーバーから届く ✓

鎖の真ん中が抜けます。その結果が unable to get local issuer certificate です。

なぜブラウザでは見えてしまうのか

ここが混乱の原因です。

一部のブラウザは、中間証明書が届かなくても自力で取得を試みます。証明書に書かれた情報をもとに、不足分を補ってしまうのです。

その結果、こうなります。

  • ブラウザ：問題なく表示される（補完してくれる）
  • コマンドラインツール・プログラム：エラーになる（補完しない）
  • 古い端末・特定のスマートフォン：エラーになることがある

「ブラウザで見えるから大丈夫」は、確認になりません。API連携やバッチ処理で突然エラーになる、という形で問題が表面化します。

企業ネットワークではもう1つ原因がある

同じエラーでも、原因がまったく違う場合があります。

企業ネットワークでは、セキュリティ機器がHTTPS通信を復号して検査し、会社が発行した証明書で暗号化し直していることがあります（SSLインスペクションとは？企業ネットワークで証明書エラーが起きる仕組み）。

この場合、届く証明書は本物のサーバーのものではなく、会社が発行したものです。会社のルート証明書を信頼していないツールから見れば、やはり発行元をたどれません。

切り分け方

確認 結果 原因
証明書の発行者を見る 公的な認証局の名前 中間証明書の設定漏れの可能性
自社名や社内システム名 SSLインスペクション
社外の回線で試す エラーが出ない 企業ネットワーク側が原因
同じエラーが出る サーバー側の設定が原因

この2つを確認するだけで、原因はほぼ絞り込めます。

ツール別の対処は Gitの場合、AWS CLIの場合 をご覧ください。

自己署名証明書とは

もう1つよく見るのが self signed certificate という言葉です。

これは「発行者と主体者が同じ証明書」——つまり自分で自分を保証している証明書です。

RFC 5280も、トラストアンカーが自己署名証明書の形で提供されうると述べています。

「The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate.」

ルート証明書は、実は自己署名証明書です。最上位には保証してくれる相手がいないためです。

では何が違うのか。

ルート証明書 自作の自己署名証明書
形式 自己署名 自己署名
信頼される理由 端末に最初から入っている 誰も知らない
用途 公開サイト 社内・開発環境

技術的な作りは同じで、違いは「あらかじめ信頼されているかどうか」だけです。

社内システムで自己署名証明書を使う場合、その証明書を各端末の信頼リストに追加する必要があります。追加せずに「エラーを無視する」設定にしてしまうと、本物の攻撃も見分けられなくなります。

設定漏れを確認する方法

公開サーバーであれば、SSL/TLSの設定を診断するオンラインツールが複数公開されています。証明書チェーンが正しく設定されているかを確認できます。

コマンドで確認する場合は、次のような方法があります。

openssl s_client -connect example.com:443 -showcerts

返ってきた証明書の一覧に中間証明書が含まれているかを確認します。サーバー証明書だけしか返らない場合、設定漏れの可能性があります。

※企業ネットワーク内から実行すると、SSLインスペクションによって書き換えられた証明書が返ります。サーバー側の設定を確認したい場合は、社外の回線から実行してください。

証明書の更新時に起きやすい

このトラブルは証明書の更新作業のあとに起きがちです。サーバー証明書だけを差し替え、中間証明書を更新し忘れるためです。

認証局が中間証明書を切り替えることもあるため、更新のたびに、証明書一式が正しく設定されているかを確認してください。

よくある質問

Q. 有効期限は切れていないのにエラーが出ます

期限は証明書1枚ごとにあります。サーバー証明書が有効でも、中間証明書やルート証明書の期限が切れていればエラーになります。

実際、過去には広く使われていたルート証明書の期限切れによって、世界中で古い端末の接続がエラーになる事象が起きています。

Q. 中間証明書はどこで入手しますか？

証明書を発行した認証局が配布しています。発行時のメールや管理画面から入手できます。

ファイル名は「intermediate」「chain」「bundle」といった語を含むことが多くなっています。

Q. 「証明書チェーン」と「証明書パス」は違うものですか？

ほぼ同じ意味で使われます。RFC 5280では certification path という表現が使われ、実務では「チェーン」と呼ばれることが多い、という違いです。

Q. 無料の証明書でも仕組みは同じですか？

同じです。有料・無料にかかわらず、ルート → 中間 → サーバーというチェーンで検証されます。

暗号化の強度にも差はありません。違いは主に、保証内容やサポート、認証の厳格さ（組織の実在確認を行うかなど）にあります。

Q. 社内サーバーにも証明書は必要ですか？

社内であっても、通信内容を保護する意味は変わりません。「社内だから安全」という前提を置かないのが、現在のセキュリティの考え方です（ゼロトラストとは？VPNとの違いと中小企業での現実解）。

Q. エラーを無視する設定にしてはいけませんか？

恒久的な設定にはしないでください。証明書の検証は、通信相手が本物かを確かめる唯一の手段です。

切り分けのために一時的に使うことはあっても、設定として残すと本物の攻撃を検知できなくなります。

参考にした主な調査・資料

※RFCの引用は原文（英語）からの抜粋で、和訳は本記事によるものです。サーバーの設定手順は製品によって異なります。実際の作業前に、証明書を発行した認証局のドキュメントをご確認ください。

まとめ

  • 証明書はルート → 中間 → サーバーという鎖になっている
  • 端末は「限られた数の」ルート証明書しか持っていない（RFC 5280）。だからチェーンが必要
  • 検証は「発行者名」と「主体者名」を突き合わせて行われる
  • 中間証明書はサーバー側が送る必要がある。設定漏れが最頻出のトラブル
  • ブラウザは中間証明書を補完することがある。「ブラウザで見えるから大丈夫」は確認にならない
  • 企業ネットワークではSSLインスペクションが同じエラーを起こす。発行者名を見れば区別できる
  • ルート証明書も自己署名証明書。違いは「あらかじめ信頼されているか」だけ
  • 証明書の更新時は中間証明書もあわせて確認する

証明書エラーは「よく分からないから無視する」対象になりがちです。

しかし鎖のどこが切れているのかが分かれば、対処は明確になります。まずは発行者名を確認するところからです。

Post Views: 57
ネットワーク 技術解説