How to Fix AWS CLI Failures Behind Zscaler

The command failed. No one knew why.

You typed aws s3 ls and waited. Nothing. Then the Slack message came in: “It works locally, must be Zscaler.”

If you’ve tried to run AWS CLI commands behind Zscaler, you already know it can turn a simple deploy into a brick wall. What should be instant turns into a maze of TLS errors, broken handshakes, and connection resets. The fix is not a simple checkbox — it’s understanding how AWS CLI interacts with Zscaler’s secure web gateway and ensuring the two can talk without cutting each other off.

The problem
AWS CLI requires direct, uninterrupted access to AWS endpoints via HTTPS. Zscaler, by default, proxies and inspects all outbound connections, often via SSL interception. The interception inserts Zscaler’s root certificate into the trust chain. If the AWS CLI environment doesn’t explicitly trust that certificate, commands will fail. Sometimes the requests don’t even reach AWS — they die at the proxy layer.

The fix

1. Get the Zscaler root certificate from your network or security team.
2. Install the certificate in the OS trust store that AWS CLI uses. This is different depending on whether you run AWS CLI in Linux, macOS, or Windows.

• On Linux, update /etc/ssl/certs and run update-ca-certificates.
• On macOS, import it into the Keychain and mark it as trusted.
• On Windows, import into the Trusted Root Certification Authorities store.

1. If you can’t alter the OS store, point AWS CLI to the Zscaler cert file directly:

export AWS_CA_BUNDLE=/path/to/zscaler.crt

or configure it in ~/.aws/config:

ca_bundle = /path/to/zscaler.crt

1. Verify HTTP proxy settings. If your org mandates Zscaler’s proxy, export:

export HTTP_PROXY=http://proxy.company.com:port
export HTTPS_PROXY=http://proxy.company.com:port

Make sure these match your Zscaler configuration.

1. Test with a simple command:

aws sts get-caller-identity

If this works, S3, EC2, and the rest should follow.

Advanced considerations

• Some AWS CLI calls use regional endpoints. Zscaler must allow all required AWS IP ranges. Pull the latest ranges from AWS’s ip-ranges.json and feed them into your Zscaler policy.
• For automation, embed cert handling into Docker images or CI/CD runners so builds don’t fail unexpectedly.
• Keep Zscaler certs and AWS CLI versions updated to prevent mismatches when encryption standards shift.

The connection between AWS CLI and Zscaler is straightforward only when trust and routing are exact. Every break in the chain is a failed build, a stalled deploy, a quiet blocker that costs hours. Setting it up right once saves days later.

You can wire this up everywhere in minutes if you don’t want to babysit configs on every machine. See it live and running end-to-end at hoop.dev — no waiting, no manual patching, and no guessing why the command failed.