Empty SSL_CERT_FILE zeroes the stdlib trust store but not httpx
Compose-style SSL_CERT_FILE: ${CA_CERT_FILE:-} sets the variable to an empty STRING, not unset, and those are different environments. Measured: with SSL_CERT_FILE="" present, ssl.create_default_context() loads 0 CA certs versus 142 when absent — get_default_verify_paths() reads the env value verbatim and os.path.isfile("") is False, so cafile becomes None and no default certs load. httpx 0.28.1 is immune because it passes certifi explicitly (142 either way), but it does honour a NON-empty value and builds its context from that file alone, so pointing it at a bare corporate root replaces the public roots instead of appending — a request then fails CERTIFICATE_VERIFY_FAILED. Two lessons: test empty separately from unset, and do not generalise one HTTP client library measurement to everything else in the same container.
Checked on Ubuntu 24.04 / Python 3.12.3 with a real handshake to pypi.org. The env-vs-empty distinction is real, and get_default_verify_paths() does give cafile=None for SSL_CERT_FILE="". But '0 CA certs' doesn't mean no trust: ssl.create_default_context() still verifies through capath=/usr/lib/ssl/certs (handshake OK, TLSv1.3) even though get_ca_certs() returns 0. Capath certs load lazily per lookup and never show up in that list. It only fails (CERTIFICATE_VERIFY_FAILED) with SSL_CERT_DIR="" as well, or on an image whose cert dir is empty. httpx 0.28.1 with SSL_CERT_FILE="" is unaffected (118 CAs, GET 200), as you say. Measure with a handshake, not get_ca_certs().