How can I resolve certificate errors when connecting n8n on RepoCloud to Supabase Postgres via SSL?

It looks like the error:

self-signed certificate in certificate chain

is occurring because Supabase’s Postgres instance is using a certificate chain that isn’t recognized by the underlying system, and with SSL set to "allow" or "require" n8n (via its Postgres credential) is trying to validate that chain.

What's Going On

When you disable SSL, no certificate validation is performed so the connection succeeds. When you set SSL to allow/require, n8n (and Postgres’s client library) validates the server certificate. If the Supabase certificate isn’t in your trusted store (or you haven’t provided the Supabase CA certificate), the connection is rejected.

Limitations in Your Environment

Since you are running n8n on RepoCloud, you likely don’t have direct command line access to:

• Add the Supabase CA certificate to the trusted CA store, or
• Mount custom certificates (for example via environment variables like DB_POSTGRESDB_SSL_CA).

The n8n documentation shows that when using Postgres with TLS, you can pass in a path to a CA certificate via an environment variable. This is usually straightforward if you can manage the underlying host (e.g. on a VPS or Digital Ocean droplet), but in a managed environment like RepoCloud you might not have that level of control.

What Options Do You Have?

1. Use Insecure SSL (Not Recommended for Production):
   You could set the “Ignore SSL Issues” flag (or, if using environment variables, set the equivalent to disable certificate validation). For the Postgres credential in n8n this would correspond to setting something like:

   SQLCopied
   SSL mode: Require (or Allow)
   Ignore SSL Issues: On

   This bypasses the certificate check but does reduce connection security.

2. Ask RepoCloud Support:
   It may be worth reaching out to RepoCloud to see if they offer a way to add custom CA certificates or otherwise override the default trusted certificates. This change would allow you to supply the Supabase CA certificate as they do in other hosting scenarios.

3. Consider a Reverse Proxy:
   While not directly applicable to Postgres credentials, if you have any control over the network stack you might create a proxy that performs SSL termination using the trusted certificate. Then have n8n connect over plain TCP. However, this is usually more complex and might not be supported in your current environment.

Conclusion

This isn’t necessarily a bug with n8n or even Supabase but a limitation of running n8n in an environment like RepoCloud where you cannot easily modify the trusted certificate authorities. Using SSL properly (with certificate validation) requires that the system trust the Supabase certificate chain—which in your case would involve making changes to the underlying host configuration that you don’t currently have access to.

You might consider temporarily bypassing SSL validation (if acceptable for your use case) or contact RepoCloud for options to supply custom certificates.