0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@homhom44(ホムホム ホムホム)

Claude Code で "Self-signed certificate detected" / "SSL certificate verification failed" が出たときの直し方（社内プロキシと NODE_EXTRA_CA_CERTS）

0
Posted at

Claude Code で Unable to connect to API: Self-signed certificate detected や Unable to connect to API: SSL certificate verification failed が出たときの直し方です。結論から言うと、会社のプロキシなどが TLS の通信を検査して自前の証明書に差し替えていて、Claude Code がその発行元（CA）を信頼していないことが原因です。その CA の証明書ファイルを NODE_EXTRA_CA_CERTS で渡せば通ります。

確認環境は Claude Code 2.1.318、macOS 26.6、2026-11-06 です。

症状

次のような表示が出て、以降の依頼が通りません。

API Error: Unable to connect to API: Self-signed certificate detected (SELF_SIGNED_CERT_IN_CHAIN). 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

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

上の 2 つは公式の Error reference に載っている文言です。かっこ内のコードは状況で変わります。後で書くとおり、私の手元では DEPTH_ZERO_SELF_SIGNED_CERT と UNABLE_TO_VERIFY_LEAF_SIGNATURE が出ました。

ログイン時や起動時の接続確認では、同じ原因で別の文言になります。

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.

古い版（公式によれば v2.1.273 より前）では、どちらも Check your proxy or corporate SSL certificates で終わり、OpenSSL のコードも NODE_EXTRA_CA_CERTS の案内もありませんでした。古い文言で検索してきた方は、更新すると手がかりが増えます。

結論

  • 原因は、通信の途中にいる装置（社内プロキシ、セキュリティ製品など）が、Claude Code の知らない CA で署名した証明書を返していること
  • 直し方は、その CA の証明書（PEM 形式）を入手して、NODE_EXTRA_CA_CERTS=/path/to/ca-bundle.pem を付けて起動すること
  • NODE_TLS_REJECT_UNAUTHORIZED=0 で黙らせるのは避けます。公式が「証明書の検証を丸ごと無効にする」ので使わないよう明記しています

原因

会社のネットワークによっては、外向きの HTTPS を一度プロキシが受けて中身を検査し、自分の CA で署名した証明書を作って、クライアントに見せ直す構成があります（TLS 検査、いわゆる中間者方式です）。ブラウザは、社内 PC に配られた社内 CA を信頼しているので気づきません。一方、Claude Code は OS やブラウザとは別に、自分が持つ信頼リストで検証します。そのため、社内 CA の署名だけが「知らない発行元」として弾かれます。

公式の説明も同じで、「ネットワーク上のプロキシかセキュリティ機器が自前の証明書で TLS を横取りしていて、Claude Code はそれを信頼していない」という書き方です。

issue では、社内プロキシ（TLS 検査）越しで出たという報告が複数あります。

手元で確かめたこと

本物の社内プロキシは用意できないので、同じ状況を手元で作りました。

  1. ダミーの「社内ルート CA」を openssl で作る
  2. その CA で署名したサーバ証明書を持つ HTTPS サーバを 127.0.0.1:8443 で立てる
  3. ANTHROPIC_BASE_URL=https://127.0.0.1:8443 と、ダミーの ANTHROPIC_API_KEY で claude -p hi を実行する

設定ディレクトリは CLAUDE_CONFIG_DIR で空のものに切り替え、外部には何も送っていません。

証明書を信頼していない状態と、CA を渡した状態

1 回目は CA を渡さずに実行し、証明書の検証エラーで止まりました。2 回目は NODE_EXTRA_CA_CERTS に社内 CA の PEM を指定したところ、TLS は通り、先に進んで（ダミーサーバが返した 500 を表示して）終わりました。つまり、NODE_EXTRA_CA_CERTS を付けるだけで証明書の壁は越えられます。

ほかにも次のことが分かりました。

  • 自己署名の証明書を直接返すサーバに繋ぐと、Self-signed certificate detected (DEPTH_ZERO_SELF_SIGNED_CERT) になります。公式の例にある SELF_SIGNED_CERT_IN_CHAIN とは、コードが違うだけで同じ種類の問題です
  • CA が署名した証明書を返すサーバだと、2.1.318 では SSL certificate verification failed (UNABLE_TO_VERIFY_LEAF_SIGNATURE) になり、「中間証明書が抜けているサーバなら、運用者がフルチェーンを送るべき」という説明も付きました。公式ドキュメントの例文より少し長い文言です
  • NODE_EXTRA_CA_CERTS に存在しないパスを渡すと、Warning: Ignoring extra certs from ...., load failed: No such file or directory という警告が先に出て、同じ検証エラーが続きます。パスの打ち間違いは、この警告で気づけます
  • 参考までに NODE_TLS_REJECT_UNAUTHORIZED=0 でも通りました。ただし検証を丸ごと切っているので、中間者に差し替えられても気づけません。試す価値はなく、勧めません

なお、実際の社内プロキシ（Zscaler など）での挙動や、システムの証明書ストアを使う設定は、手元では確認していません。

直し方

1. 社内 CA の証明書（PEM）を入手する

一番確実なのは、情報システム部門に「TLS 検査に使っているルート CA の PEM ファイルをください」と頼むことです。公式の troubleshoot-install でも、ファイルを持っていなければ IT 部門に聞くよう案内されています。

自分の Mac で探すなら、キーチェーンアクセスで社内 CA を見つけて、PEM でエクスポートする方法があります。コマンドなら、次のような形です（"Your Corp Root CA" は自分の組織の CA の名前に読み替えます。このコマンドは今回手元では試していません）。

security find-certificate -a -p -c "Your Corp Root CA" /Library/Keychains/System.keychain > ~/corp-ca.pem

2. 環境変数を付けて起動する

macOS / Linux です。

export NODE_EXTRA_CA_CERTS=/path/to/corp-ca.pem
claude

Windows PowerShell です。

$env:NODE_EXTRA_CA_CERTS = 'C:\path\to\corp-ca.pem'
claude

公式の troubleshoot-install にある書き方と同じです。毎回打たなくて済むよう、~/.zshrc などの設定ファイルに export の行を足しておくと便利です。

3. 直ったか確認する

新しいターミナルで claude を起動し、何か 1 つ依頼して、証明書のエラーが出なくなれば完了です。直らなければ、パスが正しいか（先ほどの Ignoring extra certs の警告が出ていないか）を見ます。

直らないとき

  • 渡したのが、ルート CA ではなく自分のサーバ証明書だけになっていませんか。プロキシが使っている CA の証明書を渡す必要があります。中間 CA がある構成では、IT 部門に、ルートと中間をまとめた 1 つのバンドルを頼むのが早いです
  • そもそもプロキシ経由でしか外に出られない環境なら、HTTPS_PROXY の設定も要ります。公式の Error reference に、社内プロキシ越しなら HTTPS_PROXY を設定する、という案内があります。なお、ターミナルから起動したプロセスは macOS のシステムのプロキシ設定を引き継がない、という整理を issue の調査で見かけました。network-config のページで確認してください
  • ログイン時の文言には、IT 部門に *.anthropic.com を許可してもらう、という案内も入っています
  • OS の時計が大きくずれていても、証明書の検証は失敗します。これは推測ですが、念のため確認する価値はあります
  • システムの証明書ストアを使わせる設定（CLAUDE_CODE_CERT_STORE や NODE_USE_SYSTEM_CA）の名前が、2.1.316 の実行ファイル内の文字列にあります。ただし、公式ドキュメントで確認できたわけではなく、版によって失敗した報告（issue #69387）もあります。まずは NODE_EXTRA_CA_CERTS を試してください
  • Amazon Bedrock を使う場合、AWS への通信（STS や SSO など）も同じ証明書設定に依存する、と公式にあります

同じ原因で出る別のメッセージ

  • ネイティブ版のインストーラ段階では、TLS connect error や unable to get local issuer certificate が出ます。公式の対応表では、CA 証明書の更新か社内 CA の設定が案内されています
  • 証明書ではなく、プロキシに繋がらない場合は、Couldn't connect through your proxy (ERR_PROXY_TUNNEL) のような別の文言になります。こちらは URL や認証情報、許可されたホストかどうかの確認が先です

Claude Code で出るほかの英文エラーと、それぞれの対処は、早見表にまとめています。

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?