HTTPS certificates

AdaL uses an additive certificate policy for CLI and backend HTTPS connections:

Bundled public CAs + system CAs + configured extra CAs.

If your organization inspects HTTPS traffic, ask IT for its public CA certificate bundle in PEM format. Do not supply a private key.

For example, on macOS or Linux:

SSL_CERT_FILE=/path/to/company-ca.pem adal

In PowerShell:

$env:SSL_CERT_FILE = 'C:\certificates\company-ca.pem'
adal

AdaL accepts SSL_CERT_FILE, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, NODE_EXTRA_CA_CERTS, and ADAL_EXTRA_CA_CERTS as additional PEM bundles. Multiple configured bundles are combined. SSL_CERT_DIR supplies certificate directories separated by the platform's path separator (: on macOS/Linux, ; on Windows).

These settings are additive in AdaL. Unlike some other programs, SSL_CERT_FILE does not restrict AdaL to only the certificates in that file. Public roots remain available even if your bundle contains only your company's CA. There is no replacement mode.

AdaL does not rewrite your certificate files or CA environment settings. A missing or invalid configured bundle produces an error naming the setting. Correct that path or unset the variable, then restart AdaL.

CA paths are selected at startup. Keep configured files available throughout the session: the backend reads them when it creates new HTTPS clients, so removing or corrupting a file can interrupt later requests. Restart AdaL after changing CA paths or certificate contents so the CLI and backend use the same settings.

Certificate-chain, hostname, and expiration verification remain enabled. Adding a CA authorizes it to vouch for HTTPS servers, including AdaL's services. Only add certificates from administrators you trust. Do not disable certificate verification to work around a connection error.

These settings apply to AdaL's CLI and Python backend. Your browser and external programs launched by tools use their own certificate policies.