Azure CLI – az login – behind SSL intercepting DLP/proxy

https

Should you be in similar situation to many of us behind corporate firewall intercepting SSL connections (i.e. DLP/Layer 7 inspection) trying to use Azure CLI (az) will raise following error:

# az login
Please ensure you have network connection. Error detail: HTTPSConnectionPool(host='login.microsoftonline.com', port=443): Max retries exceeded with url: /common/oauth2/devicecode?api-version=1.0 (Caused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')],)",),))

Above will be shown even if system wide SSL CA Certificate used by intercepting proxy is installed on your system.

Normally to get such certificate installed for system wide use, following needs to be done:

  1. copy certificate to: /usr/local/share/ca-certificates/<your-ca>.crt
  2. run, i.e. on debian/ubuntu flavours: update-ca-certificates
  3. relogin

This though won’t work with Azure CLI as it uses Python related certificate chains ignoring the system wide.

The easiest workaround is to force Azure CLI to use the system wide SSL trusted certificate file:

# echo "export REQUESTS_CA_BUNDLE=/etc/ssl/certs/ca-certificates.crt" >> ~/.bashrc

Once above is done – re-login and run az login – all should work fine.

Hope this helps.

Kodi and ssl_bump Squid

UPDATE: 2017-11-25 Kodi changed modules and how Certs are checked (certifi and schism)

Friend of mine, happy user of freshly baked private DLP based on Squid and ssl_bump, have quickly realized that to update his add-ons he has to connect to avoid ssl_bump based proxy.

Throughout checking shown that Kodi uses Python libraries with local certificates and trusted Certificate Authorities (at least on Windows). Troubleshooting did lead to:

OLD: before 2017-11-25

NEW:

AND

All what was needed was to add his Root CA cert content at the end of the file (crt format):

Afterwards everything came back to normal.