Error: Provider routines::bad decrypt when starting n8n with HTTPS in Docker. How do I fix this?

Questions
1

Hi everyone,

I’m trying to set up n8n on my Raspberry Pi using Docker with HTTPS enabled via a self-signed certificate. However, I keep encountering the following error in the logs:

Error: error:1C800064:Provider routines::bad decrypt

Here’s what I’ve done so far:

  1. Initially, I tried installing n8n using NPM, but I couldn’t get HTTPS working with my self-signed certificate. After running into several issues, I decided to uninstall the NPM version and switch to Docker.
  2. I’m fairly sure I removed all traces of the old NPM installation, including the ~/.n8n directory and any globally installed packages.
  3. Generated a self-signed certificate (selfsigned.crt) and private key (selfsigned.key) using OpenSSL.
  4. Placed the certificate and key in /home/lanie/n8n/pki on my Raspberry Pi.
  5. Mapped this directory to /opt/custom-certificates in the Docker container using the volumes section of my docker-compose.yml.
  6. Set the environment variables N8N_PROTOCOL, N8N_SSL_CERT, and N8N_SSL_KEY to enable HTTPS and point to the certificate and key files.
  7. Verified permissions and ownership for the certificate and key:
    chmod 644 /home/lanie/n8n/pki/selfsigned.crt
chmod 600 /home/lanie/n8n/pki/selfsigned.key
chown 1000:1000 /home/lanie/n8n/pki/selfsigned.crt
chown 1000:1000 /home/lanie/n8n/pki/selfsigned.key

Despite this, I still get the “bad decrypt” error when starting n8n.

Logs:

Here are the relevant logs from docker-compose logs n8n:

2024-12-30T05:30:24.762824099Z Error: error:1C800064:Provider routines::bad decrypt
    at setKey (node:internal/tls/secure-context:93:11)
    at configSecureContext (node:internal/tls/secure-context:209:7)
    at Object.createSecureContext (node:_tls_common:114:3)
    at Server.setSecureContext (node:_tls_wrap:1488:27)
    at Server (node:_tls_wrap:1352:8)
    at new Server (node:https:80:3)
    at Object.createServer (node:https:135:10)
    at Server.init (/usr/local/lib/node_modules/n8n/dist/abstract-server.js:135:33)
    at Start.init (/usr/local/lib/node_modules/n8n/dist/commands/base-command.js:86:9)
    at Start.init (/usr/local/lib/node_modules/n8n/dist/commands/start.js:160:9)
Exiting due to an error.

Docker Compose File:

Here’s my docker-compose.yml file:

version: '3'

services:
  n8n:
    container_name: n8n
    image: docker.n8n.io/n8nio/n8n
    ports:
      - 5678:5678
    volumes:
      - /home/lanie/n8n/pki:/opt/custom-certificates
    environment:
      - N8N_PROTOCOL=https
      - N8N_SSL_CERT=/opt/custom-certificates/selfsigned.crt
      - N8N_SSL_KEY=/opt/custom-certificates/selfsigned.key
      - N8N_ENCRYPTION_KEY=9ZXBIEqLCXuFJmrFX9d9dEPX91sd9JdnqyhfuxsDXCk=
      - N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true

System Info:

-N8N Version: 1.7.2.1

  • Database: SQLite
  • Executions process: default
  • Running Method: Docker-compose
  • System version: Debian GNU/Linux 12 (bookworm)

Additional Notes:

  • The certificate and key are in PEM format (.crt and .key), and I verified that they match using openssl x509 -noout -modulus and openssl rsa -noout -modulus.
  • I’ve also tried regenerating the certificate and key, but the issue persists.
  • The container starts fine if I disable HTTPS by changing N8N_PROTOCOL to http, but then I can’t access it from my Windows computer.

Does anyone know what might be causing this issue? Could there be residual effects from my previous NPM installation? Any help would be greatly appreciated!

2

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
3

(Maybe) Correcting the n8n https server config

Not sure this is the underlying cause of the error, but, the first thing I see is that you are mixing up the inbound and outbound certificate setup. Use a different path than /opt/custom-certificates for your server certificates. n8n automatically pulls in everything it finds in /opt/custom-certificates as trusted CA certificates for other servers to which it is connecting outbound (e.g. from an HTTP Request node).
For reference, see Configure n8n to use your own certificate authority or self-signed certificate. Where it says (currently) “This means you are able to trust a certain SSL certificate,” that is referring to connections from n8n to other servers (outbound). It isn’t related to the SSL configuration for n8n AS an https host (inbound).

Your server certificates for the N8N_SSL_* environment vars can be in any path, so maybe create another volume mapped to /home/node/n8n_server_certs and put your server certificate and key there instead.

  volumes:
    - /home/lanie/n8n/trusted_ca_certs:/opt/custom-certificates
    - /home/lanie/n8n/server_http_certs:/home/node/n8n_server_certs
  environment:
    - N8N_SSL_CERT=/home/node/n8n_server_certs/selfsigned.crt
    - N8N_SSL_KEY=/home/node/n8n_server_certs/selfsigned.key

See: Set up SSL - There isn’t much hand-holding here. This generally assumes you already know what you are doing with SSL server setups.

So… this may not be the cause of your bad encrypt error, but it couldn’t hurt to get the n8n config a little closer to correct either way.

Using a Separate Reverse Proxy Instead

If you continue to have issues getting the https host/server setup within n8n to work (I also had some frustrations with this, especially with self-signed certificates), then you might consider terminating the inbound SSL/https connections before they get to n8n, with a reverse proxy.

To give you some ideas about how to do this using Traefik, take a look at this: Self Hosting n8n with Docker and Traefik/LetsEncrypt (for https) In addition to insulating your ssl issues from n8n issues, this uses LetsEncrypt to relieve you from messing with self-signed certificate issues. The server certificates generated/provided from LetsEncrypt are already trusted in browsers, web clients, etc.

4

I had so much trouble with both self-signed certificates and the Nginx reverse proxy that I decided to just use HTTP and disable the secure cookie. I’m running this on my home network on a Raspberry Pi with a firewall and PiHole as DNS, so I think I’m pretty well protected.

5

That works until you get to a point where something (like Google API oauth2) requires that n8n has https enabled somehow. If you don’t need that right away, it sounds like you are good with non-ssl https. When/if you get to a point where you need this, review the section of the previously mentioned writeup on dev.to titled “The Use Case that Made this Necessary”. Good luck.

6

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.