Claude Code「SSL certificate verification failed」の意味と対処法|企業プロキシの証明書
Claude Code の「API Error: Unable to connect to API: SSL certificate verification failed. Check your proxy or corporate SSL certificates」の意味と直し方。企業の TLS 検査プロキシの CA を NODE_EXTRA_CA_CERTS で信頼させる手順、openssl での確認方法、SSL certificate has expired などの派生メッセージを実機出力つきで解説します。

API Error: Unable to connect to API: SSL certificate verification failed. Check your proxy or corporate SSL certificates
# v2.1.273 以降の表示(原因コードとヒントが追加)
API Error: Unable to connect to API: SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). The certificate comes from an authority Claude Code doesn't trust, usually a TLS-inspecting corporate proxy or a gateway signed by a private CA: set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store · see https://code.claude.com/docs/en/network-config
このメッセージは、Claude Code が接続先から受け取った TLS 証明書を信頼できなかったため、API に接続しなかったという意味です。多くの場合、会社のネットワークにある TLS 検査プロキシ(通信を復号して中身を検査する装置)が独自の証明書で通信を差し替えています。IT 部門からプロキシのルート CA 証明書(PEM ファイル)を受け取り、NODE_EXTRA_CA_CERTS にそのパスを設定して Claude Code を起動し直せば解消します。
上の2つは同じエラーの新旧の表示です。v2.1.273 より前は、どの原因でも末尾が Check your proxy or corporate SSL certificates でしたが、v2.1.273 以降は原因のコード(UNABLE_TO_GET_ISSUER_CERT_LOCALLY など)と NODE_EXTRA_CA_CERTS のヒントが入るようになりました(Error reference)。古いバージョンを使っていると原因のコードが表示されないので、claude --version で確認し、可能なら更新すると切り分けが楽になります。この記事は、2026年9月25日時点(Claude Code v2.1.282)の公式ドキュメントと、テスト用サイトで実際に再現した出力をもとにしています。実機で確認した内容とドキュメント記載の内容は書き分けています。
この記事を読むとわかること
- このエラーが出る仕組みと、出る場面
SSL certificate has expired・Self-signed certificate detectedなど派生メッセージごとの原因- 誰が証明書を発行しているかを
opensslで確かめる方法 NODE_EXTRA_CA_CERTSと OS の証明書ストアの使い分け(macOS・Linux・Windows)NODE_TLS_REJECT_UNAUTHORIZED=0を使ってはいけない理由- 管理者が組織全体に設定を配る方法
このエラーの意味と出る場面
公式ドキュメントでは、このエラーの原因を「ネットワーク上のプロキシやセキュリティ機器が自前の証明書で TLS 通信を傍受しており、Claude Code がそれを信頼していない」と説明しています(SSL certificate errors)。社内のゲートウェイがプライベート CA で署名された証明書を使っている場合も同じです。
- 出る場面:ターミナルの
claude、claude -pなどで API にリクエストを送ったとき - ログインや初回の接続確認のときは別の文面:
/loginと起動時の接続確認では、このリストの下に示す文面で表示されます - 再試行されない:v2.1.199 以降、証明書の検証エラーは再試行せずに最初の1回で表示されます。それより前は数分再試行してから表示されていました
- Amazon Bedrock でも関係する:Claude Code が AWS へ送るリクエスト(STS や SSO の認証情報の取得、モデル一覧の取得など)も同じ証明書設定を使います
SSL certificate error (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). If you are behind a corporate proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA bundle path, or ask IT to allowlist *.anthropic.com. Run `claude doctor` for details.
メッセージ別の原因と直し方
Unable to connect to API: の後ろの文面で、原因が分かれます。実機での再現状況は後述の「実機での再現結果」にまとめました。
表示(Unable to connect to API: の後ろ) | 主な原因 | 直し方 |
|---|---|---|
SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT_LOCALLY) | TLS 検査プロキシ、プライベート CA のゲートウェイ | CA を NODE_EXTRA_CA_CERTS か OS の証明書ストアへ |
SSL certificate verification failed (UNABLE_TO_VERIFY_LEAF_SIGNATURE) | 中間証明書が送られてこない、または信頼できない発行元 | 同上。自社ゲートウェイなら中間証明書の設定を見直す |
Self-signed certificate detected (SELF_SIGNED_CERT_IN_CHAIN) | 信頼されていないルート CA(TLS 検査プロキシで典型的) | 同上 |
Self-signed certificate detected (DEPTH_ZERO_SELF_SIGNED_CERT) | 接続先そのものが自己署名証明書 | その証明書(または発行元 CA)を信頼させる |
SSL certificate has expired | 接続先かプロキシの証明書の期限切れ、PC の時計のずれ | 時計を確認し、証明書の管理者に更新を依頼 |
SSL certificate is not yet valid | PC の時計が遅れている、発行直後の証明書 | 時計を合わせる |
SSL certificate hostname mismatch | 接続先の URL と証明書の名前が一致しない | ANTHROPIC_BASE_URL やプロキシの設定を確認 |
証明書には有効期間(開始日時と終了日時)があり、検証する側の時計で判定されます(RFC 5280 4.1.2.5)。「expired」や「not yet valid」が出たら、まず PC の日時が正しいかを確認してください。
対処法
1. 誰が証明書を発行しているか確かめる
TLS 検査プロキシが間にいるかどうかは、openssl で API ホストの証明書の発行元を見るとわかります。Claude Code を使うのと同じネットワークで実行してください。
echo | openssl s_client -connect api.anthropic.com:443 -servername api.anthropic.com -showcerts 2>/dev/null | grep -E "s:|i:|Verify return code"
2026年9月25日に筆者の環境(プロキシなしの直接接続)で実行したところ、発行元(i:)は Google Trust Services で、Verify return code: 0 (ok) でした。ここに会社名やセキュリティ製品の名前が出る場合、プロキシが通信を差し替えています。プロキシを使う設定の環境では、openssl s_client に -proxy ホスト:ポート を付けないとプロキシを経由しないことがあります。
公式ドキュメントも、直接接続で試してプロキシが原因かを確かめる方法を挙げています(Troubleshoot installation and login)。
2. CA 証明書を NODE_EXTRA_CA_CERTS で指定する
プロキシのルート CA 証明書(PEM 形式)を IT 部門から受け取り、そのパスを NODE_EXTRA_CA_CERTS に設定します(Network configuration)。
macOS・Linux:
export NODE_EXTRA_CA_CERTS=/path/to/corporate-ca.pem
claude
Windows PowerShell:
$env:NODE_EXTRA_CA_CERTS = 'C:\path\to\corporate-ca.pem'
claude
シェルで設定した環境変数は起動時に一度だけ読まれるため、実行中のセッションには反映されません。設定したら Claude Code を起動し直してください。毎回設定したくない場合は、~/.claude/settings.json の env ブロックに書くこともできます(ネットワーク設定の環境変数はすべて settings.json でも設定できると公式ドキュメントに記載があります)。
{
"env": {
"NODE_EXTRA_CA_CERTS": "/path/to/corporate-ca.pem"
}
}
証明書ファイルが手元にない場合、プロキシがチェーンにルート CA を含めて送ってくる環境(SELF_SIGNED_CERT_IN_CHAIN のとき)なら、-showcerts の出力から取り出すこともできます。ただし、それが本当に自社のプロキシの CA かは IT 部門に確認してください。見知らぬ CA を信頼すると、その CA を持つ第三者に通信を読まれるおそれがあります。
3. OS の証明書ストアに入っているのに失敗する場合
公式ドキュメントによると、Claude Code は同梱の Mozilla の CA 一式と、OS の証明書ストアの両方を既定で信頼します(CA certificate store)。会社が OS の証明書ストアにプロキシのルート CA を配布していれば、通常は追加設定なしで動きます。それでも失敗する場合は、次を確認します。
- npm でインストールしていて Node.js が古い:OS のストアを読むには Node 22.15 以降が必要です。それより古い Node では、同梱の CA と
NODE_EXTRA_CA_CERTSしか使われません(ネイティブインストーラー版は常に読めます) CLAUDE_CODE_CERT_STOREを変更している:既定値はbundled,systemです。bundledだけにすると OS のストアを見ません- Claude Code が古い:OS の証明書ストアを既定で信頼するようになったのは v2.1.101 です(CHANGELOG)
インストール方法ごとの違いはインストールと初期設定ガイドを参照してください。
4. 設定が読み込まれたか確かめる
公式ドキュメントでは、claude --debug で起動してデバッグログ(~/.claude/debug/ 以下)を見る方法が案内されています。証明書ファイルを読み込めていれば、次のような行が出ます。
CA certs: Appended extra certificates from NODE_EXTRA_CA_CERTS (/etc/ssl/certs/corp-ca.pem)
読み込めなかった場合は Failed to read や Failed to load の行に理由が出ます。セッション内の /status にも Additional CA cert(s) としてパスが表示されますが、こちらはファイルが読めたかどうかまでは確認していないため、ログで確かめるのが確実です(Verify your configuration)。
証明書の検証を無効にしない
検索すると、NODE_TLS_REJECT_UNAUTHORIZED=0 を設定して検証を止める方法が見つかることがあります。公式ドキュメントは、この設定は証明書の検証を完全に無効にするため使わないようにと明記しています(SSL certificate errors)。
検証を止めると、通信経路にいる誰でも Claude Code の接続先になりすませるようになり、送信する API キーやソースコードを読まれる危険があります。正しい CA を1つ追加すれば済む問題なので、検証そのものを止める必要はありません。
実機での再現結果(v2.1.282)
2026年9月25日、macOS 上の Claude Code v2.1.282 で、偽の API キー(sk-ant-fake-test)と、証明書の検証テスト用に公開されている badssl.com のホストを ANTHROPIC_BASE_URL に指定して claude -p hi を実行しました。本物の認証情報は使っていません。
| 接続先 | 表示されたメッセージ(先頭の API Error: Unable to connect to API: を省略) |
|---|---|
self-signed.badssl.com | Self-signed certificate detected (DEPTH_ZERO_SELF_SIGNED_CERT). The certificate comes from an authority Claude Code doesn't trust, … |
untrusted-root.badssl.com | Self-signed certificate detected (SELF_SIGNED_CERT_IN_CHAIN). The certificate comes from an authority Claude Code doesn't trust, … |
incomplete-chain.badssl.com | SSL certificate verification failed (UNABLE_TO_VERIFY_LEAF_SIGNATURE). The certificate comes from an authority Claude Code doesn't trust, … |
expired.badssl.com | SSL certificate has expired |
wrong.host.badssl.com | SSL certificate hostname mismatch |
いずれも1〜3秒で表示され、終了コードは1でした。再試行による待ち時間はなく、ドキュメントの「最初の1回で表示」と一致しています。… の部分はすべて set NODE_EXTRA_CA_CERTS to that CA bundle, or add it to the system certificate store · see https://code.claude.com/docs/en/network-config という共通のヒントでした。一方、期限切れとホスト名の不一致には、このヒントは付きませんでした。
次に、untrusted-root.badssl.com のルート CA を openssl s_client -showcerts の出力から取り出し、NODE_EXTRA_CA_CERTS に指定して同じコマンドを実行しました。証明書のエラーは消え、テスト用サイトが API ではないためにモデルのエラー(There's an issue with the selected model)が返りました。TLS の接続そのものは通るようになった、ということです。
SSL certificate is not yet valid は再現できる公開テスト用ホストがなかったため、v2.1.282 の実行ファイルにこの文字列が含まれていることだけを確認しました。UNABLE_TO_GET_ISSUER_CERT_LOCALLY の表示と、ログイン時の SSL certificate error の表示は再現していません(ドキュメント記載の文面です)。
似ているが別のエラー
| メッセージ | 違い |
|---|---|
Unable to connect to API. Check your internet connection、Connection refused …、Couldn't connect through your proxy (ERR_PROXY_TUNNEL) など | 証明書ではなく、接続そのものが失敗している。curl -I https://api.anthropic.com で到達確認し、HTTPS_PROXY を設定する |
curl: (35) TLS connect error、Could not establish trust relationship for the SSL/TLS secure channel | インストール時のエラー。インストーラーのダウンロードに CA を渡す(curl --cacert) |
unable to get local issuer certificate(Bedrock のモデル確認や認証情報の取得) | TLS検査プロキシのCAを信頼できていない(v2.1.261より前はBedrockまわりのリクエストがOSの証明書ストアを見ない不具合もあった)。更新する |
HTTP 403 と x-deny-reason: host_not_allowed | Web 版のクラウドセッションのネットワーク制限。手元の PC の問題ではない |
出典は Error reference、Troubleshoot installation and login、Claude Code on Amazon Bedrock です。Bedrock 利用時に認証情報そのものが見つからない場合はCould not load credentials from any providers の対処法を、エラー全般はClaude Code トラブルシューティング完全ガイドを参照してください。
管理者向け:組織全体に設定を配る
社内で Claude Code を展開する場合は、一人ひとりのシェルに環境変数を設定してもらうより、設定ファイルで配るほうが確実です。公式ドキュメントには、次の注意点が記載されています(Network configuration)。
- Claude Desktop:アプリが接続先を管理するセッション(サードパーティ提供元の Code タブや Cowork)では、
NODE_EXTRA_CA_CERTSやプロキシの環境変数を managed settings と~/.claude/settings.jsonからしか読みません。リポジトリ内の設定ファイルに書いても無視されます - バックグラウンドエージェント:
claude agentsや--bgのセッションは、シェルとは別のプロセスで動きます。シェルで export しただけの証明書やプロキシの設定は届かないことがあるため、~/.claude/settings.jsonか managed settings のenvブロックに書きます - 許可する通信先:
api.anthropic.com・claude.ai・platform.claude.comなどを、プロキシとファイアウォールで許可しておきます(Network access requirements)
TLS 検査の対象から Anthropic のホストを外すか、CA を配布するかは、社内のセキュリティ方針によります。導入全体の設計はClaude Code の企業導入ガイドとセキュリティ設計ガイドで解説しています。
よくある質問
まとめ
- このエラーは、接続先の TLS 証明書を Claude Code が信頼できなかったという意味。多くは会社の TLS 検査プロキシが原因
openssl s_clientで発行元を見れば、プロキシが間にいるかわかる- プロキシのルート CA を
NODE_EXTRA_CA_CERTSに指定し、Claude Code を起動し直す。OS のストアでもよい(npm 版は Node 22.15 以降) expired・not yet validはまず PC の時計を確認する。hostname mismatchは接続先の URL を確認するNODE_TLS_REJECT_UNAUTHORIZED=0で検証を止めてはいけない
koromo からの提案
AIツールの導入判断は、突き詰めると「投資対効果が合うか」「リスクを管理できるか」「事業にどう効くか」の3点に帰着します。koromo では、この判断に必要な材料を整理するところからご支援しています。
以下のような状況にある方は、まず現状の整理だけでも前に進むきっかけになります。
- AIで開発や業務を効率化したいが、自社に合う方法がわからない
- 社内にエンジニアがいない / 少人数で、AI導入の進め方に見当がつかない
- 外注先の開発会社にAI活用を提案したいが、何を求めればいいか整理できていない
- 「AIを使えばコスト削減できるはず」と感じているが、具体的な試算ができていない
ツールを使った上で相談したい方はお問い合わせフォームから「Claude Code の社内ネットワーク対応の相談」とご記載ください。初回の壁打ち(30分)は無料で対応しています。
無料で相談する

