Question
Global certificate bypass flag versus per-request trust policy in Deno
Kavi River
0 reputation · 12 Jul 2023, 19:43 UTC
132.2K views1
Loading…
0 reputation · 12 Jul 2023, 19:43 UTC
Deno validates HTTPS server certificates against the system trust store by default. The --unsafely-ignore-certificate-errors flag disables validation globally for every network call in the process, leaving no documented way to relax trust for internal services while keeping strict validation for public APIs.
This creates a binary choice in current Deno releases: enforce system trust everywhere or disable verification for the entire runtime. Applications that must reach both secure public endpoints and internal services with self-signed certificates cannot isolate the relaxation to specific calls.
Is there a planned API for per-request certificate configuration? If not, what constraint prevents isolating trust settings to individual fetch calls?
34275 reputation · 12 Jul 2023, 21:37 UTC
No. Deno 1.x and 2.x do not provide a per-request certificate or TLS trust policy for fetch. The only built-in relaxation is --unsafely-ignore-certificate-errors, and it is process-wide: when enabled, certificate validation is disabled for every outbound TLS connection in that Deno process, including calls to public APIs and dependency fetches.
Deno initializes one shared TLS configuration at process startup. Its networking layer, built on hyper and rustls, creates a single client configuration that owns the root certificate store and verifier. Every fetch call reuses that shared configuration; there is no code path to build a separate ClientConfig, inject custom CA certificates, or override hostname verification for an individual request.
Deno's fetch signature intentionally mirrors the browser RequestInit dictionary, which has no tls, ca, or verify fields. Adding Deno-specific TLS options would diverge from web-compatible fetch semantics and is not currently supported.
denojsnginx, stunnel, or mitmproxy on localhost and configure it to trust your internal CA. Point internal fetch calls at http://localhost:PORT while public HTTPS calls continue using Deno's system trust store.--unsafely-ignore-certificate-errors, optionally scoped to internal hostnames, for internal traffic only. Communicate over stdin/stdout or localhost HTTP so the main process remains strict.# Confirm the only certificate-related runtime flag
deno --help | grep -i certificate
# Confirm fetch RequestInit has no TLS fields
deno types | grep -A 25 "interface RequestInit"
# Check the Deno version
deno --version
Run these on the target runtime before adopting a workaround. Behavior may differ on Deno Deploy, where the bypass flag is unsupported.
Are you deploying to Deno Deploy or Deno Subhosting, or to self-hosted infrastructure?
--unsafely-ignore-certificate-errors is not supported. A proxy or outbound allow-list is required.This detail changes the recommendation because it determines whether the process-wide flag is available at all.
Use comments to ask for clarification. Post a solution as an answer.
5,700 reputation · 12 Jul 2023, 19:58 UTC
Deno’s --unsafely-ignore-certificate-errors turns off certificate verification for every network request made by the process. The TLS context is created once per runtime, so the runtime cannot apply a different policy to a single fetch call. This design choice keeps the networking stack simple and avoids accidental leaks of insecure connections.
DENO_TLS_CA_CERTS to a PEM file that contains your internal CA. This adds the CA to the trust store without disabling verification globally.node-fetch via Deno’s --import-map) that allows per‑request options.Adding a per‑request option would require a major revision of Deno’s networking stack, so no stable API is currently planned. Until then, the above techniques are the safest ways to balance strict validation for public endpoints with relaxed trust for trusted internal services.