scaleway/rustls-platform-verifier

scaleway/rustls-platform-verifier

Description: A certificate verification library for rustls that uses the operating system's verifier

License: Apache-2.0

Stars: 0

Forks: 0

Open issues: 0

Created: 2025-08-19T14:56:14Z

Pushed: 2025-08-19T14:56:45Z

Default branch: main

Fork: yes

Parent repository: rustls/rustls-platform-verifier

Archived: no

README:

rustls-platform-verifier

 !CI

A Rust library to verify the validity of TLS certificates based on the operating system's certificate facilities. On operating systems that don't have these, webpki and/or rustls-native-certs is used instead.

This crate is advantageous over rustls-native-certs on its own for a few reasons:

• Improved correctness and security, as the OSes CA constraints will be taken into account.
• Better integration with OS certificate stores and enterprise CA deployments.
• Revocation support via verifying validity via OCSP and CRLs.
• Less I/O and memory overhead because all the platform CAs don't need to be loaded and parsed.

This library supports the following platforms and flows:

| OS | Certificate Store | Verification Method | Revocation Support | |----------------|-----------------------------------------------|--------------------------------------|--------------------| | Windows | Windows platform certificate store | Windows API certificate verification | Yes | | macOS (10.14+) | macOS platform roots and keychain certificate | macOS Security.framework | Yes | | iOS | iOS platform roots and keychain certificates | iOS Security.framework | Yes | | Android | Android System Trust Store | Android Trust Manager | Sometimes[^1] | | Linux | System CA bundle, or user-provided certs[^3] | webpki | No[^2] | | WASM | webpki roots | webpki | No[^2] |

[^1]: On Android, revocation checking requires API version >= 24 (e.g. at least Android 7.0, August 2016). When available, revocation checking is only performed for the end-entity certificate. If a stapled OCSP response for the end-entity cert isn't provided, and the certificate omits both a OCSP responder URL and CRL distribution point to fetch revocation information from, revocation checking may fail.

[^2]: The fall-back webpki verifier configured for Linux/WASM does not support providing CRLs for revocation checking. If you require revocation checking on these platforms, prefer constructing your own WebPkiServerVerifier, providing necessary CRLs. See the Rustls [ServerCertVerifierBuilder] docs for more information.

[^3]: On Linux the [rustls-native-certs] and [openssl-probe] crates are used to try and discover the system CA bundle. Users may wish to augment these certificates with [webpki-roots] using [Verifier::new_with_extra_roots] in case a system CA bundle is unavailable.

[ServerCertVerifierBuilder]: https://docs.rs/rustls/latest/rustls/client/struct.ServerCertVerifierBuilder.html [Verifier::new_with_extra_roots]: https://docs.rs/rustls-platform-verifier/latest/rustls_platform_verifier/struct.Verifier.html#method.new_with_extra_roots [rustls-native-certs]: https://github.com/rustls/rustls-native-certs [openssl-probe]: https://github.com/alexcrichton/openssl-probe [webpki-roots]: https://github.com/rustls/webpki-roots

Deployment Considerations

When choosing to use rustls-platform-verifier or another trust store option, these differences are important to consider. They are primarily about root certificate availability:

| Backend | Updates | Roots used | Supports system-local roots | |-------------------------------------------------|---------------------------------|-------------------------------------------------------------------------------------------------------|------------------------------| | rustls-platform-verifier (non-Linux/BSD) | Updated by OS | System store, with full (dis)trust decisions from every source available. | Yes | | rustls-native-certs + webpki | Updated by OS | System store, with no (dis)trust decisions. All roots are treated equally regardless of their status. | Yes, with exceptions | | webpki-roots + webpki | Static, manual updates required | Hardcoded Mozilla CA roots, limited support for constrained roots. | No |

In general: It is the opinion of the rustls and rustls-platform-verifier teams that this is the best default available for client-side libraries and applications making connections to TLS servers when running on common operating systems. This is because it gets both live trust information (new roots, explicit markers, and auto-managed CRLs) and better matches the common expectation of apps running on that platform (to use proxies, for example). Otherwise, it becomes your maintenance burden to ship updates right away in order to handle increasing numbers of positive and negative trust events in the WebPKI/certificate ecosystem, or risk availability and security concerns.

Linux/BSD

As of the time of writing, rustls-platform-verifier on these OSes only loads the trust stores from the OS once upon startup. This is the same behavior as rustls-native-certs, but the abstraction allows better behavior on the other platforms without extra work for downstreams.

Other

Alternatively, there is a clear answer to use static webpki-roots in your application instead if you are deploying containerized applications frequently, where root store changes will make it to production faster and any possibly used trust root is static by definition.

Even though platform verifiers are sometimes implemented in memory-unsafe languages, it is very unlikely that Rust apps using this library will become a point of weakness. This is due to either using a smaller set of servers or just being less exposed then other critical functions of the operating system, default web browser, etc. But if your activity is identical or close to one of the following examples that process large amounts of untrusted input, a 100% Rust option like webpki is a more secure option:

• Seeing how many TLS servers rustls with a specific configuration can connect to.
• Harvesting data from various untrusted TLS endpoints exposed on the internet.
• Extracting info from a known-evil endpoint.
• Scanning all TLS certificates on the open internet.…