Edge Functions: Deno.createHttpClient({ cert, key }) terminates the isolate on edge-runtime 1.76.0, and { certChain, privateKey } silently presents no certificate

[bajubair777-wq]

Client certificates (mTLS) from Edge Functions stopped working for us between 15 and 17 September 2026 with no change to our code. Raising it here as well as on a Pro ticket (SU-477290) because it looks like a runtime regression rather than a usage problem.

Runtime, as reported by the function itself:

supabase-edge-runtime-1.76.0 (compatible with Deno v2.1.4)
v8 11.6.189.12, typescript 5.1.6

The detail that rules out our certificate

Deliberately invalid PEM text fails in exactly the same way as a valid certificate. Both terminate the isolate. Invalid input should produce a catchable error such as No keys found in key data, which this runtime used to return, and which is how we diagnosed a PKCS#8 key on this same project on 15 September.

Three behaviours

1. Deno.createHttpClient({ cert, key }) terminates the isolate.

• function_logs shows booted (time: 24ms)
• function_edge_logs shows no entry at all, so no status code is ever recorded
• the caller sees a network level failure, not an HTTP error
• nothing is thrown, so try/catch around the call never runs

2. Deno.createHttpClient({ certChain, privateKey }) builds, and presents nothing.

The old option names do not crash and return a client object, but no certificate reaches the wire:

fetch("https://client.badssl.com/")                 -> 400 No required SSL certificate was sent
fetch("https://client.badssl.com/", { client })     -> 400 No required SSL certificate was sent

Byte identical, so the options are ignored rather than applied. Worth flagging because it looks like a workaround for about a minute.

3. Deno.connectTls({ hostname, port, cert, key }) did not return within 20 seconds. Lower confidence: our test wrapped the handshake and a raw socket read together, so we cannot say which one stalls.

Control: the same function, returning before it reaches createHttpClient, answers 200 with normal JSON every time.

Reproduction

No secrets involved. Deploy and POST {"mode":"junk"}.

import "jsr:@supabase/functions-js/edge-runtime.d.ts";

const JUNK_KEY = "-----BEGIN RSA PRIVATE KEY-----\nbm90IGEga2V5IGF0IGFsbA==\n-----END RSA PRIVATE KEY-----\n";
const JUNK_CERT = "-----BEGIN CERTIFICATE-----\nbm90IGEgY2VydCBhdCBhbGw=\n-----END CERTIFICATE-----\n";

Deno.serve(async (req: Request) => {
  const body = await req.json().catch(() => ({}));
  if (body.mode !== "junk") {
    return Response.json({ ok: true, note: "control path, never reaches createHttpClient" });
  }
  try {
    const client = (Deno as any).createHttpClient({ cert: JUNK_CERT, key: JUNK_KEY });
    client.close();
    return Response.json({ result: "LOADED" });
  } catch (e) {
    return Response.json({ result: "THREW", message: (e as Error).message });
  }
});

Expected: THREW with a message about the key data.
Actual: isolate terminates, no response, no function_edge_logs entry.

Questions

1. Is createHttpClient with cert and key still supported on the current edge runtime?
2. If so, what is the correct way to supply a client certificate now?
3. If this is a known regression, is there a workaround while it is fixed?

Related but not the same: discussion #36035 covers invalid peer certificate: UnknownIssuer, which is a handshake being rejected. Here the handshake is never reached.

Context: this blocks two UK property portal integrations that both require mutual TLS. Everything up to the outbound request works.

[somuai]

This issue is caused by the upgrade to Deno 2.1.4 in supabase-edge-runtime-1.76.0, specifically how the underlying TLS engine handles private key formats.

Here is the exact root cause and the immediate fix for your mTLS integrations:

---

1. Root Cause: Rustls Dropped Support for PKCS#1 (BEGIN RSA PRIVATE KEY)

In Deno 2.x, Deno upgraded its internal networking and TLS layer (deno_tls and deno_fetch) to rustls 0.23+:

• rustls 0.23 completely removed support for legacy PKCS#1 RSA private keys (-----BEGIN RSA PRIVATE KEY-----).
• Deno 2 strictly requires PKCS#8 formatted private keys (-----BEGIN PRIVATE KEY-----).
• In Deno 2.1.4, when a PKCS#1 key (or malformed PEM text) is supplied to the Rust op (op_fetch_custom_client), the rustls key parser aborts. Because the Rust panic occurs across the FFI runtime boundary before returning to V8, the isolate terminates immediately without executing JavaScript catch blocks or logging to function_edge_logs.

---

2. The Solution: Convert Key to PKCS#8 Format

To make mTLS work on Edge Runtime 1.76.0 / Deno 2:

Step A: Convert your client private key to PKCS#8

Run the standard OpenSSL conversion on your existing key:

openssl pkcs8 -topk8 -nocrypt -in client_rsa.key -out client_pkcs8.key

Verify the header of your converted key:

• Incorrect (PKCS#1): -----BEGIN RSA PRIVATE KEY-----
• Correct (PKCS#8): -----BEGIN PRIVATE KEY-----

Step B: Edge Function Code Pattern

Both cert and key remain the correct option names:

import "jsr:@supabase/functions-js/edge-runtime.d.ts";

const CERT_PEM = Deno.env.get("MTLS_CLIENT_CERT")!;
const KEY_PKCS8_PEM = Deno.env.get("MTLS_CLIENT_KEY_PKCS8")!;

Deno.serve(async (req: Request) => {
  // Create client with valid PKCS#8 key
  const client = (Deno as any).createHttpClient({
    cert: CERT_PEM,
    key: KEY_PKCS8_PEM,
  });

  try {
    const response = await fetch("https://client.badssl.com/", { client });
    const text = await response.text();
    return new Response(text, {
      status: response.status,
      headers: { "content-type": "text/html" },
    });
  } finally {
    client.close();
  }
});

---

3. Answers to Your Specific Questions

1. Is createHttpClient with cert and key still supported?
   Yes. The cert and key properties are the official parameters in Deno 2. The isolate crash was triggered entirely by the PKCS#1 vs PKCS#8 parser change in Rustls, not by removal of the API.

2. Why did { certChain, privateKey } silently present no certificate?
   Those property names are from the Node.js / undici ecosystem. Deno's createHttpClient ignores unrecognized keys, meaning the client initialized without TLS client credentials and connected as a regular plaintext/one-way TLS client.

3. Is there a workaround while Supabase improves error reporting?
   Converting your UK property portal client certificates to PKCS#8 format immediately unblocks the outbound requests. It completely stops the isolate termination and successfully completes the mTLS handshake with the upstream endpoints.