Open adamrodger opened 11 months ago
Hey, @adamrodger! Thanks for reaching out.
It looks like the firewall can't recognize the authority of the issuer, which for api.shuttle.rs
is Amazon.
I am not sure whether adding the Amazon Root CA 1 (https://www.amazontrust.com/repository/) in the firewall certificates store is something you can ask for.
The actual cert I need to add is my company Root CA, because corporate firewalls intercept HTTPS, decrypt it and re-sign the stream with their own CA (a classic man in the middle interception, given all your traffic goes through the corporate firewall).
So, I have the Root CA that I need to add, the problem is "which certificate store?".
It doesn't appear to be using the Windows cert store via rustls-native-certs
because the cert is installed there, and it doesn't appear to respect the SSL_CERT_FILE
env var that rustls
supports (presumably because it's a cargo
tool...?).
If there was a CA bundle on disk I could edit then I'd add it there, but I don't think there is one?
Preferably there'd be some kind -k/--insecure
flag like curl
has to just ignore cert errors.
I've recompiled cargo-shuttle
locally with the reqwest
feature rustls-tls-native-roots
enabled, and I no longer get certificate errors because that will use the OS cert store instead of the built in one.
Can we maybe make this the default or add an option to configure the built in one?
Thanks for your investigation @adamrodger! We'll probably want to enable both: extending the rustls root CAs store on demand or default to the OS cert store.
From my understanding, defaulting reqwest
compilation to use the rustls-tls-native-roots
feature, when compiling cargo-shuttle
, should be a low-hanging fruit. This means users will use the native root CA store when doing https traffic through cargo-shuttle
. There is a chance though to break some users with this change (in case they have expired certs, or miss a required one), which we'll want to avoid. There are also more downsides with the native root CA store, which are stated here: https://github.com/rustls/rustls-native-certs#should-i-use-this-or-webpki-roots, and we'll want to understand how to go about them.
We might want down the line to have one be the default for cargo-shuttle
(e.g. the tls native one), and the webpki-roots
based version (bundled by default with rustls), be guarded behind a runtime flag (if possible?), while also giving the option to extend the webpki-roots
when needed.
We'll have to give this some thought. We'll discuss this internally and get back with an answer soon.
What happened?
If you are running behind a corporate firewall which does any kind of TLS interception then you can't interact with Shuttle due to the untrusted certificate in the chain
Version
0.34.1
Which operating system(s) are you seeing the problem on?
Windows
Which CPU architectures are you seeing the problem on?
x86_64
Relevant log output
Duplicate declaration