The reqwest backend (which uses native-tls and thus schannel and thus the Windows cert store) is the default on Windows, so it shouldn't be using curl. https://github.com/rust-lang/rustup.rs/commit/6389676b6bf211...
If you must use an older rustup, set `$env:RUSTUP_USE_REQWEST` (or `$env:RUSTUP_USE_HYPER` for an even older rustup) to `1`
Re:Rust's 2019 Roadmap
by windwake12 on Tuesday April 23, 2019 @03:30PM
(#19732017)
According to Google/SO curl can indeed be built/configured to use the Windows cert store, seems that would be a better fix?
Re:Rust's 2019 Roadmap
by moosingin3space on Tuesday April 23, 2019 @04:41PM
(#19732617)
Another fix could be to use Hyper with tokio-tls. Under the hood, that package uses Windows schannel, macOS SecureTransport, and a dynamically-linked openssl on everything else.
Re:Rust's 2019 Roadmap
by littlestymaar on Tuesday April 23, 2019 @10:39PM
(#19735098)
It already uses `reqwest`, which uses schannel. See https://news.ycombinator.com/item?id=19732721
It went from "rebase and I'll merge" to not a single word anymore about how it might be merged.
The Windows support thing is this: rustup/curl doesn't use Windows' own certificate store. Where employers put the TLS certificate for their intercepting proxies.
curl itself has the -k option, so the user can override the check (much, much easier than preparing a certificate bundle for curl – and since the employer intercepts and decrypts the traffic anyway, there is no security issue).
rustup calls curl without that flag. The pull request was to teach rustup to call curl with -k.
(I know that it doesn't solve the whole problem, because cargo itself needs to support it, as well)