SSL Peer Certificate Untrustedエラーの原因と解決方法を徹底解説

2025 10/29

2025/10/29

はじめに

本記事の目的

本記事は「SSL Peer Certificate Untrusted」エラーの原因と対処法を分かりやすく説明することを目的としています。専門的な用語は必要最小限にし、具体例や手順を示して誰でも取り組めるようにします。

この章で読み取れること

エラーの概要と影響範囲
記事全体の構成と各章で扱う内容
事前に用意しておくと便利な情報（サーバーのログ、証明書ファイル、利用しているクライアント情報など）

読者対象

サイト運営者やサーバー管理者
開発者や運用担当者
ブラウザやAPIで接続時に証明書エラーが出た方

全体の流れ（簡単な案内）

第2章でエラーの意味を平易に説明し、第3章で発生原因を整理します。第4章で実際のエラー例とログを示し、第5章で解決策を提示します。第6章はトラブルシューティングの進め方、第7章はセキュリティ面での注意点、第8章はよくある質問をまとめます。

始めに準備を整えてから順を追って確認すると、原因特定と対応が速く進みます。次章から具体的に見ていきましょう。

SSL Peer Certificate Untrustedとは何か？

概要

「SSL Peer Certificate Untrusted」は、通信相手が提示したSSL/TLS証明書をシステムが信頼できないと判断したときに発生するエラーです。多くはサーバーやクライアントの証明書が信頼された認証局（CA）で署名されていない、または証明書チェーンが欠落している場合に起こります。

平易な説明

ウェブサイトやAPIは証明書を使って身元を証明します。相手の証明書に問題があると、通信を安全と判断できません。すると接続を拒否したり警告を出したりします。これは「相手の身分証が信用できない」と同じ意味です。

どんな場面で起きるか（具体例）

ブラウザでサイトに接続した際に警告が出る
curlやwgetでAPIにアクセスするとエラーになる
アプリ間のTLS接続でハンドシェイクが失敗する

何が問題になるか（影響）

重要なデータが送れない、サービスの自動連携が止まる、ユーザーに不安を与えるなどの影響があります。業務システムでは可用性や信頼性に直結します。

簡単な確認手順

証明書の発行元（Issuer）を確認する
証明書チェーンが完全か確認する
証明書の有効期限を確認する
クライアント側で信頼するCAリストに含まれているか確認する

次章では、より具体的な発生原因を詳しく説明します。

主な発生原因

SSL Peer Certificate Untrusted が発生する代表的な原因を、分かりやすく整理します。

1) 自己署名証明書の利用

開発環境や内部システムで自己署名証明書や私的CA発行の証明書を使うと、多くのOSやブラウザはそれを信頼しません。例：ローカルで作った証明書をブラウザで開くと警告が出ます。対処：信頼されたCAの証明書を使うか、クライアント側に私的CAを登録します。

2) 中間証明書・ルート証明書の導入ミス

サーバーが証明書チェーンを正しく送らないと、クライアントは途中で信頼を判断できません。よくあるミスは中間CAの未設定です。確認方法：openssl s_client -connect :443 -showcerts でチェーンを確認します。

3) 証明書の有効期限切れ・ホスト名不一致・誤用

証明書が期限切れ、または証明書のCN/SANに接続先ホスト名が含まれていない場合にエラーとなります。別用途の証明書（例：メール用をHTTPSで使う）も問題です。

4) クライアント側の証明書ストア未登録

必要なCA証明書がクライアント端末やサーバーのストアに登録されていないと信頼できません。企業内の端末やCI環境で起きやすいです。確認方法：OSやブラウザの証明書管理画面でCAが存在するか確認します。

具体的なエラー例とログ

SAP環境での例

エラー例: SSSLERR_PEER_CERT_UNTRUSTED
ログ例:
2025-03-12 10:15:23 ERR /sap/bc/srt/rfc/sap/XYZ SSSLERR_PEER_CERT_UNTRUSTED: SSL handshake failed – peer certificate not trusted (subject=”CN=api.example.com”, issuer=”CN=Untrusted CA”, serial=0x1234)
説明: SAPでは信頼ストアにルート/中間証明書が無いか、有効期限切れ・チェーン不備が原因で発生します。

RStudio / Posit Connect の例

エラー例: “Peer certificate cannot be authenticated with known CA certificates”、”The URL does not appear to belong to a valid server”
ログ例:
2025-04-01T08:05:01Z ERROR deploy: Failed to fetch content: Peer certificate cannot be authenticated with known CA certificates (URL: https://api.example.com)
説明: デプロイ時や外部API呼び出しでCAチェーンが検証できないときに出ます。

Cisco AnyConnect / Firewall の例

表示例: “Untrusted server blocked”、”SSL certificate validation failed: untrusted root”
ログ例:
Apr 10 12:00:00 firewall1 %ASA-3-SSL_CONN_FAIL: SSL handshake failed: untrusted root (CN=vpnhost.example.com)
説明: VPNやファイアウォールは未検証の証明書を標準で遮断します。

ログの読み方（共通ポイント）

タイムスタンプ、プロセス名、エラーコードを確認します。
証明書のSubject／Issuer／シリアル／フィンガープリントを探します。
中間証明書の欠如、ホスト名不一致、期限切れがないかを確認します。

収集のヒント

openssl s_client -connect api.example.com:443 -showcerts で証明書チェーンを取得します。
ブラウザやシステムの信頼ストアとIssuerを比較してください。

次章で具体的な解決手順を順を追って説明します。

主な解決策

1) 正しい証明書チェーンのインストール

サーバーには中間CAやルートCAを含む「フルチェーン」を入れてください。多くの認証局は中間証明書をまとめたファイルを提供します。例：ApacheはSSLCertificateFileにフルチェーン、Nginxはssl_certificateにフルチェーンを指定します。確認はopenssl s_client -connect example.com:443 -showcertsで行います。

2) クライアント側ストアへのCA登録

クライアントが必要なCAを信頼していない場合、OSやアプリ側にCA証明書を追加します。例：Windowsはmmcで「信頼されたルート証明機関」にインポート、Linuxは/usr/local/share/ca-certificates/へ追加してupdate-ca-certificates、Javaはkeytoolでcacertsに登録、SAPはSTRUSTでインポートします。

3) VPNやミドルウェアの設定変更

Cisco AnyConnectなどには「信頼されていないサーバーをブロック」等の設定があります。一時的な検証のために無効化できますが、運用での無効化はセキュリティリスクが高いため推奨しません。

4) 証明書再発行・再インストール

インストール手順やCSRに誤りがある場合は、鍵ペアとCSRを再生成して証明書を再発行し、フルチェーンで改めてインストールしてください。コモンネームやSANが正しいか、有効期限や鍵形式（RSA/EC）を確認します。

5) 基本的なチェックリスト

サーバーの証明書有効期限とチェーン
ホスト名（CN/SAN）の一致
クライアント時刻の同期
中間証明書がサーバーに含まれているか
プロキシやミドルウェアで証明書を置換していないか

これらを順に確認・修正すると多くの「SSL Peer Certificate Untrusted」問題を解決できます。

トラブルシューティングのポイント

確認の順序

トラブル時は順序立てて確認すると早く解決できます。まずは証明書チェーン、次に信頼ストア、最後にログと設定を確認します。

証明書チェーンの確認

ブラウザの証明書表示や以下のコマンドで、サーバーが中間証明書を含めて正しく送っているか確認します。

openssl s_client -connect example.com:443 -showcerts

サーバーが中間証明書を送らないとクライアント側で未検証となります。

信頼ストアの確認

SAP: STRUSTで該当CAが登録されているか確認します。
Windows: 証明書管理ツール(certmgr.msc)でルート/中間CAを確認します。
Linux: /etc/ssl/certs や update-ca-certificates を確認します。
Java: keytoolでcacertsを確認・更新します。

ログ・再現方法

ブラウザの開発者ツール、curl -v、opensslコマンドで再現して原因ログを取得します。SAPならdev_icmログや通信ログを確認します。

よくあるチェック項目

証明書の有効期限
CN/SANのホスト名一致
サーバーがフルチェーンを送信しているか
システム時刻が正しいか
中間CAの未登録や古いCAバンドル

上記を順に確認すると原因特定が速くなります。必要であれば各手順の具体的コマンドや画面操作を補足します。

セキュリティ上の注意

なぜ信頼されていない証明書が危険か

信頼されていない証明書を許可すると、暗号化された通信の相手を正しく確認できなくなります。これにより中間者攻撃（MITM）により通信内容が盗聴・改ざんされるリスクが高まります。例えば、開発環境でcurl -kやブラウザの例外を使うと、意図せず機密情報を漏らす可能性があります。

一時的な例外を許可する場合の注意点

どうしても例外を使う場合は短期間・限定的に留めてください。対象を特定のIPやホストに限定し、例外の期限を明確にします。運用担当者は例外発生時に記録を残し、再発防止策を計画してください。

安全に運用するための具体的対策

正規の証明書を取得・更新する（Let’s Encryptなど自動化が便利です）。
サーバー証明書のチェーンと有効期限を監視し、期限切れを防ぎます。
証明書ピンニングやOCSP/CRLによる失効確認を導入すると信頼性が向上します。

ログと監査

証明書エラーや一時許可の記録を必ず残してください。ログから異常なアクセスや繰り返す例外を早期に検知できます。定期的にログをレビューし、必要ならポリシーを見直します。

ユーザー教育

開発者や運用担当者に証明書の重要性を周知してください。安易に例外を許可しない、警告を無視しない、といった基本ルールを設けます。

よくある質問・FAQ

Q: 自己署名証明書を使いたい場合は？

クライアント側にその自己署名証明書を明示的に「信頼できるCA」として登録すれば、一時的に接続できます。手順はOSやブラウザごとに異なりますが、開発環境や社内限定でのみ使ってください。本番環境では信頼された証明機関（CA）発行の証明書を使うことを強くおすすめします。

Q: 証明書がインストールされているのにエラーが出る？

多くは証明書チェーンの不備（中間CAが欠ける等）です。サーバーが中間証明書を正しく送信しているか、正しい証明書ファイルを設定しているかを確認してください。オンラインのSSLチェッカーや「openssl s_client -connect ホスト:ポート -showcerts」で送信チェーンを確認できます。