When I require SSL in my n8n cloud Postgres node with the Settings dropdown to connect to Supabase using Transaction Pooler parameters, connection fails with error “self-signed certificate in certificate chain”.
I’m able to connect while SSL is disabled, and I’m also able to connect if I toggle on Ignore SSL Issues (Insecure). But obviously I want my connection to require SSL and be secure without ignoring issues.
How can I enable SSL without ignoring the self-signed certificate error?
When using SSL, client-side certificate validation requires a trusted root certificate and any necessary intermediate certificates to verify the server’s certificate chain. In the n8n Cloud environment, since there’s currently no mechanism to upload custom root or intermediate certificates (that I know of, but I haven’t looked too hard), the instance cannot validate self-signed certificates from an external services.
Given these constraints, you have three practical options (in order of preference):
For optimal security, I’d recommend going with publicly trusted CA to issue a certificate for your database, if that’s an option.
Continue using SSL while enabling “Ignore SSL Issues” (understanding this reduces security)
Use an unencrypted connection (though this isn’t recommended for production environments)
Hey tx for your help. I’m not sure if option 1 is possible on n8n cloud with Supabase. I don’t think anyone should agree to options 2 or 3 because it makes man in the middle attacks too easy.
Supabase gives you the option of downloading its certificate to add to the certificate authority list used by Postgres. I don’t see a way of uploading a new certificate.
This makes me think there is no secure way to connect n8n cloud to Supabase through the Postgres node.
Ok, I just read a bit about Supabase and it’s architecture.
If I understood the docs correctly, Supabase is a BaaS fronting Postgres DB. Both Supabase as well as Postgres DB can be managed or self-hosted. What is your setup? I know you are using the cloud n8n, what about other parts of this equation? Both managed or both self-hosted or Supabase is managed and Postgres is self-hosted?..
I think, the SSL certificate which you can download from Supabase dashboard is the one you would need to configure Postgres connection with in n8n. Since the certificate is going to be a root certificate which was used to sign the server certificate a managed postgres instance was configured with. It will allow n8n to be able to verify a full certificate chain for the certificate returned by postgres instance.
For the supabase - for the managed version, it should already be behind an existing SSL certificate, otherwise, if supabase is self-hosted - you would obtain your own trusted certificate and either configure a reverse proxy with this certificate or configure Supabase Gateway (Kong) with it.
I assume you are using:
a cloud version of n8n
managed (online) version of supabase
This means:
if the postgres is also managed:
you download the certificate from the supabase dashboard and use it in the connection in postgres node
if the postgres is self-hosted:
you obtain your own certificate for it from a trusted CA, which n8n will respect
Good point, I assumed (and I know I shouldn’t have) the credentials portion of Postgres node configuration have a field for specifying the CA certificate (just like MySQL node does for instance, which is why I made an assumption), but just checked and it appears it doesn’t.
This definitely means that securing your connection to Supabase with SSL won’t be possible with default Postgres node. Also reading up on configuring Supabase makes me believe that providing your own publicly trustable server certificate to use for managed Postgres in Supabase is also not possible. Good god, limitation after limitation.
There was a community node that claims to have implemented Postgres SSL, but it appears it wan’t updated for a couple of years and only includes verify, and not verify-full option (which may or may not be your requirement), and given your n8n is cloud based, that wouldn’t help much anyway even if it was fresh off the grill.
Final options we are left with:
not use SSL and accept the fate of the SSL-less life
not use managed Postgres and point Supabase to either self-hosted or managed instance which allows to “bring your own cert”
use Supabase api calls instead of direct Postgres calls (which is probably limited in what it can do)
Yeah verify-full would be ideal. Seems like full encryption w/ the Postgres node on n8n cloud is not possible.
I found a workaround similar to your third option: Supabase database functions. These are stored procedures fronted by an API (different than the Data API, which is a wrapper for PostgREST and is quite limited). In n8n I use an HTTP node to hit my function’s API endpoint with an HTTPS POST request. Fully encrypted.
.