To access an API we need to provide an SSL certificate. This certificate is signed by the CA of the developer. We followed Configure n8n to use your own certificate authority | n8n Docs But we still get the following error. Is there anyone with some tips or tricks to make this work without ignoring SSL issues (then the flow works)
You mean the cert is self signed? The steps outlined in those instructions should work. Have you confirmed the cert exists in the docker volume after the copy command?
Yes, we have an added the SSL certificate to the HTTP request. And the authorization works on the suppliers end, we retrieve the data, but it only works when we turn on ‘ignore SSL issues’. When we use the flow with the option turned off, n8n is unable to het the local issuer certificate.
We added the CA chain to the docker and we are using the documentation you send for the HTTP request for SSL certificates, we are pretty sure we have followed the right instructions. Is there anything else we can try?
In the folder where you have added your cert did n8n generate some extra files? I am just wondering if maybe the files are owned by a different user and need the permissions to be changed.
The Trusting custom certificates from /opt/custom-certificates in the logs
We are not seeing the error in the console
Is it an idea that n8n expands the docs with more detailed information how to setup the CA Chain and SSL certificates in n8n? I think we need this to make any use of this feature.
Still trying to read between the lines on what has already been discussed, so apologies if I’m missing something you already tried.
I think @gaulter already said this, but maybe not clearly enough if there is still confusion between client and server certificates. I’m not 100% sure of this, but n8n might not use the CA (certificate authority) certificates from /opt/custom-certificatesat all with the SSL Certificates credential type.
In the SSL certificate credential itself, the fields are:
CA - (presumably) the public certificate for the issuer of the client certificate - required as a reference for the “signer(s)” in the client-certificate’s certificate-chain.
This is probably not the same as the root CA certificate/certificate-chain that might need to be trusted for a self-signed server certificate
Certificate - The “private” client-certificate issued to you for the purpose of authenticating your client
Private Key - used in the process of signing the client-certificate
may have also been provided by the issuer of the client-certificate
Passphrase - needed if the client-certificate and/or private-key data is encrypted/protected that way
Note that if the server to which you are connecting is ALSO set up with a self-signed server certificate, it may be possible that you are contending with two separate issues, and will also need to configure n8n to trust the server’s TLS certificate in /opt/custom-certificates
Yes, we are using the SSL certificate to get access to an API endpoint. So we are trying to add a client certificate. Thanks for clarifying that piece.
When adding the SSL certificate credential fields I’ve made use of the docs. These are a bit limited so maybe I am filling the CA field with the wrong value.
I am pretty confident that the rest of the fields are filled correctly.
Well I think we have fixed it, but im not sure it is correct to do it this way. In the SSL certificate credential fields I’ve let the CA empty. The flow now runs well without the option Ignore SSL issues enabled.
Because the documentation says if it is required then fill it, and in n8n it is not required. And your @hubschrauber comment made me think about this field. So i though i would try.
If the authentication process works, there shouldn’t be a security issue by leaving out the client-certificate’s CA chain. The only certificates that are usually required, with a client-certificate authentication, are intermediate CAs/signers that are the chain “links” back to a trusted CA/signer/certificate. Chances are, the client-certificate you have is directly linked to a trusted client-certificate-CA on the service-end (i.e. there are no intermediate CAs), so you only need to send the client-certificate itself.
