Telegram Trigger: 'The resource you are requesting could not be found' error

Questions
1

Hi everyone,

Searched everywhere for this error, but wasn’t able to find anything.

I am running n8n on a dedicated server without docker with SSL Certificates provided by Sectigo. If I create a Telegram trigger, fill in my credentials (i.e. bot token I got from Telegram’s BotFather) and update type (any) then press ‘Execute’, I am getting the following error:

There was a problem running the workflow:
The resource you are requesting could not be found
Telegram Trigger: Not Found

The WebHook URLs are HTTPS and responsive.

Any ideas on how to debug what’s going on?

2

update:

If I revoke and then create a bot token, the trigger is executed, but no data is passing through, i.e. I message my bot, but the trigger doesn’t catch anything.

3

Welcome to the community @Dima_Neiaglov

If you add a webhook node, execute the workflow, and hit it with an HTTP client, does it work?

4

@RicardoE105, many thanks for the welcome and for the response! I am, indeed, happy to become a part of this community and hope to contribute something to n8n is due time :slight_smile:

Yes, if I add a webhook node and execute the workflow, I can shoot a JSON at it with no trouble at all. So, my current situation is,

  1. I have a workflow with two nodes: webhook and telegram trigger
  2. If I execute the webhook workflow, it receives whatever data I send
  3. If I execute the Telegram trigger, it is being executed, but doesn’t show any messages I send to the respective bot.
5

It seems that the route of my problem is SSL, again. The way my SSL is set up, I have a root certificate, an intermediate certificate and my domain certificate (all come from Sectigo) in a single file that is reffered to by N8N_SSL_CERT. It seems, however, that only domain certificate is being sent: SSL Server Test: auto.extra-axis.com (Powered by Qualys SSL Labs)

I wonder how should I treat root / intermediate certificates in this installation without Docker?

6

(I also see something like this here Telegram trigger doesn't work - #8 by mkz, but the person was running nginx in front of n8n and so was able to resolve on the nginx level)

7

Sorry for the late response. Somehow I missed the message. Sadly do not have experience with another server set up other than the one officially supported.

If you find the solution would be awesome if you share it here with the community.

8

So now that I knew that there is official solution, I came up with the following unofficial solution :slight_smile:

For everyone who might be reading this: it only makes sense if you’re running n8n WITHOUT docker, i.e. installed it on a dedicated server.

The problem is, Telegram is very strict when it comes to security, so even if one has an SSL certificate installed, Telegram requires the whole certificate chain to be valid. This results in a situation when some services (and browsers) work with n8n no problem (trust it enough), while Telegram doesn’t.

n8n (without traefic outside of docker) can’t serve the whole certificate chain so we’d need something that can. I decided to use Caddy. It will serve certificates automatically with no need to even bother with certificate files. I believe it’s so good, it should be the default way.

The overall idea is for n8n to work in http mode on a port 9000 while Caddy will listen to port 443, pretend it’s https, forward all requests to n8n etc.

  1. Download and install Caddy as described here: Install — Caddy Documentation

  2. Ensure that n8n is configured as http and on some higher port. It is very important for WEBHOOK_TUNNEL_URL to be set. Here’s a quick minimal set up that I store in /etc/environments on my server:

    N8N_BASIC_AUTH_ACTIVE=true
    N8N_BASIC_AUTH_USER=your_user_name
    N8N_BASIC_AUTH_PASSWORD=your_pass
    N8N_HOST=example.com
    N8N_PORT=9000
    N8N_LISTEN_ADDRESS=your_ip_address
    WEBHOOK_TUNNEL_URL=“https://example.com/”

It’s very important to add https:// to the example.com in the last line and not omit the final slash (/).

  1. Create a file called Caddyfile anywhere you like and populate it with two strings:

    example.com
    reverse_proxy your_ip_address:9000

Now if you go to the directory with Caddyfile you created and execute ‘sudo caddy run’ everything should work: example.com should be available via https, all webhooks should work and Telegram should work.

Now the only trouble left is to start Caddy automatically. Several steps to do that.

  1. Find out path to your caddy installation via ‘which caddy’. In my case it’s /usr/bin/caddy so I’ll keep using this as example.

  2. Let’s give Caddy rights to use port 443 (https) without the need to be launched as root:
    sudo setcap cap_net_bind_service=+ep /usr/bin/caddy

  3. Now let’s create a service. Say ‘sudo nano /etc/systemd/system/caddy.service’ and paste the following

[Unit]
Description=Caddy webserver
Documentation=https://caddyserver.com/
After=network.target

[Service]
User=your_user_name
WorkingDirectory=/home/your_user_name
LimitNOFILE=4096
PIDFile=/var/run/caddy/caddy.pid
ExecStart=/usr/bin/caddy run -config=“path_to_your_caddy_file”
Restart=on-failure
StartLimitInterval=600

[Install]
WantedBy=multi-user.target

  1. Now let’s active the startup service we just created

sudo systemctl enable caddy
sudo service caddy start

Now Caddy will start on boot. If you’re using pm2 to start n8n, as described here, you can configure it to automatically start n8n by ussuing ‘pm2 startup’, doing what it says, then ‘pm2 start n8n’, then ‘pm2 save’.

4 Likes