In smaller deployments, it's common to have the topurl setting point at the same webserver as the hub, like:

[kojidev]
server = https://kojidev.example.com/kojihub
topurl = https://kojidev.example.com/kojifiles
serverca = ~/.koji/pki/koji-ca.kojidev.example.com.crt

The CLI does not re-use the Koji session's requests.Session object to download files. This means that we use the serverca option to do hub RPCs, but not for koji download-build.

$ koji -p kojidev download-build bash-5.0.17-2.fc33
2020-12-23 14:32:23,743 [ERROR] koji: SSLError: HTTPSConnectionPool(host='kojidev.example.com', port=443): Max retries exceeded with url: /kojifiles/packages/bash/5.0.17/2.fc32/src/bash-5.0.17-2.fc33.src.rpm (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: self signed certificate in certificate chain (_ssl.c:1124)')))

Does it make sense for koji download-build to use the same serverca option?

I could foresee this breaking some environments where users use an internal CA to talk to the hub, but the topurl setting points to a different webserver that has an HTTPS cert signed by a different CA.

Steps to reproduce

1. Set up a Koji Hub with a private CA.
2. Set up a Koji profile config on a client. In particular, server and topurl should point to the the same HTTPS server, and this HTTPS server should not be trusted system-wide (use the serverca config option.)
3. Ensure koji -p kojidev hello works on the client (to validate that RPCs work via HTTPS)
4. Ensure the hub has at least one build to download
5. Try downloading the build with the CLI, eg koji -p kojidev download-build bash-5.0.17-2.fc33

Actual Results
koji fails to download the build (see SSLError above)

Expected Results
koji uses the serverca setting just like the other sub-commands

Additional information
I can use the REQUESTS_CA_BUNDLE environment variable like so:

REQUESTS_CA_BUNDLE=~/.koji/pki/koji-ca.kojidev.example.com.crt kojidev download-build bash-5.0.17-2.fc33