SSL certificate error в n8n: HTTPS, reverse proxy, self-signed CA и webhooks

Обновлено: 2026-05-29

SSL certificate error в n8n может означать несколько разных проблем. Иногда браузер не доверяет сертификату самого n8n. Иногда внешний сервис не может отправить webhook на ваш домен. Иногда HTTP Request node не доверяет сертификату внутреннего API. Лечить все эти случаи одной галочкой “ignore SSL” опасно: можно скрыть настоящую проблему с TLS.

Начинайте диагностику с вопроса: кто кому не доверяет? Браузер → n8n, Telegram/Tilda/ЮKassa → n8n, n8n → внешний API, n8n → внутренний self-signed сервис. От ответа зависит исправление.

Четыре типовых сценария

Где ошибка	Пример	Что проверять
браузер открывает n8n	NET::ERR_CERT_AUTHORITY_INVALID	домен, сертификат, chain, reverse proxy
внешний webhook не доходит	Telegram или ЮKassa не принимает URL	публичный HTTPS, валидный сертификат, 443 порт
OAuth callback ломается	Google/CRM возвращает redirect error	`WEBHOOK_URL`, callback URL, HTTPS
HTTP Request падает	self-signed certificate in chain	CA bundle, внутренний сертификат, настройки API

Проверка публичного сертификата

Сначала проверьте домен снаружи, а не из контейнера:

curl -Iv https://n8n.example.ru
openssl s_client -connect n8n.example.ru:443 -servername n8n.example.ru

Смотрите на срок действия, issuer, совпадение домена и наличие full chain. Если сертификат выпущен на другой домен или цепочка неполная, некоторые сервисы откажутся отправлять webhooks, даже если браузер “как-то открыл” сайт.

Reverse proxy: где должен жить TLS

В большинстве self-hosted установок TLS завершает reverse proxy: Caddy, Nginx, Traefik или Cloudflare Tunnel. n8n при этом работает внутри Docker-сети по HTTP, а наружу отдаётся HTTPS.

environment:
  - N8N_HOST=n8n.example.ru
  - N8N_PROTOCOL=https
  - WEBHOOK_URL=https://n8n.example.ru/
  - N8N_PROXY_HOPS=1

Если WEBHOOK_URL указывает на localhost, внутренний docker-host или HTTP-адрес, production webhooks и OAuth callback будут ломаться даже при рабочем сертификате.

Caddy, Nginx и Traefik: что проверить

Proxy	Что обычно ломается	Практическая проверка
Caddy	DNS не указывает на сервер, не выпущен сертификат	`docker compose logs caddy`
Nginx	неполный chain, забытый websocket/proxy headers	`nginx -t`, `curl -Iv`
Traefik	неверные labels/router/service	dashboard, access logs, labels контейнера
Cloudflare	режим Flexible вместо Full strict	проверить SSL/TLS mode и origin cert

Self-signed CA для внутренних API

Если n8n ходит в корпоративный API с self-signed сертификатом, не спешите отключать проверку TLS в HTTP Request. Лучше добавить собственный CA в n8n. Это безопаснее, чем принимать любой недоверенный сертификат.

Подход: получить CA certificate, смонтировать его в контейнер и указать n8n/Node.js, что этому CA можно доверять. После этого HTTP Request сможет проверять цепочку, а не работать вслепую.

services:
  n8n:
    volumes:
      - ./certs/company-ca.pem:/opt/certs/company-ca.pem:ro
    environment:
      - NODE_EXTRA_CA_CERTS=/opt/certs/company-ca.pem

Webhook-сервисы особенно требовательны

Telegram, Tilda, amoCRM, ЮKassa, платежные и CRM-сервисы обычно требуют публичный HTTPS с доверенным сертификатом. Для локальной разработки можно использовать tunnel, но рабочий URL должен быть стабильным: домен, сертификат, 443 порт, понятный path.

После смены сертификата или домена проверьте не только браузер, но и повторную регистрацию webhook у сервиса. Некоторые интеграции продолжают отправлять события на старый URL.

Что делать нельзя

глобально отключать проверку TLS для всех запросов;
использовать self-signed certificate для публичных payment/CRM webhooks;
оставлять WEBHOOK_URL=http://localhost... на рабочем сервере;
публиковать n8n без HTTPS и надеяться, что OAuth будет стабилен;
копировать сертификат без private key rotation и понимания срока действия.

Пошаговая диагностика

Откройте n8n с внешнего интернета по домену.
Проверьте certificate chain через openssl s_client.
Проверьте WEBHOOK_URL в env.
Отправьте тестовый POST на production webhook.
Проверьте логи reverse proxy и n8n.
Если падает HTTP Request к внутреннему API, добавьте custom CA вместо отключения TLS.

Ручная диагностика перед исправлением ¶

Перед тем как менять настройки по теме «SSL certificate error в n8n», зафиксируйте не только текст ошибки, но и последний успешный запуск. Для n8n это критично: один и тот же симптом может появиться из-за credentials, изменения payload, лимита API, обновления версии или инфраструктурного сбоя.

Рабочий порядок: изолируйте один execution, сохраните входной item без секретов, проверьте branch с ошибкой и только потом меняйте workflow. Главный риск — исправить симптом на одной ноде, но оставить первопричину в credentials, payload, лимитах API или окружении.

Слой	Что зафиксировать	Зачем
Вход	payload webhook/API с подписью, timestamp, event_id и исходным HTTP-статусом	позволяет повторить проблему без доступа к production-секретам
Контроль	error_count_by_node, retry_count, first_failed_execution, last_successful_execution, affected_workflows	показывает деградацию раньше, чем пользователи начинают писать в поддержку
Безопасность	исправить симптом на одной ноде, но оставить первопричину в credentials, payload, лимитах API или окружении	снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
Готовность	есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «SSL certificate error в n8n»	делает статью пригодной для runbook, а не только для чтения

Пример безопасного входного контракта ¶

{
  "execution_id": "exec_...",
  "workflow_id": "wf_...",
  "node_name": "node_with_symptom",
  "error_message": "точный текст ошибки без токенов",
  "input_item_id": "external_or_dedupe_id",
  "last_successful_run": "timestamp",
  "changed_before_error": ["credentials", "payload", "version", "env"]
}

Критерий готовности ¶

точный текст ошибки сохранён без токенов и персональных данных
понятно, какая нода упала первой, а какие ошибки были следствием
есть минимальный воспроизводимый workflow или тестовый execution
после исправления проверены retry, error branch и последний успешный сценарий