I’m using self-hosted n8n and trying to connect to AWS RDS Postgreql database. As described in AWS documentation, custom CA certificates need to be downloaded and loaded in order to establish a secure connection with the database.
I’ve also tried copying the custom certificates into the /opt/custom-certificates directory according to n8n documentation but this has not helped with the certificate errors I am facing.
Note #1: When enabling Ignore SSL Issues (Insecure) my connection is successful, but I would like to avoid using this insecure setting.
Note #2: Adding chown -R 1000:1000 /opt/custom-certificates also did not improve the situation:
Notably, there are no symlinks as mentioned by the other post. I also do not see any messages during startup related to certificates (neither “Trusting custom certificates from /opt/custom-certificates” nor " WARNING: mycertchain.pem does not contain exactly one certificate or crl: skipping").
I’ve found the issue by checking the n8n source code, we are setting an entrypoint script in our Dockerfile, which we did not realize is overriding the default n8n entrypoint script which loads the custom certificates.
My temporary workaround is to copy/paste the logic in the default script to the bottom of my own custom entrypoint script, but I will continue to investigate a better long-term solution. (Note: we are using the custom script for a scrappy CI/CD style deployment of workflows from source-code by importing them from JSON files, likely there’s a better way to do this)
FWIW, we had to do the same in kubernetes because the certificates directory is mounted to a config-map volume, which cannot be modified at runtime, so the symlink files must be created ahead of time (as actual copies of the certificates), manually, using the c_rehash command to generate the filenames, and the call to c_rehash in the startup script must be removed.
Also, since you’ve already overriddendocker-entrypoint.sh, it won’t affect you, but for others who end up reading this thread, there was (is) a bug in the script affecting installs where both NODE_OPTIONS and certificates are used. The bug was fixed very recently - March 10, 2025 (released with n8n version 1.83.0).