amazon-bedrock AWS SSO credential resolution ignores CODEX_CA_CERTIFICATE / SSL_CERT_FILE behind a TLS-intercepting proxy

What version of Codex CLI is running?

0.153.2

Also reproduced on 0.151.0.

What subscription do you have?

N/A — this session uses the built-in amazon-bedrock model provider.

Authentication and billing are through the user's AWS account / Amazon Bedrock, using an AWS SSO (IAM Identity Center) profile. No ChatGPT plan or OpenAI API-key billing account is involved in the failing request.

The failure occurs during AWS credential resolution, before any model inference request is made.

Which model were you using?

N/A / model-independent.

The failure occurs while resolving AWS credentials for amazon-bedrock, before a model request is sent.

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64 (Windows 11 Enterprise)

What terminal emulator and version are you using (if applicable)?

Windows Terminal (Powershell 7)

Codex doctor report

{
  "schemaVersion": 1,
  "overallStatus": "fail",
  "codexVersion": "0.153.2",
  "network.env": {
    "status": "ok",
    "summary": "network-related environment looks readable",
    "details": {
      "SSL_CERT_FILE": "readable file C:\\ProgramData\\<corporate-ca>.pem",
      "managed proxy": "not configured",
      "proxy env vars": "none",
      "respect system proxy": "disabled"
    }
  },
  "runtime.provenance": {
    "status": "ok",
    "summary": "running standalone on windows-x86_64",
    "details": {
      "install method": "standalone (windows)",
      "platform": "windows-x86_64",
      "version": "0.153.2"
    }
  },
  "state.rollout_db_parity": {
    "status": "ok",
    "details": {
      "rollout DB model providers": "openai=51, amazon-bedrock=26"
    }
  }
}

The full codex doctor --json snapshot also reported that no OpenAI credential was active at capture time. That is unrelated to this bug: the reported failure occurs earlier in the AWS credential-resolution path for the amazon-bedrock provider and does not require OpenAI authentication.

The doctor report included above is limited to the sections relevant to this issue.

What issue are you seeing?

When model_provider is set to amazon-bedrock and the provider uses an AWS SSO / IAM Identity Center profile, AWS credential resolution fails while obtaining SSO role credentials (GetRoleCredentials) in an environment with a TLS-intercepting corporate proxy.

Codex is already configured with the corporate CA through SSL_CERT_FILE (the same issue applies when using CODEX_CA_CERTIFICATE). Codex's own HTTP/TLS client recognizes that CA bundle, but the AWS SDK HTTP client used during Bedrock credential resolution does not appear to receive the same trust configuration.

With RUST_LOG=debug, the AWS credential failure is approximately:

aws_config::profile::credentials: failed to load base credentials
error=an error occurred while loading credentials: dispatch failure:
io error: client error (Connect): invalid peer certificate:
UnknownError {
    source: DispatchFailure(
        DispatchFailure {
            source: ConnectorError {
                kind: Io,
                source: hyper_util::client::legacy::Error(
                    Connect,
                    Custom {
                        kind: Other,
                        error: Custom {
                            kind: InvalidData,
                            error: InvalidCertificate(UnknownIssuer)
                        }
                    }
                ),
                connection: Unknown
            }
        }
    )
}

The CLI-facing error is:

ERROR: stream disconnected before completion: failed to load AWS credentials:
an error occurred while loading credentials

In the same process/environment, Codex's custom-CA-aware HTTP path logs that it loaded the configured CA bundle. No corresponding custom-CA log is emitted for the AWS SDK credential-resolution path.

This makes the built-in amazon-bedrock provider unusable with an SSO profile when AWS SSO endpoints are reached through a corporate TLS-inspection proxy, unless the proxy's CA is installed into the trust mechanism used independently by the AWS SDK.

What steps can reproduce the bug?

1. Use a network where outbound HTTPS is intercepted by a corporate TLS proxy whose CA is not otherwise trusted by the AWS SDK's default trust configuration.

2. Point Codex at the corporate CA bundle.

   In PowerShell:

   $env:SSL_CERT_FILE = "C:\ProgramData\<corporate-ca>.pem"
   

   CODEX_CA_CERTIFICATE can be used instead.

3. Confirm the CA bundle works for Codex's normal custom-CA-aware HTTP path.

   With debug logging enabled, this path reports that certificates were loaded from the custom CA bundle.

4. Configure a valid AWS SSO / IAM Identity Center profile and confirm that the profile itself works on the same machine and network:

   aws sso login --profile <profile>
   

5. Run Codex using the built-in Bedrock provider and that profile:

   codex exec `
     -c 'model_provider="amazon-bedrock"' `
     -c 'model_providers.amazon-bedrock.aws.profile="<profile>"' `
     -c 'model_providers.amazon-bedrock.aws.region="<region>"' `
     'Reply with one word.'
   

6. AWS credential resolution fails before model inference with an error containing:

   InvalidCertificate(UnknownIssuer)
   

   followed by:

   failed to load AWS credentials
   

Reproduced with Codex CLI 0.151.0 and 0.153.2.

What is the expected behavior?

The built-in amazon-bedrock provider's AWS SDK HTTP client should honor the same custom CA configuration that Codex already exposes through:

CODEX_CA_CERTIFICATE

and:

SSL_CERT_FILE

In particular, HTTPS requests made by the AWS credential provider chain — such as AWS SSO token/role credential resolution and GetRoleCredentials — should trust the configured corporate CA in the same way as the rest of Codex's custom-CA-aware network traffic.

A user should not have to obtain a TLS-inspection bypass for AWS SSO endpoints simply because the Bedrock authentication path is implemented using a different HTTP client.

Additional information

Current source appears to explain the behavior directly.

Codex's shared custom-CA implementation is in:

codex-rs/http-client/src/custom_ca.rs

It explicitly reads CODEX_CA_CERTIFICATE, falling back to SSL_CERT_FILE, and adds the configured certificates to the transport trust store.

By contrast, the AWS configuration used by the Bedrock authentication path is currently loaded in:

codex-rs/aws-auth/src/config.rs

load_sdk_config() constructs:

let mut loader = aws_config::defaults(BehaviorVersion::latest());

then applies the selected profile and region and finally calls:

loader.load().await

There is no custom HTTP client / TLS trust configuration attached to that AWS SDK ConfigLoader in this path.

The AWS SDK for Rust supports custom CA roots programmatically by constructing an aws_smithy_http_client HTTP client with a TlsContext / TrustStore and passing it to the AWS config loader via .http_client(...).

So this appears to be an integration gap between Codex's existing custom-CA policy and the AWS SDK client used for amazon-bedrock, rather than a problem with the SSO profile itself.

A likely fix would be for the AWS auth path to consume the same CA-bundle selection and parsing policy already used by codex-rs/http-client, then configure the AWS SDK HTTP client with native roots plus the configured custom CA before loading the AWS credential provider chain.

Start with codex-rs/http-client/src/custom_ca.rs to understand the existing CODEX_CA_CERTIFICATE and SSL_CERT_FILE handling, then inspect codex-rs/aws-auth/src/config.rs and its load_sdk_config() entry point. Confirm that AWS SSO credential-resolution requests use the configured CA bundle, and verify that the amazon-bedrock provider no longer fails with InvalidCertificate(UnknownIssuer) behind the reproducing proxy setup.