webpki

rustls-webpki is a fork of Brian Smith’s original webpki crate, maintained by the Rustls project to handle certificate-related tasks required for implementing TLS clients and servers. It parses DER-encoded X.509 certificates, builds and validates certification paths against a caller-supplied set of trust anchors, and checks that an end-entity certificate is valid for a given DNS name or IP address under its stated usage constraints.

The crate deliberately does not implement any cryptographic primitives itself. Instead it depends on a CryptoProvider-style implementation — commonly rustls-aws-lc-rs or rustls-ring — so consumers can choose their cryptography backend while webpki focuses purely on certificate parsing, path building, and policy enforcement. It also stays no_std by default (with optional alloc and std features), making it usable in constrained and embedded contexts as well as full server deployments.

Because it underlies Rustls, rustls-webpki is exercised at very large scale across the Rust TLS ecosystem, and its test suite includes real-world certificate corpora (Cloudflare, Netflix, Amazon, WebPKI test vectors from web-platform-tests) plus the shared x509-limbo interoperability test suite used across multiple X.509 implementations.

What You Get

• DER certificate parsing via Cert and EndEntityCert types that avoid heap allocation on the hot path
• Trust anchor representation (anchor_from_trusted_cert) so callers explicitly bootstrap the roots they trust
• Certification path building and verification (PathBuilder, VerifiedPath) against a supplied trust anchor set and intermediates
• DNS name and IP address validation against certificate SAN entries via the subject_name module
• Certificate revocation list (CRL) support, including borrowed and owned revocation lists with configurable revocation policies
• Signed Certificate Timestamp (SCT) processing for Certificate Transparency verification
• A raw public key entity type (RawPublicKeyEntity) for RFC 7250 raw-public-key based validation flows
• no_std compatibility by default, with opt-in alloc and std features for environments that need heap or libstd support

Common Use Cases

• Providing the certificate-chain validation logic for a TLS client or server built on Rustls
• Validating a peer’s leaf certificate against a pinned or system trust anchor set in a custom network client
• Checking certificate revocation status against a CRL as part of a stricter TLS validation policy
• Embedding X.509 validation in no_std or resource-constrained environments (e.g. embedded TLS stacks) that cannot pull in libstd
• Validating raw public keys instead of full certificate chains in RFC 7250-based deployments

Under The Hood

Architecture The crate is organized around a small set of cooperating modules rather than one monolithic verifier: der.rs provides a hand-rolled zero-copy DER parser (built on the untrusted crate) that every other module consumes; cert.rs and x509.rs turn parsed DER into structured certificate views; verify_cert.rs (the largest module, ~1500 lines) owns path building and the core RFC 5280-style validation state machine via PathBuilder/VerifiedPath; subject_name/ isolates DNS-name and IP-address matching; crl/ isolates revocation-list parsing and policy; and trust_anchor.rs/end_entity.rs/rpk_entity.rs define the entry-point types callers interact with. This separation means the DER parser and name-matching logic can be reasoned about and fuzzed independently of the path-building state machine, and the public API surface (re-exported from lib.rs) is a deliberately narrow set of types rather than exposing internal parsing structures. Because the crate has no built-in crypto, signature verification is delegated through algorithm-identifier plumbing (signed_data.rs, ring_algs.rs, aws_lc_rs_algs.rs) to whatever CryptoProvider the caller supplies, which keeps the validation logic and the cryptographic implementation cleanly decoupled — changing crypto backends does not touch the path-building code at all.

Tech Stack The crate targets no_std by default (#![no_std] in lib.rs) with alloc and std as additive Cargo features, and depends on very few crates in its default build: rustls-pki-types (aliased as pki-types) for shared PKI type definitions across the Rustls ecosystem, and untrusted for safe zero-copy byte-slice parsing. Dev-dependencies pull in rustls-aws-lc-rs, rustls-ring, and rustls-post-quantum to exercise real crypto providers in tests, plus rcgen for generating test certificates, x509-parser and chrono for cross-checking against an independent implementation, and the shared limbo-harness-support crate to run the x509-limbo interoperability suite. The crate enforces edition = 2021 with rust-version = 1.83, uses cargo-semver-checks lint configuration and a deny.toml for license/advisory auditing, and ships a fuzz/ directory with cargo-fuzz targets alongside cifuzz.yml for continuous fuzzing.

Code Quality Testing is extensive and multi-layered: unit tests live alongside implementation code (e.g. 46 #[test] functions in crl/types.rs, 85 in alg_tests.rs), and a separate tests/ directory runs integration-style suites against real-world certificate corpora — Amazon, Cloudflare DNS, Netflix, and web-platform-tests fixtures — plus the shared x509-limbo cross-implementation test suite and dedicated CRL, client-auth, and custom-EKU test files. CI (ci.yml) runs cargo fmt checks, clippy, and the test suite, and the crate additionally has a continuous fuzzing setup via cifuzz.yml. Lint configuration in Cargo.toml is strict: #![deny(missing_docs, clippy::as_conversions)] at the crate root, plus warn-level lints for elided lifetimes, unreachable pub items, and manual-let-else patterns, indicating a codebase held to a stricter-than-default standard for a security-critical library.

What Makes It Unique Unlike most X.509 libraries, rustls-webpki deliberately does not try to be a general-purpose certificate toolkit — it has no support for self-signed certificates, no certificate/keypair generation, and no access to arbitrary extensions or human-readable subject display, all called out explicitly in its README as intentional limitations. That narrow scope, combined with no_std-first design and a hard dependency boundary between certificate logic and cryptographic implementation, lets it serve as a minimal, auditable trust-decision engine purpose-built for Rustls rather than a Swiss-army-knife X.509 library — a tradeoff that shows up directly in its unusually strict lint posture and fuzzing investment for a crate of its size.