webpki-roots

webpki-roots bundles Mozilla’s set of trusted Certificate Authority root certificates directly into a Rust binary as a no_std-compatible constant (TLS_SERVER_ROOTS), so applications using rustls or webpki can validate TLS certificate chains without depending on the host operating system’s certificate store. This makes it especially useful for statically-linked binaries, containers, and cross-platform deployments where a consistent, known-good root store matters more than relying on whatever CA bundle happens to be installed on the machine.

The crate is part of a small workspace alongside webpki-root-certs (which exposes full self-signed X.509 certs for projects that need them) and webpki-ccadb (internal tooling that regenerates the root list deterministically from the Common CA Database, CCADB). Because roots are compiled in rather than loaded at runtime, updating trusted CAs requires recompiling and redeploying the application — a tradeoff the README calls out explicitly, recommending rustls-platform-verifier instead for end-user-deployed applications that can’t always be recompiled.

What You Get

• A no_std-compatible TLS_SERVER_ROOTS constant containing Mozilla’s full trusted root certificate set
• Direct drop-in compatibility with rustls::RootCertStore and the webpki crate
• Deterministic, reproducible generation from the Common CA Database (CCADB) via the sibling webpki-ccadb tooling
• A companion webpki-root-certs crate for projects needing full self-signed X.509 certs rather than webpki’s trust-anchor format
• Conformance tests (tests/verify.rs, tests/codegen.rs) validating the generated root list against real certificate chains

Common Use Cases

• Statically-linked Rust binaries and containers that need a consistent, known-good CA trust store independent of the host OS
• TLS clients built on rustls/webpki that need to work identically across Linux, Windows, macOS, and minimal/embedded targets
• Reproducible-build systems where relying on a mutable system certificate store would break build determinism
• Cross-compiled or no_std environments lacking access to an OS-provided certificate store at all

Under The Hood

Architecture - webpki-roots/src/lib.rs is a ~4,600-line, #![no_std], #![forbid(unsafe_code)] module containing exactly one meaningful item: a TLS_SERVER_ROOTS: &[TrustAnchor<'static>] constant array, each entry a pre-parsed trust anchor (subject, SPKI, optional name constraints) derived from a real CA certificate; the file’s header states it is auto-generated from the Mozilla IncludedCACertificateReportPEMCSV report via the sibling webpki-ccadb crate (344 lines), which fetches and parses CCADB data deterministically so the generation step is independently verifiable.

Tech Stack - Pure Rust with a single runtime dependency (pki-types) and no allocator or OS dependency at all, keeping the crate usable in no_std and embedded targets; dev-dependencies (aws-lc-rs, rustls, webpki, rcgen, x509-parser) are used only for the test/verification suite, not shipped to consumers.

Code Quality - tests/verify.rs and tests/codegen.rs validate the generated root list against real certificate chains (including fixture DER data for edge cases like the Turkish TUBITAK root), and strict lint attributes (deny(elided_lifetimes_in_paths, trivial_casts, unused_qualifications, ...)) are enforced at the crate root, reflecting the security-sensitive nature of shipping a trust store.

API Design - The public surface is a single constant, so integration is a one-line RootCertStore { roots: webpki_roots::TLS_SERVER_ROOTS.to_vec() } call with essentially no learning curve; the explicit tradeoff, documented prominently in the README, is that trust updates require a recompile-and-redeploy cycle rather than a runtime refresh, which the maintainers flag as unsuitable for end-user-deployed applications that can’t be recompiled on demand.