Eproto error (alert number 112) on Http request node

Questions
1

Describe the problem/error/question

I am trying to connect n8n (self-hosted, Docker on Hostinger) to the Pennylane API using the HTTP Request node with a Bearer API token.

I have already successfully connected n8n to other external APIs (Baserow, Simplybook, Google, etc.), so outbound HTTP requests in general work fine.

However, when trying to call Pennylane API endpoints, I encounter DNS and SSL/TLS errors and cannot establish a connection.

I want to understand whether this is:

  • a TLS / OpenSSL issue in the n8n Docker image,

  • a DNS / networking limitation,

  • or a known incompatibility with Pennylane API.

What is the error message (if any)?

SSL / TLS error (when using https://api.pennylane.app):

EPROTO
write EPROTO error:0A000458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name
SSL alert number 112

Full error excerpt:

write EPROTO 4072F10FE0710000:error:0A000458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name

Please share your workflow

Share the output returned by the last node

NodeApiError: write EPROTO … ssl3_read_bytes:tlsv1 unrecognized name

Information on your n8n setup

    1. n8n version: 1.121.3
    2. Database: SQLite (default)
    3. n8n EXECUTIONS_PROCESS: own
    4. Running n8n via: Docker (self-hosted)
    5. Hosting provider: Hostinger
    6. Operating system: Linux (Hostinger VPS)

Additional context

  • Other HTTP Request nodes to external APIs work correctly.

  • api.pennylane.app resolves, but fails during TLS handshake in n8n.

  • Disabling SSL verification (Ignore SSL Issues) allows the request to go through, which suggests a TLS/OpenSSL compatibility issue.

2

Welcome to the n8n community @Chooks!
As i cannot mention a specific thing which might be wrong cause there can be multiple things which are happening in this so below are some steps i recommend you to try:

The issue appears related to TLS handshake problems between Node inside your n8n container and Pennylane’s API, not a known incompatibility. Here are practical steps to troubleshoot and fix:

  1. Inside the container, run curl https://api.pennylane.app to verify if TLS works at the OS level. If it succeeds, the network and DNS are fine, and the problem is with Node/OpenSSL.

  2. Force TLS 1.2 in your container by adding the environment variable NODE_OPTIONS=--dns-result-order=ipv4first --tls-max-v1.2 in your Docker setup. Restart n8n after making this change. This often resolves handshake issues caused by TLS version mismatches.

  3. If you’re using a reverse proxy, ensure N8N_PROTOCOL is set to http since TLS is terminated there, and avoid passing SSL cert environment variables to n8n unless necessary.

  4. Set the Host header explicitly to api.pennylane.app in your HTTP Request node. This can help with SNI and hostname verification issues behind proxies or virtual hosts.

  5. Avoid ignoring SSL validation in production. If Pennylane uses a custom or self-signed certificate, mount the CA certificate into the container and configure n8n to trust it.

These steps align with common SSL/TLS fixes for similar issues. If after trying them the problem persists, share your docker-compose setup for further review.

Let me know if this helps