rustls-native-certs

rustls-native-certs gives rustls-based TLS clients access to the host operating system’s trusted root certificate store instead of requiring a bundled certificate list. It exposes a single function, load_native_certs(), that returns a CertificateResult containing the certificates found on the current platform plus any platform-specific loading errors, so applications can trust the same roots the OS itself trusts.

Under the hood it dispatches to platform-appropriate mechanisms: reading SSL_CERT_FILE/SSL_CERT_DIR when set, the Windows certificate store via schannel on Windows, Keychain via security-framework on macOS, and PEM/DER files discovered via openssl-probe on Linux/BSD. The maintainers now recommend the higher-level rustls-platform-verifier crate for new projects, but this crate remains actively maintained as the lower-level primitive that platform-verifier and other consumers build on where no better alternative exists.

What You Get

• A single load_native_certs() function returning parsed CertificateDer values ready to feed into a rustls RootCertStore
• Platform-specific certificate discovery for Windows (schannel), macOS (Keychain via security-framework), and Unix (openssl-probe plus SSL_CERT_FILE/SSL_CERT_DIR conventions)
• A CertificateResult type that surfaces per-certificate parsing errors alongside successfully loaded certs, instead of failing the whole load on one bad entry
• Test coverage that compares platform-native trust roots against the Mozilla root store (compare_mozilla.rs) to catch discovery regressions

Common Use Cases

• Configuring a rustls ClientConfig to trust the same CAs the operating system trusts, matching curl/browser TLS validation behavior
• Building CLI tools or agents that need to make outbound TLS connections in corporate environments with custom internal CAs installed at the OS level
• Avoiding staleness in a vendored root CA bundle by reading whatever certificates are currently installed on the host
• Serving as the underlying native-certificate-loading primitive inside higher-level crates like rustls-platform-verifier

Under The Hood

Architecture The crate is a thin, focused dispatch layer: src/lib.rs defines the public load_native_certs() API and CertificateResult type, then delegates to one of three platform modules — src/windows.rs, src/macos.rs, or src/unix.rs — selected at compile time via cfg(windows)/cfg(target_os = "macos")/cfg(all(unix, not(target_os = "macos"))) target dependencies, each wrapping the OS-native certificate enumeration API behind the same return type. Tech Stack Pure Rust, 2021 edition, minimum Rust 1.71. Depends on rustls-pki-types for the shared certificate type, plus platform-gated dependencies: schannel on Windows, security-framework on macOS, and openssl-probe on other Unix targets. Dev-dependencies (rustls, rustls-webpki, ring, webpki-roots, x509-parser) are used only for the test suite’s cross-validation against Mozilla’s root list. Code Quality Roughly 480 lines of test code (tests/smoketests.rs, tests/compare_mozilla.rs) against ~636 lines of source, a healthy ratio for a crate whose main risk surface is platform-specific certificate parsing edge cases. compare_mozilla.rs specifically diffs the OS-provided trust store against the well-known Mozilla CA list, catching silent discovery failures that a simple “does it return non-empty” test would miss. Workspace lints (unexpected_cfgs) are configured for the docs.rs cfg flag. API Design The public surface is deliberately minimal — one function, one result type — which makes integration nearly zero-boilerplate: call load_native_certs(), feed the returned certs into a rustls RootCertStore. The README is explicit that the function can be expensive (parsing a ~300KB file on some platforms) and should be called sparingly, which is good developer-facing guidance that heads off a common misuse (calling it per-connection instead of once at startup).