An Azure service that enables hosting Domain Name System (DNS) domains in Azure.
Configure Azure CLI to use a PEM CA bundle containing its standard public roots plus the complete Zscaler signing chain; installing the Zscaler root only in the operating-system trust store is not sufficient for this Azure CLI configuration.
Configure a separate CA bundle
Do not modify Azure CLI’s installed cacert.pem directly: upgrades can replace it. Copy it, append the Zscaler root and any intermediate CA certificates, and point REQUESTS_CA_BUNDLE to the copy. This is Microsoft’s documented proxy workaround.^1^
- Obtain the Zscaler certificates that signed the certificate presented for
login.microsoftonline.com. Export them in Base-64 encoded X.509/PEM format. Each certificate must look like:-----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- - Find Azure CLI’s default bundle. Common locations are:
- Windows 64-bit:
C:\Program Files\Microsoft SDKs\Azure\CLI2\Lib\site-packages\certifi\cacert.pem - Windows 32-bit:
C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages\certifi\cacert.pem - Ubuntu/Debian:
/opt/az/lib/python<version>/site-packages/certifi/cacert.pem
- Windows 64-bit:
- Windows PowerShell: create the combined bundle and configure it persistently for the current user:
$source = "C:\Program Files\Microsoft SDKs\Azure\CLI2\Lib\site-packages\certifi\cacert.pem" $bundle = "$env:USERPROFILE\.azure\zscaler-ca-bundle.pem" $zscaler = "C:\Certificates\zscaler-chain.pem" Copy-Item $source $bundle -Force Add-Content $bundle "" Get-Content $zscaler | Add-Content $bundle [Environment]::SetEnvironmentVariable( "REQUESTS_CA_BUNDLE", $bundle, "User" ) $env:REQUESTS_CA_BUNDLE = $bundle az login - Linux/macOS: use the corresponding Azure CLI
cacert.pempath:
Add themkdir -p "$HOME/.azure" cp /path/to/azure-cli/certifi/cacert.pem \ "$HOME/.azure/zscaler-ca-bundle.pem" cat /path/to/zscaler-chain.pem >> \ "$HOME/.azure/zscaler-ca-bundle.pem" export REQUESTS_CA_BUNDLE="$HOME/.azure/zscaler-ca-bundle.pem" az loginexportline to the shell profile used to launch Azure CLI if it must persist.
The separate file must retain the original public CA certificates. Pointing REQUESTS_CA_BUNDLE at a file containing only the Zscaler root can make other HTTPS destinations fail.
Validate the result
Open a new terminal after setting a persistent Windows environment variable, then run:
az login --debug
az account get-access-token --debug
A successful result should proceed beyond the OpenID configuration request without CERTIFICATE_VERIFY_FAILED. The debug output also identifies the hostname at which validation fails.^1^
If it still fails:
- Check that the PEM contains the actual Zscaler root and intermediate chain used by the TLSv2.0 tunnel, not merely another Zscaler certificate.
- Confirm that
REQUESTS_CA_BUNDLEis visible in the same process that launchesaz:- PowerShell:
$env:REQUESTS_CA_BUNDLE - Bash:
echo "$REQUESTS_CA_BUNDLE"
- PowerShell:
- If only
az loginfails after other Azure CLI HTTPS operations succeed, there is a reported Azure CLI/MSAL case in which an authentication path does not honorREQUESTS_CA_BUNDLE.^2^ In that case, captureaz login --debug, remove tokens and identifiers, and add the Azure CLI version fromaz versionwhen escalating to Microsoft support.
Do not use AZURE_CLI_DISABLE_CONNECTION_VERIFICATION, NODE_TLS_REJECT_UNAUTHORIZED=0, or similar verification bypasses. They disable server identity validation and may not cover the initial MSAL discovery request anyway.
The Zscaler tunnel mode does not need to be changed if its signing chain can be supplied through this bundle. If corporate policy prevents exporting that chain, the remaining safe option is for the Zscaler administrator to exempt the required Microsoft authentication endpoints from TLS inspection or provide the approved PEM chain.
References