Unable to connect to database while enforcing SSL

[jeffrey-clarion]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

I am trying to connect to a database with SSL enforcement enabled from my local computer. I have followed the local development cli guide here: https://supabase.com/docs/guides/local-development/overview and the SSL guide here: https://supabase.com/docs/guides/platform/ssl-enforcement. I have downloaded the CA from my supabase project as advised in the ssl-enforcement docs.

I've run these commands:
supabase login
supabase link --project-ref
supabase db pull

When I run the db pull command I get this error message:
failed to connect to postgres: failed to connect to host=aws-0-us-east-1.pooler.supabase.com user=postgres.<project_id> database=postgres: server error (FATAL: SSL connection is required (SQLSTATE XX000))

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Create a supabase project in the CLI
2. Enable SSL (full enforcement) in the database settings
3. Download the SSL Certificate from the Database Settings page
4. Create file ~/.postgres/root.crt
5. Run cat {location of downloaded prod-ca-2021.crt} >> ~/.postgres/root.crt
6. Run "supabase login"
7. Run "supabase link --project-ref "
8. Run "supabase db pull"## Expected behavior
   The "supabase db pull" command succeeds, pulling the migration history from my remote project

Screenshots

If applicable, add screenshots to help explain your problem.

System information

• OS: macOS 14.5, Apple M1 Pro,
• Version of Supabase CLI: 2.15.8
• Version of Node.js: v18.20.0

Additional context

Add any other context about the problem here.

[Hallidayo]

Hi @jeffrey-clarion - I've moved this over to the cli repo.

[manizm]

supabase cli is giving me the similar error:

[select_097e65a]: Executing query failed: SSL connection is required
main worker has been destroyed 

My supabase cli version is 2.34.3 and I am running it via pnpm dlx supabase db pull

I have enabled SSL a long time ago but I am consistently getting this issue just recently. I can also connect to db via psql properly. The root.crt also exist in the same place as suggested via docs.

I tried passing db-url option so I can explicitly type ssl related options in query but the result was the same

[sweatybridge]

Thanks, I can confirm this is a bug. We will work on it soon.

[djechlin]

Same. I'm on 2.34.3.

1. Make super CLI is 2.34.3
2. Get cert from project dashboard.
3. Run supabase CLI with PGSSLMODE=require PGSSLROOTCERT=~/.postgres/root.crt.
4. Run supabase db pull

A workaround would be useful. Perhaps I can override the URL manually?

$ supabase db pull  --linked                          [11:33:29]
Using workdir /Users/danechlin/dev/
Initialising cli_login_postgres role...
Connecting to remote database...
failed to connect to postgres: failed to connect to `host=127.0.0.1 user=postgres database=postgres`: tls error (server refused TLS connection)
Try rerunning the c

My guess is local doesn't support SSL while remote requirements. I'm not actually using a local DB, I'm just doing local development and migrations, so I'm going to see if I can just wipe / reset.

[sweatybridge]

The only problematic step is when pulling schema from the remote. You can workaround using and old version of cli

npx supabase@v2.34.0 db pull

Or disable ssl enforcement temporarily.

[markwallaert]

Banging my head against this bug as well, disabling ssl is not an option. This eventually worked for me on Linux without having to go to an old version.

export PGSSLMODE=require

[github-actions]

Hi! Thanks for opening this issue.

We're closing this because it has not had any activity for 45 days, and we try to keep the Supabase CLI issue tracker focused on reports that are still current.

If this still reproduces on the latest Supabase CLI, please comment with /reopen on its own line and include your CLI version, updated reproduction steps, and any recent error output. We appreciate the signal and are happy to take another look.