Azure "az" command and decryption

[Rievax]

Hello, All.

Working on Windows. A few days ago, tried to understand why the Microsoft Azure CLI "az" command line program was not working with decryption behind our PAN OS 10.2.10.

• Azure CLI is a python tool. I am currently running v2.77 (latest)
• I added the root CA to C:\Program Files\Microsoft SDKs\Azure\CLI2\Lib\site-packages\certifi\cacert.pem

This is Microsoft's recommended solution, but this latest version of Python / Azure CLI checks the certificate validity also on the Authority Key Identifier (AKI). 

The error message seems "obvious":

• Before adding the "root CA" to its trusted store: "[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self-signed certificate in certificate chain (_ssl.c:1032)"
• After adding the "root CA" to its trusted store: "[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Missing Authority Key Identifier"

I searched on public posts, and pre 2024, it seems that updating the python trust store or bypassing security was possible. Not anymore with this latest version of Azure CLI.

Our friends Copilot and Gemini helped me in finding this "reason" for the problem I am facing. But I am surprised that nobody else posted anything about this though.  

Don't you guys face the same issue? The way I see it, it is impossible to solve since the decryption mechanism does not publish the Authority Key Identifier in fear of breaking a client's verifications... Or why the PA firewall does not update the AKI to match its Forward Trust Certificate's Server Key Identifier? 

Any input is welcome.

Cheers.

[rachel33berry]

You are encountering an [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Missing Authority Key Identifier error with the Azure CLI (v2.77) on Windows when it's operating behind a Palo Alto Networks firewall performing SSL decryption. This issue arises because the latest Python versions used by the Azure CLI have stricter certificate validation, requiring the Authority Key Identifier (AKI) to be present in the certificate chain. The Palo Alto firewall, during decryption and re-signing of the certificate, does not include this AKI in the new certificate it presents to the client. This breaks the chain of trust for the Azure CLI's validation process, which expects the AKI to match the Subject Key Identifier (SKI) of the issuing certificate, a detail that is lost in the decryption and re-signing process. While adding the root CA to the cacert.pem file addresses the initial "self-signed certificate" error, it cannot fix the missing AKI, as this is a fundamental part of the re-signing behavior of the firewall.

[Rievax]

Hello rachel33berry,

Thanks for the answer and rephrasing my message (too keep the discussion alive?) with a technical explanation instead of empiric description.

Posting in LIVEcommunity was my effort in sharing the behavior while no recent post were found on the subject - Azure CLI behing very important for many enterprises nowadays.

I was expected more input from the community on "how" they now workaround this issue other that disabling decryption for everything Azure... like maybe instruct Python's "certifi" module to ignore the missing AKI match.

Since Palo Alto "tried" to support for parsing the Server Key Identified (SKID) and Authority Key Identifier (AKID) extensions (PanOS 10.1.7 and 10.2.2 in 2022), this is not an unknown issue.

I am missing something?