malsamiri-oai d5a8117e08 Use aws-lc-rs for rustls crypto provider (#27706) ...

## Why

Some enterprise TLS proxies issue certificate chains signed with
`ecdsa_secp521r1_sha512` / `ECDSA_NISTP521_SHA512`. Custom CA
configuration such as `SSL_CERT_FILE` can add the right trust root, but
it cannot make `rustls`'s `ring` verifier support a certificate
signature algorithm it does not advertise.

That can still break TLS after the CA bundle is configured, including on
Rust websocket paths that call the shared
`ensure_rustls_crypto_provider()` helper, such as the Responses
websocket connector and remote app-server client:

-
[`codex-api/src/endpoint/responses_websocket.rs`](https://github.com/openai/codex/blob/eddc5c75ed527a8348bfcaa85692e53189600833/codex-rs/codex-api/src/endpoint/responses_websocket.rs#L441)
-
[`app-server-client/src/remote.rs`](https://github.com/openai/codex/blob/eddc5c75ed527a8348bfcaa85692e53189600833/codex-rs/app-server-client/src/remote.rs#L718)

The `aws-lc-rs` `rustls` provider supports this P-521/SHA-512
certificate signature scheme, so use it as Codex's process-wide `rustls`
provider.

## What Changed

- Switch the workspace `rustls` feature from `ring` to `aws_lc_rs`.
- Update `codex-utils-rustls-provider` to install
`rustls::crypto::aws_lc_rs::default_provider()`.
- Add an assertion and integration test that the installed provider
supports `ECDSA_NISTP521_SHA512`.

## Verification

```shell
just fmt
just test -p codex-utils-rustls-provider
just bazel-lock-update
just bazel-lock-check
```

d5a8117e08 · 2026-06-15 11:32:13 -07:00

History

..

preinstalled.rs

Use aws-lc-rs for rustls crypto provider (#27706)

2026-06-15 11:32:13 -07:00

provider.rs

Use aws-lc-rs for rustls crypto provider (#27706)

2026-06-15 11:32:13 -07:00