I was trying to get logged into my shiny new Azure Free account so I could do some training. Using the "az login" CLI command resulted in the following:
HTTPSConnectionPool(host='login.microsoftonline.com', port=443): Max retries exceeded with url: /organizations/oauth2/v2.0/token (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:997)')))
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. More info: https://docs.microsoft.com/cli/azure/use-cli-effectively#work-behind-a-proxy.
I was doing this from my work laptop, while on VPN, where my employer -- almost certainly -- is passing my web traffic through some kind of inspection proxy. Using the link in the error message for guidance, I performed the following steps.
First, I located my employer's root CA.
- In your browser, open the certificate details for this web page. Yes, this page. The reason for this is that your employer (or school) probably has some kind of root CA installed on your machine so that it can validate the self-signed cert that comes back from the internal proxy.
- In Chrome, click the "padlock" next to the address bar
- Click "connection is secure"
- Click "certificate is valid".
- Now click the "Certification Path" tab.
Here you might start to understand why the 'az' command is complaining in the first place. On my computer, I see a cert path that doesn't make much sense. I see a "stevecox.us" certificate at the bottom, but a Root CA with my employer's name on the top. Since I know I didn't get my domain cert from my employer (it's a Let's Encrypt cert), this is pretty definitive proof that my work PC has an employer-specific Root CA installed that is vouching for the cert being presented by the proxy.
Your next step is to locate this Root CA on your local machine.
- Back on the "Certification Path" tab, double-click on the top-most listed certificate (this will be your "Root CA").
- The easiest way in my opinion to match this up with the correct CA installed on your computer is the expiration date. You'll see what I mean in a second. On the "Certificate" page, take note of the "Valid to" date.
- Open "mmc". You will likely need admin privileges to do this.
- Go to File -> "Add/Remove Snap-in"
- In the "Available snap-ins" pane, locate "Certificates", and click "Add >"
- Choose "Computer account" (Note that this is the most likely place for your certificate to exist, but it's not guaranteed.)
- Click "Next"
- Make sure "Local computer" is selected
- Click "Finish"
- Click "OK"
On my computer, the Root CA was stored in "Certificates (Local Computer)" -> "Intermediate Certification Authorities" -> "Certificates". It's very possible that your organization may have picked a different path to store the CA in.
Now you'll need to match up the Root CA you saw in the Certification Path in your browser to the cert in your local certificate store.
- Take the date that was observed from the Root CA earlier and find a matching expiration date in the list of certificates. The "Issued To" and Issued By" columns should match the name of the cert you identified in your browser as well.
- Once you believe you've identified the correct CA, double-click on it, go to the "Details" tab, and locate the "Thumbprint" attribute at the bottom of the list.
- Go to the "Details" tab back on the certificate dialog in your browser. Locate the "Thumbprint" attribute here as well.
- Make sure the "Thumbprints" match. If they do, you've found the correct cert.
At this point, your goal is to export the CA from your local certificate store, and place it into the "cacert.pem" file.
- Back in the certificate store window, close the certificate details if they are currently open.
- Locate your correct Root CA, right-click, then select "All Tasks" -> "Export"
- Click "Next"
- Select "Base-64 encoded X.509 (.CER)"
- Click "Next"
- Use the "Browse" button to select a location that you are able to access, and choose any arbitrary file name that you can remember
- Click "Next"
- Click "Finish"
- You should receive a "The export was successful" message.
- Locate the newly saved file and open it in a plain-text text editor. (Windows Notepad is fine for this, I used VSCode.)
- You should see "-----BEGIN CERTIFICATE-----" at the top of this file followed by several rows of mostly alphanumeric characters. If you see something very different (for example, lots of garbled text, "square boxes", etc., you may have failed to select the "Base 64" option during the export procedure).
- Copy the contents of this file into your clipboard.
- If the Azure CLI tool is installed on the default location on your Windows system, this is the file you will need to edit:
- C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\Lib\site-packages\certifi\cacert.pem
- Open this file, scroll to the bottom, and paste the contents of your clipboard. Save the file.
- Re-launch your terminal where you are using the 'az login' command and try again.
Hopefully this works for you like it did for me. One important thing to note is that this file will not automatically update when your company's Root CA is replaced. The Root CA in my example expires mid-2023, so I have about a year before (in theory) my az commands suddenly stop working. Keep that in mind when you make this change, that you will likely have to do this again when your own CA expires.
- Log in to post comments