rustls-platform-verifier

Verifies TLS certificates through each operating system's native trust store instead of a bundled, hand-rolled root list.

Library
Cargo
v0.7.0
156stars
Apache License 2.0

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
62/100Good
Development Activity52
Maintenance48
Community76
Maturity52
Momentum20

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
80/100Excellent
Architecture90
Code Quality88
Innovation85
Learning Curve55

rustls-platform-verifier is a drop-in rustls certificate verifier that delegates TLS chain validation to the operating system’s own certificate facilities rather than shipping a static list of trusted roots. On Windows it calls into the Windows certificate verification API, on macOS/iOS it uses Security.framework, and on Android it bridges into the platform’s Trust Manager via JNI and a bundled Kotlin component. Linux, BSD, and WASM targets fall back to rustls-native-certs plus webpki, matching the behavior of a pure-Rust stack where no OS-level verifier exists.

The payoff over webpki-roots or rustls-native-certs alone is that the OS keeps the trust decisions current: newly distrusted CAs, enterprise-injected roots, and OS-level constraints are honored automatically, and on platforms that support it (Windows, Apple, sometimes Android) revocation is checked via OCSP and CRLs rather than skipped entirely. It’s maintained by the rustls project and is already depended on in production by 1Password, Bitwarden, Signal, and rustup, giving its platform-specific edge cases real-world battle testing.

What You Get

  • Native trust-store integration - certificate validation defers to Windows, macOS/iOS Security.framework, or Android’s Trust Manager instead of a bundled root list.
  • Revocation checking where available - OCSP and CRL checks are performed on Windows, Apple platforms, and Android API 24+, catching revoked certificates that pure-webpki verification misses.
  • One-line rustls integration - ClientConfig::with_platform_verifier() and the BuilderVerifierExt/ConfigVerifierExt traits attach the verifier without any custom ServerCertVerifier boilerplate.
  • Consistent fallback for unsupported OSes - Linux, BSD, and WASM automatically use rustls-native-certs + webpki so the same API works across every target.
  • Extra-roots support - Verifier::new_with_extra_roots lets callers augment the platform trust store with additional CAs when the system bundle alone is insufficient.

Common Use Cases

  • Cross-platform Rust clients - desktop and mobile apps built on rustls that need the TLS trust decisions to match what the OS (and its admins) actually trust, including enterprise-injected CAs.
  • Password managers and security-sensitive apps - software like 1Password and Bitwarden where certificate revocation checking and OS-level distrust of compromised CAs materially matter.
  • CLI tools distributed across OSes - tools like rustup that need correct TLS behavior on Windows, macOS, and Linux without maintaining a bundled root list that can drift from what’s actually trusted.
  • Mobile apps needing native trust semantics - Android and iOS apps where certificate pinning or enterprise MDM-injected roots must be honored the same way the platform browser honors them.

Under The Hood

Architecture The crate is a Cargo workspace with the main rustls-platform-verifier package and a companion android-release-support sub-crate that ships prebuilt Android/Kotlin components. Platform dispatch happens in verification/mod.rs, which conditionally compiles and re-exports a platform-specific Verifier type: apple.rs for macOS/iOS/tvOS/watchOS/visionOS via Security.framework, windows.rs (the largest module) for Windows CryptoAPI, android.rs for a JNI bridge into the bundled Kotlin trust-manager component, and others.rs as the rustls-native-certs + webpki fallback for remaining Unix targets and WASM. Every variant implements rustls’s ServerCertVerifier trait, so lib.rs only needs two thin extension traits (BuilderVerifierExt, ConfigVerifierExt) to splice the platform verifier into a standard rustls ClientConfig builder chain. Because verification/mod.rs is the single integration seam between all four backends and the public API, any change to that dispatch layer ripples into every downstream consumer.

Tech Stack Rust 2021 edition, MSRV 1.85, built against rustls 0.23.27 with no bundled crypto provider (callers supply their own, e.g. ring). Platform-specific dependencies are gated per target: security-framework/security-framework-sys + core-foundation on Apple, windows-sys (Win32_Security_Cryptography) on Windows, jni 0.22 plus the android-release-support AAR on Android, and rustls-native-certs + rustls-webpki on other Unix and WASM (webpki-root-certs supplies static roots for WASM specifically). Tooling includes cargo-deny for license and advisory auditing on every Cargo.toml/lock change, cargo-ndk for Android cross-compilation, and clippy runs across nightly build-std targets (tvOS, watchOS, visionOS) in addition to stable Linux/macOS/Windows/Android/iOS/WASM builds.

Code Quality Instead of conventional unit tests, the crate leans on two dedicated integration-test fixture sets: verification_mock, which uses a small Go program (ca.go) to generate synthetic CA/intermediate/end-entity certificate chains with good, revoked, and wrong-EKU variants plus matching OCSP responses; and verification_real_world, which pins real captured certificates from aws.amazon.com and letsencrypt.org to test against actual production CA chains. A shared TestCase struct standardizes expected-vs-actual certificate-validation-error assertions across all four platform backends. CI enforces -D warnings clippy across every supported target and runs a scheduled cargo-deny job to catch yanked dependencies or disallowed licenses — a level of cross-platform test and lint rigor uncommon even for widely-used crates.

API Design The public surface is deliberately small: two extension traits that bolt directly onto rustls’s existing builder pattern, so adopting the platform verifier is a one-line change (ClientConfig::with_platform_verifier()) with no new concepts beyond what rustls users already know. Optional features (dbg, cert-logging, ffi-testing) are off by default and additive, keeping the base dependency footprint minimal. The one real friction point is Android, which requires a non-Cargo Gradle/Kotlin setup step to bundle the native AAR component — documented at length in the README, but a genuine departure from the otherwise zero-config experience on every other platform.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search