Bug Fix: Ensure rustls backend respects system-native certificate authorities

Fixes #79059

Issue:

When Next.js (specifically Turbopack's turbo-tasks-fetch module) uses reqwest with rustls as the TLS backend, it does not, by default, respect custom Certificate Authorities (CAs) that have been added to the operating system's native trust store. This is because the rustls-tls feature in reqwest typically defaults to using a bundled set of web CAs (e.g., via webpki-roots) and does not automatically load CAs from the OS.

This becomes problematic in environments where network traffic is routed through SSL-inspecting proxies (common in corporate settings) or when accessing internal HTTPS services that use certificates signed by an internal/custom CA. In such cases, turbo-tasks-fetch would fail with certificate validation errors, as it wouldn't trust the custom CA.

The native-tls backend for reqwest, on the other hand, generally does use the OS's native trust store and thus works correctly in these scenarios. The goal is to achieve consistent behavior with rustls when it's selected.

Fix:

This patch modifies the turbopack/crates/turbo-tasks-fetch/Cargo.toml to change the reqwest feature from rustls-tls to rustls-tls-native-roots for the relevant target configurations.

The rustls-tls-native-roots feature flag for reqwest enables the rustls-native-certs crate, which allows rustls to load root certificates from the platform's native certificate store. This ensures that if a custom CA is trusted by the OS, reqwest (when using rustls) will also trust it, mirroring the behavior of native-tls.

File Changed:

• turbopack/crates/turbo-tasks-fetch/Cargo.toml

Diff:

--- a/turbopack/crates/turbo-tasks-fetch/Cargo.toml
+++ b/turbopack/crates/turbo-tasks-fetch/Cargo.toml
@@ -21,7 +21,7 @@ workspace = true
 reqwest = { workspace = true, features = ["native-tls"] }
 
 [target.'cfg(not(any(all(target_os = "windows", target_arch = "aarch64"), target_arch="wasm32")))'.dependencies]
-reqwest = { workspace = true, features = ["rustls-tls"] }
+reqwest = { workspace = true, features = ["rustls-tls-native-roots"] }
 
 [dependencies]
 anyhow = { workspace = true }

How to Reproduce/Verify (Conceptually):

While setting up a full environment with a custom CA and an HTTPS server using it can be involved, the following conceptual steps and sample code illustrate the issue:

1. Environment Setup (Hypothetical):

   • Create a custom Certificate Authority (CA).
   • Generate a server certificate and key, signed by this custom CA.
   • Configure a simple HTTPS server to use this server certificate.
   • Add the custom CA certificate to your operating system's trust store (e.g., Keychain Access on macOS, update-ca-certificates on Linux).

2. Sample Rust Code:
   A minimal Rust program is provided in the repro-custom-ca directory (see repro-custom-ca/src/main.rs and repro-custom-ca/Cargo.toml). This program attempts to fetch a URL using reqwest.

   • repro-custom-ca/src/main.rs
   • repro-custom-ca/Cargo.toml

3. Testing the Behavior:
   Modify repro-custom-ca/Cargo.toml to switch between reqwest features:

   • With features = ["rustls-tls"] (and default-features = false):

     reqwest = { version = "0.11", features = ["rustls-tls"], default-features = false }

     If you run cargo run in repro-custom-ca against your custom HTTPS server, reqwest (using rustls) would likely fail with a certificate validation error because it wouldn't find the custom CA in its bundled root list.

   • With features = ["rustls-tls-native-roots"] (and default-features = false) - THE FIX:

     reqwest = { version = "0.11", features = ["rustls-tls-native-roots"], default-features = false }

     Running cargo run now should succeed. reqwest (using rustls) will load the custom CA from the OS trust store, and the certificate validation will pass.

   • For comparison, with features = ["native-tls"] (and default-features = false):

     reqwest = { version = "0.11", features = ["native-tls"], default-features = false }

     This would also typically succeed, as native-tls usually respects OS-level CAs. The patch aims to make rustls behave similarly in this regard.

Conclusion:

This change ensures more consistent and robust behavior for turbo-tasks-fetch when dealing with HTTPS connections in diverse network environments, particularly those requiring custom CAs. It aligns the rustls backend's CA handling with that of native-tls and standard browser behavior.