Hi everyone,
I’m facing a persistent issue with the “Send Email” (SMTP) node and I’m out of ideas after extensive troubleshooting. I hope someone can shed some light on this.
The Problem:
Every time I try to execute the “Send Email” node, it fails instantly with the following error:
40423284687F0000:error:0A00010B:SSL routines:tls_validate_record_header:wrong version number:../deps/openssl/openssl/ssl/record/methods/tlsany_meth.c:84:
My Setup:
n8n Version: Latest (I just pulled the latest Docker image).
Deployment: Self-hosted using Docker on a Google Cloud VM.
SMTP Provider: Brevo (using smtp-relay.brevo.com).
What’s strange is that all external tests indicate the connection should work.
Troubleshooting Steps I’ve Already Taken:
n8n Credential Test: The credentials in the UI pass the test successfully when configured with Host: smtp-relay.brevo.com, Port: 465, and SSL/TLS enabled.
Server-Level Connection Test: I have SSH’d into the Google Cloud VM where n8n is running and tested the connection directly using OpenSSL. The command openssl s_client -connect smtp-relay.brevo.com:465 connects successfully and establishes a proper TLSv1.3 handshake, receiving the “220 ESMTP Service Ready” message from Brevo. This confirms there are no firewall, network, or DNS issues from the host machine.
Updated n8n: I have stopped, removed, and recreated the n8n Docker container using the n8nio/n8n:latest image to ensure I am on the latest version. The issue persists.
Forced TLS Version: Based on troubleshooting advice, I have added the environment variable NODE_OPTIONS=–tls-min-v1.2 to my Docker container configuration (docker-compose.yml / docker run command). The container is running with this variable, but the error remains exactly the same.
Despite the successful connection test in the UI and the successful OpenSSL connection from the host server, the node execution fails every time. This strongly suggests the issue lies within the n8n execution environment itself.
Does anyone know what could cause the n8n execution environment to fail this TLS handshake when the underlying machine can perform it perfectly? Is this a known bug, or is there another configuration I might be missing?
Thanks in advance for any help
n8n has problems in general with self-signed certificates (esp. Node.js). Normally setting the environment variable to “NODE_TLS_REJECT_UNAUTHORIZED=0” (super unsafe for man-in-the-middle attacks) helps, but not for this issue. I have the same issue and haven’t found a solution yet.