はじめに
本記事は、SSL通信で発生する「ssl peer certificate was not ok」エラーについて、原因・対策・事例・トラブルシュート手順をわかりやすく解説します。証明書の期限切れやチェーン不備、自己署名証明書やクライアント証明書の問題、ネットワーク環境の影響など、よくある原因を取り上げます。専門的な説明は必要最低限にし、実務で使える手順を中心にまとめています。
対象読者
- サーバ管理者や開発者、運用担当者向けに書いています。
- SSLの基本は知らないが、問題を解決したい方にも配慮しています。
本記事で学べること（全章の概要）
- 第2章: エラーの意味と発生状況の解説
- 第3章: 主な原因を分かりやすく分類
- 第4章: 具体的な対策と設定例
- 第5章: 実際の事例とその解決法
- 第6章: トラブルシュートの手順（優先順位付き）
- 第7章: 便利なコマンドや参考リンク集
- 第8章: よくある質問（FAQ）
読み方の案内
まず第2章から順に読み、原因が分かれば第4章と第6章で対策を試してください。コマンドは第7章でまとめてあります。専門用語が出る場合は具体例で補足しますので、安心して読み進めてください。
ssl peer certificate was not ok エラーとは
概要
「ssl peer certificate was not ok」は、SSL/TLSで通信するときに相手（サーバー）の証明書検証が失敗したときに出るエラーです。証明書が正しくない、期限切れ、信頼できない発行元、あるいはホスト名が一致しない等の問題を示します。
いつ出るか
- Webブラウザではなくサーバ間通信やAPI呼び出し、curlやプログラムのHTTPクライアントでよく見られます。
- 接続時に証明書の検証を行い、条件を満たさないときにエラーで止まります。
典型的な表示例
- “ssl peer certificate was not ok”
- “certificate has expired”、”hostname mismatch” といった付帯メッセージが出ることがあります。
なぜ問題か
証明書検証は通信相手の正当性と通信の安全性を確保します。検証を無効にすると情報漏えいやなりすましのリスクが高まります。したがって、単に検証を無効化するのではなく原因を調べて適切に対応することが重要です
この章のポイント
エラーは「検証に失敗した」という合図です。次の章で主な原因と具体的な対策を分かりやすく説明します。
主な原因
以下では、ssl peer certificate was not ok が発生する主な原因を分かりやすく説明します。各項目に簡単な確認方法と対処のヒントを付けました。
証明書の有効期限切れ
証明書には有効期限があります。期限切れだと多くのクライアントが接続を拒否します。確認方法：ブラウザの鍵マークや openssl s_client で有効期限を確認。対処：証明書を更新してサーバーに再インストールします。
証明書チェーンの不完全
サーバー証明書だけでなく中間CAが必要です。中間証明書が欠けると信頼チェーンが完成せずエラーになります。確認方法：SSL Labs や openssl verify を利用。対処：中間証明書をまとめて設定します。
自己署名証明書の使用
自己署名証明書は既定で信頼されません。開発・内部用でなければ公開CAの証明書を使うべきです。確認方法：発行者が自分の組織名かどうかを見る。対処：信頼されたCAで発行するか、クライアント側で証明書を信頼する設定を行います。
証明書の発行元が信頼できない
古いCAや未登録のCAで発行された場合、ルートがクライアントに存在しないと信頼されません。確認方法：ルート証明書の一覧と照合。対処：信頼されたCAから再発行するか、クライアントの信頼ストアを更新します。
クライアント証明書の不備
相互TLS（クライアント証明書）を使う環境では、クライアント証明書が不足・期限切れ・誤ったフォーマットだと接続できません。確認方法：サーバーのログやクライアント証明書の有無を確認。対処：正しいクライアント証明書をインストールします。
接続環境の問題
ファイアウォールやウイルス対策ソフト、プロキシが通信を遮断・中継・改変すると証明書が置き換わりエラーになります。確認方法：別ネットワークで接続してみる、プロキシ設定を確認。対処：中継を止めるか、適切な中間証明書を導入します。
具体的な対策方法
証明書の更新・再発行
有効期限切れが最も多い原因です。まずサーバーで現在の証明書の有効期限を確認し、期限切れなら発行元（CA）で更新または再発行してください。たとえばLet’s Encryptは自動更新ツール（certbot）を使うと手間が減ります。
証明書チェーンの確認・修正
中間証明書が不足するとエラーになります。サーバーはサーバー証明書と中間を連結した「fullchain」を返す必要があります。確認には次のコマンドが便利です。
openssl s_client -connect example.com:443 -showcerts
不足していれば、中間証明書を取得してサーバー証明書と連結（catで結合）し、設定を反映してください。
信頼できる認証局の証明書を使用
社内テストで自己署名証明書を使うケースがありますが、運用では信頼されたCA発行の証明書を採用してください。社内専用でも社内CAのルート証明書をクライアントに配布して信頼させる必要があります。
クライアント証明書の設定
クライアント認証が必要な場合は、クライアント証明書と秘密鍵を正しくインポートしてください。ブラウザでは設定画面からインポート、curlでは次のように指定します。
curl --cert client.pem --key client.key https://server/
ファイアウォール・ウイルス対策・プロキシ設定の見直し
企業環境ではプロキシやAVがTLS通信を中継し、独自の証明書に置き換えることがあります。ポート443が適切に開いているか、HTTPS検査（TLS inspection）を無効化するか、プロキシのルート証明書をクライアントに配布して信頼させることを検討してください。
ソフトウェアのアップデート
クライアントやサーバーのTLSライブラリ（OpenSSLやブラウザ、ミドルウェア）に不具合があると接続できません。パッケージを最新に更新し、必要ならサービスを再起動してください。古いOSでは最新の暗号スイートをサポートしないことがあります。
代表的な事例紹介
事例1：開発ツール（Insomnia）での発生
- 症状：macOS上の古いInsomniaでAPI呼び出し時に「ssl peer certificate was not ok」が出る。
- 原因：アプリに組み込まれたSSLライブラリ（OpenSSL互換処理）の挙動とサーバー側の証明書検証方式に不整合があったためです。具体的には新しいTLS仕様や証明書チェーンの扱いに対応していなかったことが多いです。
- 対処：Insomniaをバージョン8.5以上にアップデートしてください。アップデートで内部ライブラリが更新され、問題が解消することが確認されています。
事例2：Unityライセンス再認証時の事例
- 症状：Unityのアクティベーション（再認証）が失敗し、同じエラーが出る。企業ネットワークでよく発生します。
- 原因：ファイアウォールやウイルス対策ソフトがUnityの通信を遮断したり、プロキシが通信を中継して証明書を差し替えたりするためです。
- 対処例：
- ファイアウォールでUnityの通信（通常はHTTP/HTTPS）を許可します。
- 必要に応じてポート80/443の通信を確認します。
- オンラインでできない場合は、Unityの手動アクティベーション（ライセンスファイルの生成・適用）を試してください。
事例3：Kicadプラグインの事例
- 症状：社内プロキシ経由でKicadのプラグインが外部と通信する際にエラーが出る。プロキシで自作（自己署名）証明書を使っている場合が多いです。
- 原因：クライアント側にそのプロキシのルートCAがインストールされておらず、証明書を信頼できないため検証に失敗します。
- 対処：プロキシのルートCAを各クライアントのOSまたはアプリの信頼ストアにインストールしてください。テストとして一時的に検証を無効化できますが、安全性が下がるため推奨しません。
各事例とも、まずはエラーメッセージと環境（アプリのバージョン、ネットワーク経路、プロキシの有無）を確認すると原因特定が早くなります。
トラブルシュートの手順
以下は「ssl peer certificate was not ok」エラーに対する順序立てた点検手順です。順番に進めると原因の切り分けがしやすくなります。
1) 原因特定：エラーメッセージを詳しく見る
– ログや標準出力の全文を確認します。どのホスト・ポートで失敗しているか、TLSハンドシェイクのどの段階で止まっているかを探します。
2) 証明書の検証：opensslでチェーンを確認
– 例：openssl s_client -connect example.com:443 -showcerts
– 証明書が期限切れでないか、発行者が信頼できるか、中間証明書が抜けていないかを確認します。問題があれば検査結果をメモします。
3) サーバー設定の確認・修正
– サーバーの証明書配置（証明書ファイル、中間証明書、秘密鍵）を確認します。
– サーバー証明書のパスやパーミッションを点検し、必要なら再配置や再発行を行います。
4) ネットワーク環境の整備
– 対象ポート（通常443）が開いているか、ファイアウォールやプロキシがTLS接続を中継・改変していないかを確認します。
– 必要ならポート開放やプロキシ設定の変更を行い、再テストします。
5) クライアント側の対応
– クライアントのSSL/TLSライブラリ（例：OpenSSL、curl等）やOSの証明書ストアを最新にします。
– プロジェクトで独自のCAを使う場合は、クライアントに中間証明書やルート証明書を追加します。
6) 再現テストと確認
– 修正ごとに同じ方法で接続確認を行います（curl -v https://example.com など）。
– 正常に接続できればログを保存し、なぜ直ったかを記録します。
必要に応じて、問題箇所のスクリーンショットやコマンド出力を保存して関係者と共有してください。
参考リンク・コマンド
以下は証明書チェーンや接続時の問題を調べる際に役立つコマンドと公式参考リンクです。コマンドは具体的な用途を付けて記載します。
主な確認コマンド
-
証明書チェーン確認（最も基本）:
sh
openssl s_client -connect <ドメイン名>:443 -showcerts
サーバーが送る証明書と中間証明書が確認できます。 -
個別証明書の内容確認:
sh
openssl x509 -noout -text -in cert.pem
PEM形式の証明書を人が読める形で表示します。 -
ローカルで検証する（CAチェーン指定）:
sh
openssl verify -CAfile chain.pem cert.pem -
HTTP(S)接続の詳細確認:
sh
curl -vI https://<ドメイン名>
TLSハンドシェイクや証明書警告を確認できます。
よく見るエラーメッセージ（例）
- “SSL peer certificate or SSH remote key was not OK”
- “unable to get local issuer certificate”
- “NET::ERR_CERT_AUTHORITY_INVALID”
参考リンク（公式/便利）
- OpenSSL: https://www.openssl.org/
- curl: https://curl.se/
- Let’s Encrypt（無料のCA）: https://letsencrypt.org/
- SSL Labs（サーバーの総合診断）: https://www.ssllabs.com/ssltest/
コマンド実行時はドメイン名やファイル名を環境に合わせて置き換えてください。問題の切り分けに役立つ出力例や追加手順が必要でしたら、用途を教えてください。
よくある質問（FAQ）
以下は現場でよく聞かれる質問と簡潔な回答です。実務で試せる対処法も合わせて記載します。
Q1: 自己署名証明書を使っているが、どうすればいい？
A: 本番環境なら信頼できる認証局(CA)が発行した証明書に切り替えてください。開発環境であれば、クライアント側にルートCAをインストールして信頼させるか、一時的に証明書検証を無効化できます（開発以外では推奨しません）。
Q2: 中間証明書が不足している場合の対策は？nA: サーバーに正しい中間CA証明書をバンドルしてもらいます。運用者が使うWebサーバー設定（ApacheのSSLCertificateChainFileやnginxのssl_trusted_certificate）を確認してください。
Q3: ファイアウォールやウイルス対策ソフトが原因の場合は？
A: 一時的に無効化して接続を確認します。無効化できない場合は例外ルールで該当のSSL通信を許可してください。変更は影響範囲を確認してから行ってください。
Q4: 証明書が期限切れの場合は？
A: 新しい証明書に更新してください。更新後はチェーンと有効期間を確認して、古いキャッシュが残っていないかテストします。
Q5: ホスト名と証明書名が一致しない（名前不一致）の対処は？
A: サーバーの証明書を正しいホスト名で再発行するか、接続先を証明書のCN/SANに合わせてください。開発時のみクライアント側でホスト名検証を無効にできます。
Q6: cURLやOpenSSLで検証エラーが出るときは？
A: – cURL: –cacert または –capath で正しいCAを指定して試します。- OpenSSL: openssl s_client -connect host:port -showcerts でチェーンを確認します。
他に気になる点があれば、環境（OS・クライアント・サーバーソフト）を教えてください。より具体的な手順をお伝えします。
