Claude CodeでUNABLE_TO_GET_ISSUER_CERT — 2.1.304のBedrock退行

Claude Code 2.1.304に上げた途端、Bedrockのゲートウェイへの全リクエストがSSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT)で落ちる報告があります。報告者の環境はWindows 11で、ゲートウェイの証明書は私設CA(ルート1枚と中間2枚)の署名です。ルートはWindowsの信頼されたルート証明書ストアに入っていて、2.1.303までは同じ設定で通っていました。

この記事では、報告された症状、debugログの読み方、2.1.303へ戻して固定する手順を順に書きます。後半では、同じスレッドに集まった別の事例が2.1.310で直った経緯と、私設CA側が直ったと確認できていない点も分けて示します。

どんな構成で、何が起きたか

報告(anthropics/claude-code#103680)の環境を表にします。

settings.jsonのenvは次のとおりです。

{
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "CLAUDE_CODE_SKIP_BEDROCK_AUTH": "1",
    "ANTHROPIC_BEDROCK_BASE_URL": "https://<gateway>/...",
    "CLAUDE_CODE_CERT_STORE": "bundled,system"
  }
}

この状態でclaude -p "Reply OK"を実行すると、2.1.304では失敗し、同じマシンの2.1.303のバイナリでは通ります。ゲートウェイはチェーン全体を送っており、Windows側の検証も通る点が、報告者が「設定ミスではない」と見る根拠です。

エラー文は次の形で出ます。

API Error: Unable to connect to API: SSL certificate verification failed (UNABLE_TO_GET_ISSUER_CERT). 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

末尾の案内どおりにNODE_EXTRA_CA_CERTSを足しても直らないのが、この件の厄介なところです。

debugログのCA行をどう読むか

切り分けの中心は--debugのログです。出力先は~/.claude/debug/<session-id>.txtで、--debug-file <path>で場所を指定できます。Windows(PowerShell)なら、次の2行でCA certs:の行だけを取り出せます。

claude --debug-file ca-debug.txt -p "Reply OK"
Select-String -Path ca-debug.txt -Pattern "CA certs:|ISSUER"

報告された2.1.304のログから、CA関連の行を抜き出して意味を添えます。

注目点は2つあります。1つ目は、OSストアも追加CAも読み込みに成功していることです。「CAが読めていない」という通常の原因は、このログから除外できます。2つ目は、同梱ルートが121から117に減り、「blocked」という新しい行が出ていることです。報告者は、CAリストの組み立ては正常なのに検証がそのリストを使っていないように見えると書いています。

その後に続く行で、失敗の場所が分かります。

[ERROR] Bedrock ListInferenceProfiles failed: unable to get issuer certificate
[DEBUG] [API REQUEST] /api/v1/inference/bedrock/model/<model>/invoke-with-response-stream
[ERROR] Connection error details: code=UNABLE_TO_GET_ISSUER_CERT (SSL error), message=unable to get issuer certificate

モデル一覧の取得(ListInferenceProfiles)と、推論リクエスト本体の両方が同じコードで落ちています。

効かなかった回避策

報告者が2.1.304で試して、すべて失敗した手段は3つです。

• 中間CAを含むチェーン全体のPEMをNODE_EXTRA_CA_CERTSで渡す(ログ上は追加されている)
• NODE_USE_SYSTEM_CA=1
• BUN_OPTIONS=--use-system-ca

どれもCAリストを増やす方向の手段です。リストを増やしても通らないので、この症状ではCAの不足以外を疑う必要があります。CLAUDE_CODE_CERT_STOREの値を変えた結果は、報告に載っていません。

NODE_TLS_REJECT_UNAUTHORIZED=0は検証そのものを切るので、回避策として使いません。

暫定対処 — 2.1.303へ戻して自動更新を止める

報告者が示した回避策は、2.1.303へ戻して自動更新を止める方法です。

claude install 2.1.303

続けて、~/.claude/settings.jsonに次を加えます。

{
  "env": { "DISABLE_AUTOUPDATER": "1" }
}

DISABLE_AUTOUPDATERを1にすると、バックグラウンドの自動更新が止まります。手動のclaude updateは引き続き使えます。claude installもブロックしたい場合は、より厳格なDISABLE_UPDATESがありますが、固定したバージョンを入れ直せなくなる点に注意が必要です。

戻したあとは、claude doctorで自動更新が無効になっているかを見ます。スレッド上のコメントでは、disabled (set by env: DISABLE_AUTOUPDATER)と表示されると紹介されています。

固定は一時しのぎです。直ったと確認できたら、DISABLE_AUTOUPDATERの行を外して更新します。

設定が届いているかを先に疑う

退行を疑う前に、設定の置き場所を確かめます。バージョンを戻して通るなら設定は正しいと言えますが、戻せない環境では先にここを見ます。

CLAUDE_CODE_CERT_STOREには専用のsettings.jsonキーがなく、~/.claude/settings.jsonのenvブロックか、プロセスの環境変数で指定します。値はbundled(同梱のMozilla CA)とsystem(OSの信頼ストア)をカンマ区切りで並べ、既定はbundled,systemです。OSストアの読み込みは、ネイティブ版か、Node 22.15以降のnpm版で有効になります。

バックグラウンドエージェントを使う場合は、置き場所がさらに効きます。エージェントを動かす監視プロセスは、最初に起動したシェルの環境を引き継いで常駐します。CAのパスをシェルのexportだけで渡すと、どのシェルが先に起動したかで届いたり届かなかったりします。NODE_EXTRA_CA_CERTSもCLAUDE_CODE_CERT_STOREも、settings.jsonのenvに書いておけば、この揺れを避けられます。

信頼元の切り分けには、CLAUDE_CODE_CERT_STOREを一時的にsystemだけにする方法もあります。ルートがWindowsのストアにあるなら、systemだけで通る可能性があります。ただし、この切り分けで2.1.304の症状が変わったという報告はありません。

systemだけで通るなら、OSストア経由の信頼は生きています。systemだけでも落ちるなら、報告と同じ症状です。この分け方は設定の側を確かめる手順であり、退行の原因を特定するものではありません。

Claude DesktopのCodeタブにも波及した

スレッドには、Claude DesktopのCodeタブでも同じ問題が出たという報告があります。問題のあるバージョンのClaude Codeが、Desktopの最新アップデートに含まれていたためです。報告者によれば、サードパーティプロバイダー運用(3Pモード)でカスタムCAを使うと、製品が使えなくなります。

Desktopがプロバイダー接続を管理するセッションでは、TLSとプロキシの変数は、管理設定と~/.claude/settings.jsonからだけ読まれます。リポジトリ側のsettingsに書いたCAパスは無視されるので、CLIで試した設定をそのまま移せません。CAのパスは、ユーザー設定か管理設定に置いてください。

2.1.306以降で何が分かっているか

スレッドの経過を日付順にまとめます。

MCPの事例は、ゲートウェイの事例と原因が同じとは限りません。コメントでは、emSignの一部ルートの信頼取り消しが関わる可能性が議論されていて、2.1.307のログにもDropped 1 certificate(s) that do not chain to a root in the CA listという行が出ています。ただし、これはユーザー側の推測の域を出ません。

大事なのは次の点です。2.1.310の変更履歴にある修正項目に、証明書やCAに触れたものはありません。直った事例は、報告者本人のコメントで確認されたものです。一方、元のWindows・私設CA・Bedrockゲートウェイの報告者からは、2.1.310で直ったという書き込みが付いていません。元の報告(#103680)は未解決のまま開いています。

まだ分かっていないこと

スレッドと変更履歴から読み取れない点は、次の3つです。

• 2.1.304で入った「blocked」の判定が、どの証明書を対象にするのか。ログにはフィンガープリントが出るだけで、一覧は示されていません
• 私設CAのゲートウェイが落ちる直接の原因が、そのブロック処理なのか、別の検証経路なのか
• 2.1.310の修正が、私設CAのケースにも及ぶのか

報告者は同梱ルートの減少(121から117)とブロック行の新設を並べて挙げていますが、それが失敗の原因だと断定する材料は、報告にはありません。原因の推測を前提に設定を変えるより、バージョンを変えて挙動を比べるほうが確実です。

自分の環境で確かめる順番

2.1.304以降でこのコードが出たときは、次の順で見ると無駄がありません。

1. claude --versionで、2.1.304から2.1.309の範囲にあるかを見る
2. claude --debug-fileで、CA certs:の行に自社CAの読み込みがあるかを見る。読み込みがなければ、通常の設定ミスです
3. 読み込みがあるのに失敗するなら、Dropped blocked certificateの行と、同梱ルートの数をメモする
4. 2.1.310以降へ更新して、同じコマンドで再確認する
5. 直らなければ、2.1.303へclaude installで戻して自動更新を止める

エラーの文言が_LOCALLY付きかどうかも手がかりです。「unable to get local issuer certificate」系は、公式のエラー一覧で、TLS検査プロキシや私設CAの未登録として扱われている文言です。通常の設定ミスや、TLS検査プロキシの導入によるエラーは、Claude CodeのSSL証明書エラーの原因と対処法で原因別に分けています。Bedrock側のSTSやSSOの呼び出しにCA設定が効くようになった経緯も、そちらに年表があります。

macOSでTelia Rootのチェーンが拒否される別の事例は、Claude CodeのmacOS版が社内ゲートウェイの証明書を拒否するときの対処にあります。こちらはNODE_EXTRA_CA_CERTSで直った報告で、2.1.304の退行とは症状が似ていても、効く対処が違います。

issueに添える情報

2.1.310以降でも直らない場合は、既存のissueに次の情報を足すと、再現の手がかりになります。

• claude --versionの出力と、通った最後のバージョン
• CA certs:で始まる行のうち、LoadedとDroppedの行(ホスト名やパスは伏せる)
• 失敗する接続先の種類(Bedrockゲートウェイ、HTTP型MCPなど)
• チェーンの構成(ルート・中間の枚数、ルートをどのストアに入れたか)

証明書の中身や秘密鍵は貼りません。フィンガープリントだけで十分です。

まとめ

2.1.304の報告は、CAの設定が正しくてもBedrockゲートウェイが全滅するというもので、CAを足す対処が効かないのが特徴です。2.1.310で解消した報告はemSign G1のMCP事例で、私設CAのBedrock事例は確認が出ていません。直るまでは、debugログで読み込みを確かめ、2.1.303への固定を手元の保険にするのが現実的です。更新のたびに、同じclaude -p "Reply OK"で再確認する習慣をつけておくと、次の退行にも気づけます。