Python Requests: CA Bundles Belong in verify, Not cert

Put approved CA trust material in the verification configuration instead of treating a certificate error as a request for a client private key.

A colleague gives you the organization's CA certificate. Requests offers a parameter called cert. The names look like a match, but they answer different questions.

SettingPurpose
verifySelect trust material used to verify the peer
certPresent a client certificate, with its private key, when client authentication is required

For an approved interception CA, a Requests operation can select the intended CA bundle:

response = requests.get(
    'https://example.com/',
    proxies=routes,
    verify='/path/to/approved-ca-bundle.pem',
    timeout=15,
)

Here routes is the application's existing proxy mapping. The path must name the correct readable trust bundle for this client. It is not a downloaded website certificate selected merely because the connection failed.

The environment variable REQUESTS_CA_BUNDLE is another supported trust input. Check the actual sending path if it appears ineffective; prepared-request workflows and explicit settings can alter how environment configuration is merged.

You should not need the CA's private key

The public CA certificate is what a client needs to recognize an approved issuer. Its signing private key is another party's powerful secret. It should not be distributed to application users as part of a routine proxy-trust fix.

A client certificate can still be required by a particular destination or another separately configured TLS relationship. That is a separate requirement, not something inferred from every certificate-verification error.

When the next error appears, name the operation: loading a CA file, verifying a peer certificate, or presenting a client identity. Moving a file between verify and cert until the message changes is not a reliable way to choose its role.

Erthyglow kevrennek