[Feature Request] Support custom CA certificates for Edge Functions local development (corporate proxy/Zscaler)

[bhatiashivam]

Summary

When running supabase start or supabase functions serve behind a corporate SSL inspection proxy (e.g., Zscaler, Netskope, Blue Coat), the Edge Runtime container fails to bootstrap because it cannot verify SSL certificates for external dependencies like deno.land and esm.sh.

Problem

Corporate security tools intercept HTTPS traffic and present their own certificates. While macOS/Windows host machines trust these certificates (they're installed in the system keychain), Docker containers running the Edge Runtime don't have access to them.

Error Message

worker boot error: failed to bootstrap runtime: failed to create the graph: 
Import 'https://deno.land/std/http/status.ts' failed: error sending request for url 
(https://deno.land/std/http/status.ts): client error (Connect): invalid peer certificate: UnknownIssuer
    at file:///root/index.ts:1:42

Environment

• macOS 15.x with Docker Desktop
• Corporate network with Zscaler SSL inspection active
• Supabase CLI v2.78.1
• Edge Runtime v1.71.0

Current Workaround Attempts

1. Using DENO_TLS_CA_STORE=system (Partial Solution)

As per PR #184 and PR #633, the Edge Runtime supports DENO_TLS_CA_STORE=system to use system certificates.

# config.toml
[edge_runtime.secrets]
DENO_TLS_CA_STORE = "system"

This is set correctly but doesn't work because:

• The container's system CA store doesn't include the corporate proxy's CA certificate
• There's no CLI option to inject custom CA certificates into the container

2. Using DENO_CERT (Doesn't Work for Bootstrap)

[edge_runtime.secrets]
DENO_CERT = "/path/to/ca-bundle.pem"

The file is mounted and the env var is set, but the Edge Runtime's bootstrap phase (importing from deno.land) happens before user code runs, so DENO_CERT doesn't help.

3. Verified Docker SSL Works with CA Cert

When manually testing with the corporate CA mounted:

# This works when CA is mounted
docker run --rm -v /tmp/zscaler-ca.pem:/etc/ssl/certs/ca-certificates.crt:ro \
  alpine wget -q -O /dev/null https://deno.land && echo "SSL: OK"
# Output: SSL: OK

Proposed Solution

Add a CLI option to mount custom CA certificates into the Edge Runtime container's system CA store:

Option A: CLI Flag

supabase start --ca-cert /path/to/corporate-ca.pem
supabase functions serve --ca-cert /path/to/corporate-ca.pem

Option B: Config file option

# config.toml
[edge_runtime]
ca_cert_path = "./certs/corporate-ca.pem"

Implementation

When this option is provided, the CLI would:

1. Mount the CA certificate into the container at /usr/local/share/ca-certificates/
2. Run update-ca-certificates or append to /etc/ssl/certs/ca-certificates.crt
3. Set DENO_TLS_CA_STORE=system automatically

Impact

This affects developers at many enterprises who use:

• Zscaler (used by Netflix, Siemens, etc.)
• Netskope
• Blue Coat / Symantec
• Palo Alto Prisma Access
• Cisco Umbrella
• Any corporate proxy with SSL inspection

Currently, these developers cannot run Edge Functions locally at all, which significantly impacts the local development experience that Supabase promotes.

Related Issues/PRs

• supabase/edge-runtime#184 - Added DENO_TLS_CA_STORE support
• supabase/edge-runtime#633 - Fixed file fetcher to respect DENO_TLS_CA_STORE
• supabase/edge-runtime#664 - Added ca-certificates to Dockerfile

Workaround for Now

The only current workarounds are:

1. Ask IT to whitelist deno.land, esm.sh, dl-cdn.alpinelinux.org from SSL inspection
2. Connect to a non-corporate network (mobile hotspot)
3. Use production Edge Functions and skip local testing
4. Build a custom Edge Runtime Docker image with corporate CA baked in (not practical)

None of these are acceptable for a "100% local development" experience.

Additional Context

I've thoroughly tested this with:

• Docker Desktop factory reset
• Various DENO_CERT and DENO_TLS_CA_STORE configurations
• Different CA bundle formats
• The Zscaler CA certificate works perfectly when manually mounted into test containers

The issue is specifically that the Supabase CLI doesn't provide a way to mount custom CAs into the Edge Runtime container.