Setting up SSL certificates for local n8n deployment

Other Questions N8n
6

The Problem:

You’re experiencing issues configuring SSL encryption for your local n8n instance. While you’ve correctly set the environment variables N8N_PROTOCOL, N8N_SSL_KEY, and N8N_SSL_CERT, n8n is still running on HTTP, indicated by the http://localhost:5678/ URL in the console. This suggests that n8n isn’t properly loading or utilizing your SSL certificates. The core issue isn’t with your workflow or node configurations, but with the server’s SSL setup.

:thinking: Understanding the “Why” (The Root Cause):

The problem likely lies in how n8n is accessing and interpreting your environment variables, or the validity and accessibility of your SSL certificates. Simply setting environment variables may not always be sufficient, especially if n8n is launched in a specific way (e.g., through a process manager, npm script, or Docker). Furthermore, even if the environment variables are correctly read, issues with certificate paths, permissions, or certificate validity can prevent HTTPS from working. The console message might be cached, showing an outdated status.

:gear: Step-by-Step Guide:

  1. Verify SSL Certificate and Key: Use openssl to confirm the validity of your certificate and key, and that they match. Execute these commands in your terminal:

    openssl x509 -noout -modulus -in /home/user/ssl/certificate.crt | openssl md5
openssl rsa -noout -modulus -in /home/user/ssl/private.key | openssl md5

    The output of the modulus commands should be identical for both files. If they differ, you’re using mismatched key pairs, a common source of SSL errors.

  2. Check File Paths and Permissions: Ensure the paths specified in your environment variables (N8N_SSL_KEY and N8N_SSL_CERT) are absolutely correct. Use absolute paths to avoid ambiguity. Check file permissions using:

    ls -la /home/user/ssl/private.key /home/user/ssl/certificate.crt

    The n8n user needs read access (r) to both files. If permissions are incorrect, adjust them accordingly (e.g., using chmod 644 /home/user/ssl/certificate.crt).

  3. Directly Set Environment Variables During Startup: Instead of relying solely on shell export commands, directly embed environment variables in your n8n startup command:

    N8N_PROTOCOL=https N8N_SSL_KEY=/home/user/ssl/private.key N8N_SSL_CERT=/home/user/ssl/certificate.crt npx n8n

    or (if using a process manager such as systemd): Modify your service file to include those variables within the environment section.
    This forces n8n to use the SSL settings at its launch.

  4. Test the HTTPS Endpoint Directly: Ignore the console output for now. Directly access https://localhost:5678/ in your browser. Your browser will likely indicate whether the SSL certificate is valid. If not, investigate the certificate problems further.

  5. Restart n8n: After making any changes, completely restart the n8n instance. n8n might be caching the older HTTP configuration.

:mag: Common Pitfalls & What to Check Next:

  • Self-Signed Certificates: If using self-signed certificates, ensure they’re correctly configured and your browser trusts them (you’ll likely need to add an exception). They must include the correct Subject Alternative Name (SAN) for localhost.
  • Firewall: Make sure your firewall allows HTTPS traffic on port 5678.
  • Alternative Startup Methods: If you start n8n differently (e.g., via Docker, systemd, etc.), you might need to configure the environment variables within that setup.
  • Proxy Server: if you’re behind a proxy server, this can also interfere with the SSL handshake. Make sure that your proxy settings are configured correctly.

:speech_balloon: Still running into issues? Share your (sanitized) config files, the exact command you ran, and any other relevant details. The community is here to help!