Hi, I am new for n8n. I got a “failed to connect to servername:1433 - self signed certificate” error when setting the MS SQL Server connection account.
Does anyone has any ideas?
- Running n8n via npm
I am using the npm (Windows platform). Where is the env file to set this parameter?
Hey @anderson.wong,
You would need to set it before running the start command although the export option would possibly work on Windows as well.
You might want to check out Microsoft’s docs for PowerShell on environment variables: about Environment Variables - PowerShell | Microsoft Learn
The tl;dr would be $Env:VARIABLE_NAME = 'Variable Value'
1 Like
I tried the following:
SET NODE_TLS_REJECT_UNAUTHORIZED=0
n8n start
but still cannot connect to SQL Server, same error:
In this case support for self-signed/untrusted certificate might be a new feature that we’ll need to implement I am afraid. I’ll convert this question into a feature request for now so you and other users interested in this can vote on it @anderson.wong
1 Like
This error is preventing me from connecting to a SQL Server database on AWS’ RDS service. It may also cause this for other types of databases in RDS (Postgres and MySQL). @MutedJam not sure if that would make this more interesting to you all.
FWIW @MutedJam / @anderson.wong - I tried connecting to my SQL Server database that is on AWS RDS from the cloud as well as the desktop versions and received this error in both cases. AWS probably has a real cert or at least a fully published keychain, so this is bigger than just self-signed.
I’ve had to cancel our company trial as this is not usable if we can not connect to AWS RDS database instances. It might work under docker, but I don’t feel like trying right now.
Hi @tpak,
Oddly enough I submitted the PR below last month which adds support for self signed certificates when connecting to MSSQL.
Once reviewed it will be merged and will be in a future release, it is too late for this weeks release but we should be able to get it into next weeks release.
Thanks @Jon
I wonder if that will solve the issue connecting to AWS RDS databases. I am skeptical that their certs are self signed and blindly accepting cert errors seems risky does it not?
Actually, for RDS it does look like they self sign RDS ca’s.
For n8n cloud, I’d like to see n8n pull in their CA bundles, much safer than ignoring errors around self signed certs for connecting to the worlds largest cloud provider
Hey @tpak,
That is not a bad idea, we would need to include the same cert bundle into self hosted installs of n8n as well. I will take another look at the library to see if we can maybe have an option to specify the CA cert to use as well.
1 Like
@Jon, definitely including the bundles in all builds would be a good idea, I could not get connected to my RDS instance from the desktop or cloud, gave up and assumed docker or local install would have the same issue. Looking at GCP it looks like they may also self-sign certs but I can not see that they provide CA bundles as AWS does, although they allow you to download one for configuration. Azure also seems to do some interesting things with certs allowing rotation, etc.
Maybe the thing to do is also provide a way to import a ca/cert in addition to bundling known ca bundles as they come up from the big players? This combined with your solution (ignore errors) would allow people to securely and safely connect.
Some security departments will likely deny a solution that ignores/overrides cert errors.
If you were self hosting you should be able to add the certs to the host and it would solve the issue, Using docker would take a bit more work and involve a custom image to import them to. I have thought more about including the bundles and while it seems like it could be a good idea it is then another maintenance task to keep track of and if Amazon or one of the others revoked a cert we would then need to put out a new build.
Life would be easier if they used valid certs or had their certs added to common cacert stores.
However, n8n cloud should work with the big players, should it not? True, certs expire, but that is a given.
Also, if this is going to be pushed to the user to solve then I think how needs to be clearly documented with examples.
The docker challenge is probably not that hard and would not require a specific new builkd, just pull in the AWS cert bundle (and others) each time, it would probably only add a few seconds to the build?
Cloud and self hosted is the same image for each instance so it would be a case of including them for everyone but the question is still there of where do we stop with adding the certificates? The issue itself isn’t around just the expiration but also cert revoking.
I am just in the middle of creating a product idea so that we can think about the best way to approach this for the future as it does make sense to include a couple of them but we will need to work out the best way to handle that.
If you were to include the certs in our docker image you would need to make your own build which was why I mentioned that, If you were to use npm to install and run n8n it should take the certs you already trust.
I did read earlier today though that NodeJS already includes the certs needed for AWS services which I found interesting so there is still a bit more digging I need to do.
Just to add I have created n8n-6209 as an internal ticket to look into the CA side further.
@Jon, any update on getting your PR merged? (feat(Microsoft SQL Node): Add support for self signed certs by Joffcom · Pull Request #5160 · n8n-io/n8n · GitHub)
Even though I’d also like to see the bundles included in the base build, at least your update will be a workaround for those that are not as security sensitive or can live with it while the ca-bundle gets worked out. At the moment, AWS RDS resources are unreachable from the desktop and your hosted cloud. I’d think getting them reachable via your cloud would be an incentive 