All external APIs failing with SSL errors – Self-hosted (Hetzner)

Questions
1

Hi all,
After switching from n8n Cloud (free trial) to a self-hosted setup on Hetzner, every external API call in n8n fails due to TLS/SSL certificate hostname mismatches. I’m starting to feel quite stuck, so I’m hoping someone here can help.

Describe the problem/error/question

  • I’m trying to connect various APIs using credentials in n8n: Google OAuth2, OpenRouter, SerpAPI, etc.
  • In the cloud version of n8n this all worked perfectly.
  • Now that I self-host, all API connections fail, even with simple OAuth setups or HTTP nodes.

What is the error message (if any)?

Error: Hostname/IP does not match certificate’s altnames:
Host: oauth2.googleapis.com is not in the cert’s altnames:
DNS: app.trajectx.com, www.app.trajectx.com

or:

Host: openrouter.ai is not in the cert’s altnames: DNS: app.trajectx.com

or:

Hostname/IP does not match certificate’s altnames:
Host: enterprise.n8n.io is not in the cert’s altnames:

Information on your n8n setup

  • n8n version: 1.102.0
  • Database (default: SQLite): SQLite
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app): Docker on Hetzner VPS
  • Operating system: Windows

What we’ve already tried

  • Updated CA certificates inside the container

  • Searched for similar issues:

    On this n8n community forum
    On Reddit (found similar symptoms)
    On YouTube
    Via the n8n Assistant by Nskha, which confirmed that the certificate chain and hostname mismatch could indicate a misconfigured proxy or outdated CA store

Context

I’m not a sysadmin — my colleague set up the Docker deployment for me.
He also doesn’t see any obvious misconfigurations, and the issue is baffling.

From what I understand, n8n is trying to validate the hostname of third-party services using our own SSL certificate, which obviously doesn’t match.

Thanks in advance for any support!

2

Hey @Tom_De_Cock hope all is well. Welcome to the community.

Do you have any kind of proxy in your network?

3

Hey Jabbson, thanks a lot for helping us out!
No, we don’t have any proxy in our network. My colleague confirmed earlier that the Docker container has full internet access. He was able to ping external servers from within the container without issues.

4

Well, it certainly does look like the traffic you are sending out is either being intercepted, or proxied. When you get the errors similar to what you see, it means that the client (axion, running behind your HTTP Request Node) is sending the request to establish a secure connection to … say http://oauth2.googleapis.com/… and when it gets the response back, it is receiving a TLS certificate not issued for that domain. There could be a number of misconfiguration that could lead to this behaviour too, for instance - a poorly configured reverse proxy, improperly configured regular proxy, DNS rewrites and overrides… Hard to say which one it is in your case, but it is some sort of misconfig. What is that app.trajectx.com domain the errors are mentioning. Do you recognize it?

5

To fix it, check if a reverse proxy like Nginx or Traefik is set as the default gateway or intercepting outbound traffic—ensure it’s only handling inbound requests and not acting as a MITM (man-in-the-middle) for outbound HTTPS calls. Disabling outbound SSL interception or bypassing the proxy for external domains should resolve the issue.

6

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