はじめに
本記事は「信頼されていない機関によって証明書チェーンが発行されました」というSSL/TLS証明書のエラーについて、丁寧に解説する入門ガイドです。Webブラウザでの警告や、SQL ServerやAPI通信での接続失敗など、さまざまな場面で見かけるこのエラーを対象としています。
目的
この章では、なぜこのエラーが問題になるのかを分かりやすく説明します。原因の見つけ方や対処法を順を追って学べるようにしています。
対象読者
システム管理者、開発者、運用担当者、またはサイト利用者で、証明書のエラーに遭遇した方に向けています。専門知識がなくても理解できるよう、具体例を交えて解説します。
この記事の構成
第2章でエラーの典型的な発生場面を示し、第3章で主な原因を説明します。第4章で証明書チェーンと認証局の仕組みをやさしく解説し、第5章で具体的な対処法を紹介します。第6章はセキュリティ上の注意点、第7章はよくある質問と事例、第8章はまとめです。
読みたい項目から読んでも役立つよう構成しています。まずは第2章でエラーの現れ方を確認することをおすすめします。
エラーの概要と発生する場面
概要
SSL/TLS通信で「証明書チェーンが信頼されていない機関によって発行された」エラーが発生します。つまり、通信相手の証明書を確認する際に、受け側のシステムが証明書を発行した認証局（CA）を信頼していない状態です。証明書自体の改ざんや盗聴を防ぐ仕組みが働かないため、接続を拒否することが多いです。
発生する場面（代表例）
- Webブラウザでサイトにアクセスしたとき（「サイトは安全ではありません」等の警告）
- SQL Serverや他のデータベース接続で暗号化通信を行うとき
- サーバー間通信（APIや内部サービス間のHTTPS）
- curlやwget、opensslコマンドで証明書を検証するとき
典型的なエラーメッセージ
- 「信頼されていない機関によって証明書チェーンが発行されました。」
- “SSL certificate problem: unable to get local issuer certificate”
- “NET::ERR_CERT_AUTHORITY_INVALID”
イメージで説明
想像すると、相手が見せる身分証（証明書）に署名した公的機関（CA）が知られていない、あるいは確認できない状態です。結果として、自分のシステムは相手を信用できず接続を止めます。
エラーの主な原因
概要
エラーの主な原因は複数あります。ここでは初心者にも分かりやすく、それぞれの原因と起き方を具体例で説明します。
1) 自己署名証明書の利用
発行者が自分自身の証明書です。第三者による検証がなく、ブラウザやクライアントは信頼しません。例：社内テスト用Webサイトに自己署名証明書を使うと、ブラウザで警告が出ます。
2) 信頼されていない認証局（独自CAや社内CA）
社内で作ったCAは外部で信頼されません。クライアント側にそのCAの証明書が登録されていないと接続が拒否されます。例：新しい社内サービスにアクセスすると「証明書を信頼できません」と表示されます。
3) 中間証明書の設定漏れ
サーバーが中間証明書を送らないと、ブラウザ側で証明書チェーンが途中で切れます。見た目は有効な証明書でも警告が出ます。例：証明書を更新した際に中間を設定し忘れると発生します。
4) クライアント側の証明書ストアにCA証明書がない
端末の証明書ストアに必要なCAが入っていないと信頼できません。新しい端末やOSを導入した際によく起きます。
5) 証明書の有効期限切れやチェーンの破損
期限切れは最も単純な原因です。チェーンのファイルが壊れていると検証に失敗します。例：自動更新に失敗して期限切れになったサーバーで接続が遮断されます。
各原因は似た症状を出しますが、発生原因を特定すると対処が速くなります。
証明書チェーンと認証局（CA）の仕組み
概要
SSL/TLS証明書は階層（チェーン）で信頼を伝えます。サーバー証明書→中間証明書→ルート証明書とつながり、最終的にOSやブラウザに組み込まれたルート証明書まで到達すると信頼されます。
ルート認証局（CA）とは
ルートCAは最上位の信頼源です。OSやブラウザにあらかじめ入っているので、そこまでつながればブラウザは「信頼できる」と判断します。例えると役所が発行した身分証のような役割です。
中間証明書とは
中間証明書はルートCAとサーバー証明書をつなぐ橋です。ルートCAは直接多数のサーバーに署名しないことが多く、中間を通じて署名を委任します。中間が抜けるとチェーンが途切れて信頼エラーになります。
サーバー証明書とチェーンのつながり
サーバー側は自分の証明書だけでなく、必要な中間証明書も一緒に提示します。提示が不完全だと、クライアントはチェーンを構築できず警告を出します。
チェーンの確認とよくある問題
ブラウザの鍵アイコンで証明書の階層を確認できます。オンラインの検証ツールやサーバー設定のチェックで中間証明書の有無を調べてください。よくある問題は、中間証明書の未設定、古いルートの使用、チェーン順序の誤りです。修正は正しい中間証明書をサーバーに設定することで改善します。
主な対処法
1) 証明書を信頼された発行元から取得・再発行
信頼性のある認証局（CA）から新しい証明書を取得します。期限切れや名前不一致（CN/SAN）の場合は再発行してください。自己署名証明書を使う場合はクライアント側で信頼設定が必要です。
2) 中間証明書をサーバーに正しく設定
多くの不具合は中間証明書が欠けていることが原因です。サーバー証明書と中間を連結したチェーンファイルを使い、サーバー設定で指定します（例: ApacheはSSLCertificateFileにチェーン含むファイルを指定）。
3) クライアント側でCA証明書を信頼リストに追加
社内のCAや自己署名を使う場合は、クライアントの信頼ストアにCA証明書を入れます。Windowsならcertmgr.msc、Linuxなら/etc/ssl/certsに配置して更新します。
4) 証明書チェーンを検証する（opensslの例）
openssl s_client -connect example.com:443 -showcerts でサーバー提示を確認します。ローカル検証はopenssl verify -CAfile chain.pem cert.pemを使ってチェーンが通るか確認します。
5) アプリ・DB（例：SQL Server）の設定確認
SQL Serverでは使用する証明書が「個人」ストアにあるか、名前が一致するか、暗号化ポリシーが適切かを確認します。アプリ設定で証明書パスやTLSバージョンを指定することも重要です。
6) トラブル時の手順例
1) 証明書の有効期限・CN/SAN確認
2) 中間証明書の有無確認
3) opensslで接続検証
4) クライアント信頼ストアにCA追加
5) サーバー・アプリを再起動
注意点
秘密鍵は厳重に保管し、鍵と証明書が一致しているか必ず確認してください。設定変更後はサービスを再起動して反映を確認します。
注意点とセキュリティ上の考慮
概要
自己署名証明書や社内で発行した独自CA証明書は、社内ツールやテスト環境では便利です。ただし限定的な用途以外で使うとリスクが高まります。ここでは注意点と具体的な対策をやさしく説明します。
なぜ注意が必要か
- 信頼されていない証明書は、通信相手の真正性を保証しません。例えば外部から訪れるユーザーは接続先が本物か判別できず、なりすましや盗聴の危険があります。
主なリスクと事例
- 中間者攻撃（なりすまし）：攻撃者が証明書を偽装すると通信内容を抜き取られます。
- 証明書管理の不備：期限切れや秘密鍵漏えいでサービス停止や情報漏えいが起きます。
本番環境での推奨
- 公開されるウェブサイトやAPIは必ず公開CAの証明書を使ってください。ブラウザやOSが自動で信頼するので利用者の安全が保たれます。
運用上の注意点（具体策）
- 鍵の保護：秘密鍵を安全な場所に保管し、アクセスを最小限にしてください。
- 更新と監視：証明書の有効期限を監視し、自動更新を導入します。Let’s Encryptのような自動化サービスが便利です。
- 失効確認：OCSPやCRLで証明書の失効を確認する仕組みを整えてください。
- 限定的な例外：内部ネットワークで自己署名を使う場合は、利用範囲を明確にし、端末の信頼設定を厳格にしてください。
- ログと監査：証明書関連の操作を記録し、不正な変更がないか定期的に確認します。
最後に
本番環境では信頼できる公開CAの証明書を使用し、鍵の管理や更新を怠らないことが安全な運用の要です。
よくある質問・トラブル事例
よくある質問（FAQ）
- Q: curlで「証明書を検証できません」と出ます。どうすればよいですか？
-
A: まずサーバーが中間証明書を正しく返しているかを確認します。サーバー側の設定漏れで中間証明書が欠けると、クライアントはルートCAまで辿れず検証に失敗します。クライアント側では正しいCA証明書を信頼ストアに追加することで解決する場合があります。
-
Q: SQL Serverに接続できません。エラーは証明書関連です。原因は？
-
A: 多くは発行元CAがクライアント側で信頼されていないか、自己署名証明書を使っていることが原因です。証明書の発行元を確認し、必要ならそのCAをクライアントの信頼ストアに登録します。
-
Q: ブラウザで「この接続は安全ではありません」と表示されます。対処は？
- A: 証明書の期限切れ、ドメイン名不一致、または発行元CAの信頼性不足が主な原因です。証明書の有効期限とサブジェクト名を確認してください。
具体的なトラブル事例と対処例
1) curl/API通信のエラー
– 症状: エラー例「unable to get local issuer certificate」
– 原因: 中間証明書の未設定、またはクライアントのCA未登録
– 対処: サーバーで中間証明書をまとめて設定します。短期的にはクライアント側で正しいCAを追加して検証を通すことも可能です。
2) SQL Serverの接続失敗
– 症状: 接続時に証明書検証エラー
– 原因: 自己署名証明書や未信頼のCA
– 対処: 信頼できるCA発行の証明書を利用するか、開発環境では該当CAをクライアントにインポートします。接続先のホスト名と証明書のサブジェクトが一致するかも確認します。
3) ブラウザの警告
– 症状: 警告表示や鍵マークが赤くなる
– 原因: 期限切れ、失効、ドメイン不一致、CA信頼問題
– 対処: 証明書の期限を更新し、サーバーが正しくチェーンを返すか確認します。ブラウザのキャッシュが原因のこともあるので再起動して再確認します。
問題解決のチェックリスト
- サーバーが中間証明書を返しているか
- 証明書の有効期限とサブジェクト名
- クライアントの信頼ストアに必要なCAがあるか
- 開発環境での自己署名利用なら適切に配布しているか
トラブルが続く場合は、該当ログや検証コマンドの出力を用意すると原因特定が速くなります。
まとめ
SSL証明書の信頼性エラーは、証明書チェーンの設定ミスや認証局（CA）の信頼性、証明書の期限切れ、ホスト名不一致、クライアント側の信頼ストア不足などが原因で発生することが多いです。ここでは、現場で実行しやすいポイントをまとめます。
- 公開CAを使う：Let’s Encryptなどの公開CAを利用すると、多くのクライアントにそのまま信頼されます。社内用途でも中間CAの信頼連携を検討してください。
- 中間証明書を正しく配置する：サーバーは中間証明書まで含めて送信します。openssl s_client -showcertsで送信チェーンを確認してください。
- 期限とホスト名の確認：有効期限の自動更新（例：certbot）を導入し、サーバ名と証明書のCN/SANが一致するか確認します。
- クライアントの信頼ストアを点検する：古いOSや社内端末ではルートCAが登録されていないことがあります。必要に応じて更新や配布を行います。
- 時刻同期を保つ：サーバーとクライアントの時計が大きくずれていると検証に失敗します。NTPで同期してください。
- 取り扱いの注意：検証を無効にする回避策は避けてください。調査用に一時的に使う場合も範囲と期間を限定します。
定期的な監視とログ確認で問題を早期発見できます。自分で対応が難しい場合は、証明書やサーバ設定に詳しい担当者やベンダーへ相談することをおすすめします。
