You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We recently released the rustls-platform-verifier crate, and the rustls team believes this is probably the best option for most client use cases (especially on platforms like Windows, macOS, iOS and Android), since it reuses the platform verifier instead of more naively trying to find installed roots (which might be subject to additional constraints when used in the platform verifier).
This has been used for years inside the 1Password multi-platform client codebase, so it is more mature than it might seem at first glance.
I actually started adding support for this, but unfortunately it doesn't currently have great support for adding additional roots on some platforms, so the current form of feature additivity that reqwest uses (adding both webpki-roots and rustls-native-certs) doesn't work on some platforms (it only works on Linux, where it is needed the most because there is no real platform verifier).
I think this should probably become the default going forward.
Reacted by stormshield-gt, Hantong Chen, xkeyC, Daniel McCarney, Tudyx, Paolo Barbolini, Christoph Settgast, Igor Novgorodov, T-256, Emil Eriksson and 23 more
Seems like a good goal. You mentioned that it can't currently support the feature additivity that reqwest exposes. Will it at some point? Or is that a non-goal?
There's an existing issue upstream for the missing feature: rustls/rustls-platform-verifier#58 I think we're all in favour, it just hasn't been implemented. IMO knowing it's a blocker for reqwest would help motivate getting around to it 👍
Not sure it should be a blocker for reqwest -- but yes, we do want to support it eventually. While it is opt-in for reqwest, I don't think it needs to be a blocker?
Is this the proper way to use the library until there is an official feature? The documentation mentions that applications should call the install default method early in main but I can't find examples on applications doing so. I can only find an example from rustup doing it manually.
Is this the proper way to use the library until there is an official feature? The documentation mentions that applications should call the install default method early in main but I can't find examples on applications doing so. I can only find an example from rustup doing it manually.
Bumping this up, that feels important; it's also the blocker for Element to support TLS 1.3, which is important, given the security focus of Element on itself.
Activity
djc commentedon Apr 25, 2024
@seanmonstar any feedback?
seanmonstar commentedon Apr 26, 2024
Seems like a good goal. You mentioned that it can't currently support the feature additivity that reqwest exposes. Will it at some point? Or is that a non-goal?
cpu commentedon Apr 26, 2024
There's an existing issue upstream for the missing feature: rustls/rustls-platform-verifier#58 I think we're all in favour, it just hasn't been implemented. IMO knowing it's a blocker for reqwest would help motivate getting around to it 👍
djc commentedon Apr 26, 2024
Not sure it should be a blocker for reqwest -- but yes, we do want to support it eventually. While it is opt-in for reqwest, I don't think it needs to be a blocker?
seanmonstar commentedon Oct 13, 2024
Just to ease finding the status, as commented in #2286: it's blocked on being an additive feature.
djc commentedon Oct 13, 2024
(I think the work to enable that is pretty much done upstream, just needs a release.)
ofek commentedon Oct 13, 2024
Is this the proper way to use the library until there is an official feature? The documentation mentions that applications should call the
install defaultmethod early in main but I can't find examples on applications doing so. I can only find an example from rustup doing it manually.djc commentedon Oct 14, 2024
Yup, that looks fine.
ofek commentedon Oct 14, 2024
Great, thanks! Is there an example of setting it globally at the start of an application so one does not have to create a client manually?
djc commentedon Oct 15, 2024
That's not a thing for the
ServerCertVerifier, only for theCryptoProvider, see rustls/rustls#1821.Turbopack: Add an option to use system TLS certificates (fixes #79060, …
Turbopack: Update bundled webpki-roots (#81906)
alexander-potemkin commentedon Aug 14, 2025
Bumping this up, that feels important; it's also the blocker for Element to support TLS 1.3, which is important, given the security focus of Element on itself.
csett86 commentedon Dec 31, 2025
I think this is now also closed via #2891 and released in v0.13.0. Thank you!