Certificate installed for AZ CLI is not getting accepted by MicroSoft

Debashish Behera 5 Reputation points
2026-11-04T12:22:29.79+00:00

Running az login, az account get-access-token, or any az command (Like az login or az login --use-device-code) on a machine behind Zscaler fails with an error like this:

HTTPSConnectionPool(host='login.microsoftonline.com', port=443): Max retries exceeded with url: /organizations/v2.0/.well-known/openid-configuration (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1081)'))) Certificate verification failed. This typically happens when using Azure CLI behind a proxy that intercepts traffic with a self-signed certificate. Please add this certificate to the trusted CA bundle.

This happens even though the Zscaler root CA is already installed in the OS trust store

Any work around to get out of this issue.

PS : Zscaler Tunnel version TLSv2.0 is something where the things are not working as the other policy bypasses all traffic except the ones coming in port 80 and 443. Due to some business reasons we cannot move out of tunnel version TLSv2.0 ?

Azure DNS
Azure DNS

An Azure service that enables hosting Domain Name System (DNS) domains in Azure.

0 comments No comments

1 answer

Sort by: Most helpful
  1. AI answer

    2026-11-04T12:23:56.2966667+00:00

    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^

    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-----
      
    2. 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
    3. 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
      
    4. Linux/macOS: use the corresponding Azure CLI cacert.pem path:
         mkdir -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 login
      
      Add the export line 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_BUNDLE is visible in the same process that launches az:
      • PowerShell: $env:REQUESTS_CA_BUNDLE
      • Bash: echo "$REQUESTS_CA_BUNDLE"
    • If only az login fails after other Azure CLI HTTPS operations succeed, there is a reported Azure CLI/MSAL case in which an authentication path does not honor REQUESTS_CA_BUNDLE.^2^ In that case, capture az login --debug, remove tokens and identifiers, and add the Azure CLI version from az version when 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

    1. Troubleshooting Azure CLI
    2. MSAL authentication doesn't respect REQUESTS_CA_BUNDLE for ... - GitHub
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.