Skip to content

Honor SSL_CERT_FILE/SSL_CERT_DIR and the platform trust store in HTTP clients - #143

Open
chillosu wants to merge 2 commits into
raine:mainfrom
chillosu:native-roots-trust-store
Open

Honor SSL_CERT_FILE/SSL_CERT_DIR and the platform trust store in HTTP clients#143
chillosu wants to merge 2 commits into
raine:mainfrom
chillosu:native-roots-trust-store

Conversation

@chillosu

@chillosu chillosu commented Sep 9, 2026

Copy link
Copy Markdown

Summary

HTTP clients only trust the bundled webpki roots, so any host behind a private CA or a TLS-inspecting proxy gets error sending request for url (...) on every OpenAI request, and SSL_CERT_FILE has no effect. The websocket client already combines the platform trust store with webpki roots; this makes the HTTP clients do the same.

Change

One Cargo feature: reqwest gains rustls-tls-native-roots. reqwest then loads the platform trust store, or the standard SSL_CERT_FILE / SSL_CERT_DIR locations when set, in addition to webpki roots. rustls-native-certs is already a dependency, so the lockfile change is feature-only.

Verification

  • Before: claude-code-proxy codex auth device behind a TLS-inspecting proxy → Device init network error: error sending request for url (https://auth.openai.com/api/accounts/deviceauth/usercode); a CONNECT-tunnel capture shows the handshake complete and the client send a TLS alert (untrusted chain).
  • After (this branch): the same command returns Visit: https://auth.openai.com/codex/device with a device code, with the inspection CA provided via SSL_CERT_FILE.
  • curl with the same CA file verifies the same endpoint, confirming the chain is valid on the host.

Notes

  • Behaviour on hosts without a private CA is unchanged (webpki roots remain trusted).
  • Happy to add a docs line under configuration: "Trust store: the platform store is used; set SSL_CERT_FILE or SSL_CERT_DIR to provide a custom CA bundle."

chillosu and others added 2 commits September 9, 2026 09:59
… clients

The reqwest clients (Codex auth/refresh, Codex API, images, transcription,
Cursor, Grok) are built with the `rustls-tls` feature, so they trust only the
bundled webpki roots. In environments with a private CA or a TLS-inspecting
proxy, every request fails with "error sending request for url (...)" even
though the system trust store and SSL_CERT_FILE contain the CA. The websocket
client already loads the platform store (rustls_native_certs) alongside webpki,
so the two paths disagree.

Enable reqwest's `rustls-tls-native-roots` feature. reqwest then adds the
platform trust store — or, when set, the standard SSL_CERT_FILE / SSL_CERT_DIR
locations — in addition to the webpki roots. No new dependencies
(rustls-native-certs is already in the tree); behaviour on hosts without a
private CA is unchanged.

Verified: `claude-code-proxy codex auth device` behind a TLS-inspecting proxy
with the inspection CA in SSL_CERT_FILE returned the device sign-in URL where
the previous build failed at the first request.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
… clients

The reqwest clients (Codex auth/refresh, Codex API, images, transcription,
Cursor, Grok) are built with the `rustls-tls` feature, so they trust only the
bundled webpki roots. In environments with a private CA or a TLS-inspecting
proxy, every request fails with "error sending request for url (...)" even
though the system trust store and SSL_CERT_FILE contain the CA. The websocket
client already loads the platform store (rustls_native_certs) alongside webpki,
so the two paths disagree.

Enable reqwest's `rustls-tls-native-roots` feature. reqwest then adds the
platform trust store — or, when set, the standard SSL_CERT_FILE / SSL_CERT_DIR
locations — in addition to the webpki roots. No new dependencies
(rustls-native-certs is already in the tree); behaviour on hosts without a
private CA is unchanged.

Verified: `claude-code-proxy codex auth device` behind a TLS-inspecting proxy
with the inspection CA in SSL_CERT_FILE returned the device sign-in URL where
the previous build failed at the first request.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant