自己署名証明書で起こるssl certificate problemの原因と対策解説

2025 10/27

2025/10/27

はじめに

目的

本ドキュメントは、SSL/TLSに関連する証明書エラー「self-signed certificate in certificate chain」の原因と対処法を分かりやすく解説することを目的としています。専門用語は最小限にし、具体例や手順を交えて説明します。

対象読者

開発者や運用担当者（初心者から中級者）
社内システムの管理者やQAエンジニア
エラーに遭遇したが原因が分からない方

本書の構成と読み方

本書は全8章で構成します。第2章で自己署名証明書の基礎を説明し、第3章で今回のエラーが発生する仕組みを解説します。第4章で具体的な発生例を挙げ、第5章で対処方法を紹介します。第6章ではよくあるミスと注意点をまとめ、第7章で企業運用向けのポイントを述べます。最後に第8章でまとめとおすすめの対応を提示します。

各章は独立して読めるようにしていますが、順に読むと理解が深まります。実際の操作を行う際は、バックアップを取るなど安全に配慮してください。

自己署名証明書（Self-Signed Certificate）とは

概要

自己署名証明書は、信頼できる第三者（認証局＝CA）ではなく、サーバ自身や管理者が自分で署名したSSL/TLS証明書です。見た目は普通の証明書と同じですが、発行元を公的に保証しません。

仕組みをやさしく説明すると

通常はCAがサーバの身元を確認して証明書に署名します。自己署名証明書はその確認をスキップして、サーバ側で鍵と証明書を作り自分で署名します。そのためブラウザやクライアントは発行元を信用できず、警告や接続の拒否が起きます。

よく使われる場面

開発やテスト環境での動作確認
社内の限定されたネットワーク（外部公開しない内部システム）
一時的な検証や試験運用

問題と注意点

自己署名は便利ですが、公開サービスでは危険です。ブラウザ警告により利用者が接続を避けたり、APIやライブラリが接続を拒否したりします。公開するサービスでは、Let’s Encryptなどの信頼できるCA発行証明書を使うことをおすすめします。

エラー「self-signed certificate in certificate chain」の原因

概要

このエラーは、SSL/TLSの証明書チェーン（サーバ証明書→中間CA→ルートCA）の途中に自己署名証明書が含まれているときに発生します。証明書の連鎖が正しく検証できないため、接続側が安全でないと判断します。

主な原因と具体例

証明書チェーンが正規CAで繋がっていない
例：中間CAが抜けていると、ブラウザやクライアントはルートまで遡れず検証に失敗します。Webサーバで中間証明書をまとめて設定する必要があります。
サーバ証明書または中間CAが自己署名になっている
例：開発環境で作成した自己署名証明書を本番にそのまま使うと発生します。公開サービスでは正規のCA発行証明書を使います。
ルートCAがクライアントの信頼ストアに登録されていない
例：企業内独自CAのルート証明書をPCに入れていない場合、検証に失敗します。クライアント側で信頼ルートを追加する必要があります。
証明書の有効期限切れや設定ミス
例：期限切れの中間証明書を返している、または誤った証明書ファイルを指定しているケースです。
証明書の順序が不正
例：サーバがチェーンを正しい順序で送らないと、クライアントがチェーンを構築できずエラーになります。

発生しやすい場面

開発/テスト環境での自己署名利用
社内CAを使うがクライアント設定が漏れている場合
サーバ設定を更新した直後（中間証明書の抜けや順序ミス）

上記を一つずつ確認すると原因の特定が進みます。次章では実際の発生例を紹介します。

具体的な発生例

事例1：ブラウザでの警告

Webサイトにアクセスすると、ブラウザが「この接続は安全ではありません」や「証明書の発行元が信頼されていません」と表示します。内部向けサイトや試験環境で自己署名証明書を使うとよく起こります。ユーザーはアクセスを続けるかどうかを選ぶ画面が出ます。

事例2：Gitやnpmでのエラー

git cloneやnpm installで次のようなエラーが出て処理が止まります。
– SSL certificate problem: self-signed certificate in certificate chain
この場合、リモートのサーバ証明書が信頼できないため通信を拒否します。

事例3：curl、wget、lftpなどのCLIツール

curl -vやwgetで接続すると「SSL: certificate verify failed」やlftpのTLSエラーが出ます。curl例：
curl https://internal.example -v
=> “SSL certificate problem: self-signed certificate in certificate chain”

事例4：Javaや他のランタイムでの例外

Javaアプリでは次のような例外になります。
javax.net.ssl.SSLHandshakeException: PKIX path building failed
ライブラリが証明書の信頼チェーンを検証できないためです。

再現手順（簡単な流れ）

1) 問題のサーバに自己署名証明書を設定する
2) ブラウザまたはCLIでそのホストにアクセスする
3) 上記の警告やエラーメッセージが出る

どのツールでも共通しているのは「信頼できる発行元が見つからない」点です。次章で対処方法を丁寧に説明します。

主な対処方法

正規の証明書への置換

信頼できる認証局（CA）から証明書を取得し、自己署名証明書と置き換えます。例：Let’s Encryptや有償のCAを利用します。取得後は秘密鍵と証明書をサーバに適切に配置し、サービスを再起動してください。

証明書チェーンの整備

サーバ証明書だけでなく中間CA証明書も一緒に配信します。多くの障害はチェーンが不完全なため発生します。nginxやApacheではfullchain（サーバ証明書＋中間証明書）を指定して配置します。

信頼ストアへの証明書登録

閉域網やテスト環境ではルートCAをクライアントの信頼ストアに追加して一時的に解決できます。Windows、macOS、Linuxそれぞれ手順が異なるため、手順書を作成し、管理者のみ実施してください。セキュリティリスクがある点に注意します。

一時的な回避策（非推奨）

証明書検証を無効にすると接続は通りますが、安全性を大きく損ないます。開発・検証時のみ短期間で使用し、本番では絶対に避けてください。例：Node.jsではNODE_TLS_REJECT_UNAUTHORIZED=0となります。

動作確認の手順

opensslやブラウザ、curlで接続してチェーンと期限を確認します。例：openssl s_client -connect host:443 -showcertsで提示される証明書順序を確認してください。問題があればログと設定ファイルを見直します。

よくあるミス・注意点

以下は、実務でよく遭遇するミスと注意点です。具体例を挙げて分かりやすく説明します。

発行元（Issuer）が不正／想定と違う
例：サーバー証明書のIssuerが社内CAではなく自己署名になっていると、クライアントはチェーンを信頼できません。Issuer情報は証明書チェーン全体の信頼に直結します。
用途（Key Usage／Extended Key Usage）が不適切
例：サーバー認証用の拡張がない証明書をHTTPSに使うと、チェーンはあっても接続時に拒否されます。
有効期限切れ
期限切れは即時エラーになります。更新漏れが最も多い原因です。
中間証明書やフルチェーン未設定
例：サーバーに中間CAを設定していないと、クライアントが中間を探せずチェーン構築に失敗します。配布はサーバー側で行います。
ホスト名不一致
証明書のCN/SANに接続先のホスト名が含まれていないと警告になります。
信頼ストアの問題
古いCAバンドルや社内CAをクライアントが信頼していないケースがあります。
一時的な検証無効化（例：検証をオフにする設定）
デバッグでは使っても、本番での無効化は通信の盗聴や改ざんリスクを高めます。運用環境では絶対に避けてください。
証明書と秘密鍵のミスマッチ
鍵が一致しないとサーバーは起動しても正しいTLSが提供できません。

実務上の対策
– フルチェーンをサーバーに設定し、期限は自動更新する。
– opensslやブラウザでチェーンとSANを確認する。
– 検証無効化に頼らず、信頼ストアを整備する。

したがって、問題発見時はチェーン全体と用途、期限、ホスト名の順で確認すると効率的です。

企業システムでの運用ポイント

概要

社内や閉域網で自己署名証明書を使う場合、全クライアントへルート証明書を配布し信頼ストアへ登録する必要があります。外部公開サービスは正規CA証明書を必ず使用し、証明書チェーンの整合性を常時監視・更新してください。

配布と登録方法

大規模環境：Active DirectoryのグループポリシーやMDMで自動配布します。
小規模環境：構成管理ツール（Ansible等）やインストーラーで配布します。
手動配布時は手順書を用意し、ユーザー操作を減らします。

管理と更新

有効期限の追跡を自動化して期限切れを防ぎます。
証明書チェーン、CRL/OCSPの確認を定期実行します。
テスト環境で更新手順を検証してから本番に適用します。

監視・アラート

期限、チェーン不整合、失効を検知する監視を導入します。
定期的なTLSスキャンで外部漏れや設定ミスを早期発見します。

運用上の注意

クライアント側で検証を無効化しないでください。セキュリティリスクが高まります。
プライベートキーは安全に保管しバックアップを厳格に管理します。
役割分担と変更管理を明確にし、インシデント対応手順を定めておきます。

社内教育

証明書の目的と導入手順を分かりやすく文書化し、IT担当者と利用者に周知します。

まとめとおすすめの対応

要点

エラーの本質は「信頼できる証明書チェーンが構築されていない」ことです。自己署名証明書が混入するか、途中の中間証明書が欠けると、接続先を信頼できないと判定されます。最善策は正しいチェーンを用意することです。

優先する対応（順序は実務での優先度）

証明書チェーンを確認する
ブラウザの鍵アイコンやコマンド例（openssl s_client -showcerts -connect example.com:443）で実際のチェーンを確認します。
正規の証明書で再発行・再設定する
公開サイトなら認証局（Let’s Encrypt等）で発行します。社内向けなら内部CAで発行してクライアントに信頼させます。
中間証明書の順序と同梱を確認する
サーバー証明書の後に中間を連結して配置します。順序が誤るとチェーンが崩れます。
クライアント側の信頼済みに内部CAを追加（必要な場合）
OSやJavaのcacerts、Node.jsなど対象に応じてインポートします。具体的な手順は環境に合わせて行ってください。