Any reason Boto3 has not adopted Python truststore?

[byjrack]

Using awscli in an organization where proxy inspection happens. We try to advise folks to use AWS_CA_BUNDLE, but it's tough to educate thousands of folks about what to do and why. Is there a reason why boto3 has not pulled in truststore to help with CA trust? Still holding onto py2 compatibility? It made a huge difference in some other efforts where Requests was in use and reducing incident volume so it was worth the bigger supply chain. And yes its all documented, but doesn't get very far in reality. I just didn't know if I couldn't see a specific issue that was preventing using it as a path to zero-config CA trust in orgs where system CA trust is managed.

Figured before looking at a PR I would get a bit of a sanity check on if there was a blocker that would be non-trivial to get around.

[tayfuryldz]

Python 2 compatibility is no longer the blocker: current Boto3 declares python_requires >= 3.10.

The more important detail is that TLS trust selection lives in botocore, not in Boto3 itself. On current botocore, URLLib3Session still resolves verify=True to a CA file via get_cert_path() (using certifi.where() when certifi is installed, otherwise botocore's bundled cacert.pem). A configured ca_bundle / AWS_CA_BUNDLE is passed as that verification path. Botocore also constructs its own urllib3 SSL context.

That means adopting truststore is not simply adding a Boto3 dependency. To get the zero-config system trust behavior you want, botocore's HTTPS session would need a deliberate alternative trust source / SSLContext path, while preserving the existing explicit CA-bundle behavior and proxy TLS configuration.

I would therefore frame a proposal against botocore with these semantics spelled out:

• explicit verify=/path or AWS_CA_BUNDLE continues to win;
• otherwise, opt in to native/system trust (potentially through truststore);
• define behavior for HTTPS proxies separately, since botocore can load a proxy CA bundle into its SSL context too;
• test Linux/macOS/Windows and the urllib3 versions botocore supports.

There is also a compatibility/supply-chain tradeoff: botocore currently supports urllib3 from 1.25.4 through <3 and vendors part of the SSL-context setup specifically to control which SSLContext implementation is used. A truststore integration would need to fit that matrix rather than assuming Requests' TLS setup.

So the use case is reasonable and the old Python-2 explanation does not apply today, but I would not send a Boto3-only PR that swaps the CA path. The implementation boundary is botocore's HTTPS session, and it needs an explicit decision about precedence between system trust and the existing bundle mechanisms.