stack: outbound HTTPS from Postgres (http, pg_net) fails certificate verification on native darwin-arm64
Maintainers usually reply within 1 day
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 32/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- macos, postgresql, typescript
- Domain
- cli, databases, developer-experience
Research direction
Start from how supabase start --runtime native launches the bundled darwin-arm64 Postgres (experimental stack) and which env vars it actually injects into that process. Trace OPENSSLDIR / CA lookup for the shipped OpenSSL dylib versus host /etc/ssl/cert.pem, and how http vs pg_net sessions pick up curl/OpenSSL options. Done when HTTPS http_get/pg_net succeed on native like Docker without a per-session CURLOPT_CAINFO workaround.
Written by the indexing model from the issue text.
Description
Affected area
Local development
Supabase CLI version
2.119.0
Operating system
macOS 26.3 (Apple silicon), Postgres artifact 17.11.0.002-r0 (darwin-arm64). Linux not tested.
Installation method
npm (supabase package)
Command
SUPABASE_EXPERIMENTAL_STACK=1 supabase start --runtime native
Actual output
Every HTTPS request made from inside Postgres fails. Plain HTTP works.
create extension http with schema extensions;
select status from extensions.http_get('https://example.com');
-- ERROR: SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
create extension pg_net;
select net.http_get('https://example.com'); -- id 1
select net.http_get('http://example.com'); -- id 2
select id, status_code, error_msg from net._http_response;
-- 1 | (null) | SSL peer certificate or SSH remote key was not OK
-- 2 | 200 |
Cause, as far as I can tell:
- The bundled
libcrypto.3.dylibhasOPENSSLDIRcompiled as/nix/store/5ffn4pdw6mvabzrrlss7k3gabnqw2f9g-openssl-3.6.0/etc/ssl, which does not exist on the host, so OpenSSL has no trust store. SSL_CERT_FILEcannot fix it from outside: the Postgres process gets a fixed environment (DYLD_LIBRARY_PATH,HOME,LANG,NIX_PGLIBDIR,PATH,PGDATA,PGSODIUM_KEY_FILE,POSTGRES_*,PWD,SHLVL,TMPDIR). ExportingSSL_CERT_FILE=/etc/ssl/cert.pembeforesupabase startreaches the stack host process but not Postgres.
The only workaround I found is per session, and only for http:
select extensions.http_set_curlopt('CURLOPT_CAINFO', '/etc/ssl/cert.pem');
It does not help pg_cron jobs, triggers or pg_net, which run in their own sessions.
Expected behavior
HTTPS from http and pg_net works on native as it does on Docker. For example, the CLI could set SSL_CERT_FILE for Postgres to the host bundle (/etc/ssl/cert.pem on macOS), or the artifact could ship a CA bundle and point OPENSSLDIR at it.
Steps to reproduce
mkdir repro && cd repro && supabase initSUPABASE_EXPERIMENTAL_STACK=1 supabase start --runtime native- Run the SQL above against the DB URL from
supabase status.
I investigated this with help from an AI coding assistant (Claude Code), which also drafted this text. The results above come from real runs.
- Dominant language
- TypeScript
- Stars
- 2.4k
- Forks
- 531
- Avg merge
- 1d 3h
- Merged PRs (30d)
- 332
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from supabase/cli
-
stack: the HTTP gateway closes idle keep-alive connections after 5 s, so a client whose event loop is blocked gets ECONNRESET (`fetch failed`) on its next requestPossibly taken @7ttp claimed this 3 days ago. Open🐛 Bug supabase/cli
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
supabase/cli#6975 · 1 assignee ·
Maintainers usually reply within 1 day
-
📘 Docs supabase/cli
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
🐛 Bug supabase/cli
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
🐛 Bug supabase/cli
Difficulty 3/5 Half a day Newbie friendliness 68/100
Maintainers usually reply within 1 day
-
stack: functions serve fails with "Dependent … blocks restart of …" after a plain supabase startOpen🐛 Bug supabase/cli
Difficulty 4/5 3-5 days Newbie friendliness 38/100
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
wardian-app/Wardian#1603 ·
Maintainers usually reply within 1 day
-
Sign the pledgeOpen
Difficulty 1/5 Under an hour Newbie friendliness 85/100
input-output-hk/devx-updates#168 ·
Maintainers usually reply within 1 day
-
triage
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
github/docs#46222 · 1 comment ·
Maintainers usually reply within 1 day
-
agent-ready area: config area: skills type: chore upstream: brain-kit
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
dev experience frontend good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
cuttle-cards/cuttle#1403 ·
Maintainers usually reply within 1 day