Repository navigation
Add support for using rustls without a default crypto provider or root certs #4033
Description
I have found these related issues/pull requests
None.
Description
Currently, the feature flags for rustls all include a default crypto provider and a set of root certs.
It would be nice to have the option to completely customize these.
Say, to allow for use of alternative crypto providers like graviola.
Prefered solution
The common way to support this is to add "no-provider" features, and offer a "manual-roots" option.
The downside of supporting this is it will result in an explosion of permutations when it comes to testing.
Even more so if you plan on adding more options in the future, like support for rustls-platform-verifier.
Is this a breaking change? Why or why not?
No, since it would only result in adding features.
Existing rustls option should stay the same.
Activity
abonander commentedon Sep 22, 2025
Ultimately we should probably just allow supplying a manually constructed
rustls::ClientConfig, but we need to be careful with SemVer as we currently upgraderustlsat-will. Using a global provider is also a SemVer hazard as upgradingrustlscould mean it's no longer using the samestatic, which will cause panics at runtime. So I suppose we should just start trackingrustlsin our SemVer compatibility.We could add
rustls-platform-verifierbut I would deprecaterustls-native-rootssince the former is now generally recommended over it instead. I don't want to deal with a huge matrix of TLS features. I would prefer to just have a default that's good enough for 99% of use-cases and then give the user the option to manually configure whatever they need.abonander commentedon Sep 15, 2026
I have opened an RFC issue about reorganizing
rustlsfeatures: #4408