Ошибка 526 Invalid SSL Certificate в Cloudflare: как починить

Ошибка 526 в Cloudflare появляется, когда пользователь открывает сайт через Cloudflare, а Cloudflare не может признать SSL-сертификат на origin-сервере действительным. Браузер до вашего сервера напрямую не доходит: он видит страницу Cloudflare с сообщением Invalid SSL Certificate, а сама проблема находится между Cloudflare и origin.

Чаще всего 526 возникает после истечения сертификата, переезда сайта на другой сервер, неправильной настройки fullchain.pem, выпуска сертификата не на тот домен или включения режима Full (strict) без готового HTTPS на origin. Ошибка похожа на другие сбои Cloudflare из диапазона 520–524, но лечится иначе: не перезапуском приложения и не увеличением таймаутов, а проверкой TLS-сертификата на сервере.

Ниже — практический разбор: что означает ошибка 526, как быстро подтвердить причину, какие настройки проверить в Cloudflare, Nginx, Apache и certbot, и что сделать, чтобы сбой не повторялся.

Что означает ошибка 526 в Cloudflare

526 Invalid SSL Certificate означает: Cloudflare смог подключиться к origin-серверу по HTTPS, но не смог провалидировать сертификат, который origin предъявил во время TLS-соединения.

Схема запроса выглядит так:

Браузер → Cloudflare Edge → Origin-сервер

У Cloudflare есть два TLS-участка:

1) Браузер ↔ Cloudflare — публичный сертификат на edge-узлах Cloudflare. Обычно с ним всё в порядке: Cloudflare сам выпускает и обслуживает сертификаты для домена, если DNS и Universal SSL настроены корректно.

2) Cloudflare ↔ origin-сервер — сертификат, установленный на вашем сервере, балансировщике, ingress-контроллере или хостинге. Именно здесь возникает ошибка 526.

Ключевой момент: ошибка 526 характерна для режима SSL/TLS Full (strict). В этом режиме Cloudflare требует, чтобы сертификат на origin был действительным: не просроченным, выпущенным доверенным центром или Cloudflare Origin CA, подходящим к домену и правильно собранным в цепочку.

Если Cloudflare вообще не может установить TLS-соединение, чаще появляется 525 SSL handshake failed. Если сервер не отвечает, могут быть 521, 522, 523 или 524. Для соседних кодов полезен отдельный разбор: Ошибка 520/521/522/523/524 Cloudflare: что значит и как исправить. В случае 526 фокус уже не на доступности TCP-порта или таймаутах, а на валидности сертификата.

Почему возникает ошибка 526

Cloudflare проверяет origin-сертификат примерно так же, как это сделал бы строгий HTTPS-клиент. Если сертификат не проходит проверку, запрос останавливается на стороне Cloudflare, а посетитель получает страницу 526.

Самые частые причины:

1) Сертификат на origin истёк — классический сценарий: certbot renew не отработал, cron или systemd timer сломался, reload Nginx не был выполнен, контейнер с сертификатом пересобрали без актуальных файлов. Cloudflare видит просроченный сертификат и отклоняет соединение.

2) Сертификат выпущен не на тот домен — в Subject Alternative Name нет нужного имени: например, сертификат есть для example.com, но Cloudflare подключается к www.example.com, api.example.com или wildcard-домену. Проверять нужно именно SAN, Common Name здесь не спасает.

3) На сервере отдаётся дефолтный сертификат — частая проблема с SNI. На одном IP висит несколько сайтов, но Nginx или Apache выбирает не тот server_name или первый виртуальный хост. При прямом заходе на IP в браузере это может быть незаметно, но Cloudflare подключается с конкретным именем и ожидает сертификат под него.

4) Неполная цепочка сертификатов — на сервере указан cert.pem вместо fullchain.pem, не передан intermediate-сертификат, или цепочка собрана в неправильном порядке. Локально в браузере иногда всё открывается из-за кэша промежуточных сертификатов, но Cloudflare может не принять такую цепочку.

5) Используется самоподписанный сертификат — обычный self-signed сертификат не подходит для режима Full (strict). Исключение — сертификат Cloudflare Origin CA: он не доверен браузерами напрямую, но доверен Cloudflare для соединения с origin.

6) Сертификат установлен на старом сервере после переезда — DNS-записи в Cloudflare указывают на один IP, а сертификат обновлён на другом. Или часть записей A/AAAA ведёт на старые origin-адреса. В итоге Cloudflare иногда попадает на сервер с неправильным сертификатом.

7) Проблема на балансировщике или Kubernetes ingress — сертификат обновили в секретах, но ingress не перечитал конфигурацию; балансировщик отдаёт старый сертификат; один backend за LB настроен иначе; wildcard-секрет не подключён к нужному host.

8) Домен в Cloudflare for SaaS или custom hostname не прошёл проверку — для SaaS-сценариев Cloudflare также валидирует сертификаты кастомных доменов. Ошибка может быть связана с неправильным hostname, отсутствием валидации или конфликтом сертификатов.

Быстрая диагностика: где именно сломан TLS

Сначала нужно понять, какой сертификат реально видит Cloudflare на origin. Проверять сайт обычным curl https://example.com недостаточно: такой запрос попадёт на Cloudflare edge, а не на ваш сервер. Нужно обратиться к origin напрямую, но с правильным SNI.

Если знаете IP origin-сервера, выполните:

curl -Iv --resolve example.com:443:203.0.113.10 https://example.com/

Замените example.com и 203.0.113.10 на свой домен и IP. Параметр --resolve заставляет curl подключиться к нужному IP, но оставить hostname example.com для TLS/SNI и HTTP-заголовка Host.

На что смотреть в выводе:

1) SSL certificate verify ok — сертификат валиден для вашей машины. Если при этом Cloudflare всё равно показывает 526, проверьте цепочку, SNI, IPv6, несколько origin-IP и настройки Cloudflare.

2) certificate has expired — сертификат истёк. Нужно перевыпустить или обновить сертификат на origin.

3) no alternative certificate subject name matches — сертификат не содержит нужный домен в SAN.

4) unable to get local issuer certificate — проблема с цепочкой: сервер не отдаёт intermediate-сертификат.

5) self signed certificate — установлен обычный самоподписанный сертификат. Для Full (strict) он не подходит.

Более подробную информацию даёт openssl:

openssl s_client -connect 203.0.113.10:443 -servername example.com -showcerts </dev/null

Проверьте строки:

subject= — кому выдан сертификат.

issuer= — кто выпустил сертификат.

notBefore и notAfter — период действия.

Verify return code: 0 (ok) — успешная проверка цепочки.

Если Verify return code не равен 0, Cloudflare с высокой вероятностью тоже не примет сертификат.

Отдельно проверьте DNS. В Cloudflare в разделе DNS посмотрите все записи A и AAAA для домена и поддоменов. Если включён IPv6, Cloudflare может подключаться к IPv6-origin, где сертификат не обновлён. Для диагностики DNS пригодится материал про dig.

Проверьте режим SSL/TLS в Cloudflare

Откройте панель Cloudflare: SSL/TLS → Overview. Там выбран режим шифрования между Cloudflare и origin.

Основные варианты:

1) Off — Cloudflare не использует HTTPS до origin. Для нормального сайта почти никогда не подходит.

2) Flexible — браузер подключается к Cloudflare по HTTPS, но Cloudflare ходит на origin по HTTP. Это может скрыть проблему сертификата, но создаёт другие риски: трафик до origin не шифруется, а при редиректе HTTP→HTTPS на сервере часто возникает ERR_TOO_MANY_REDIRECTS.

3) Full — Cloudflare подключается к origin по HTTPS, но не проверяет сертификат строго. Подойдёт как временная мера, если нужно быстро вернуть сайт, а сертификат уже чинят. Но это не полноценное решение: Cloudflare будет принимать просроченный, самоподписанный или неподходящий сертификат.

4) Full (strict) — правильный режим для продакшена. Cloudflare требует валидный сертификат на origin. Ошибка 526 как раз говорит, что origin к этому режиму не готов или сломался после обновления.

Если сайт лежит прямо сейчас, можно временно переключить Full (strict) на Full, чтобы восстановить доступность. Но это именно временный обход: после установки корректного сертификата верните Full (strict). Не оставляйте Flexible как постоянное решение — оно ухудшает модель безопасности и часто маскирует реальные проблемы HTTPS.

Если нужно освежить базу по сертификатам, TLS и роли центров сертификации, посмотрите разбор как работает HTTPS.

Как исправить ошибку 526 на origin-сервере

Порядок действий зависит от причины, но в большинстве случаев помогает один из следующих сценариев.

1) Перевыпустить сертификат Let's Encrypt — если сертификат истёк или выпущен не на те домены, перевыпустите его с полным списком имён:

sudo certbot --nginx -d example.com -d www.example.com
sudo certbot renew --dry-run
sudo systemctl reload nginx

Для Apache используйте плагин --apache, если он установлен:

sudo certbot --apache -d example.com -d www.example.com

После выпуска проверьте, что в конфигурации веб-сервера используются актуальные файлы и указан fullchain.pem, а не cert.pem:

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;
 
    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

Подробная инструкция есть в статье как настроить HTTPS и бесплатный SSL-сертификат в Nginx.

2) Установить Cloudflare Origin Certificate — хороший вариант, если origin всегда закрыт за Cloudflare и пользователи не ходят на него напрямую. В панели Cloudflare откройте SSL/TLS → Origin Server → Create Certificate, выберите домены, сгенерируйте сертификат и ключ, установите их на сервер.

Такой сертификат доверен Cloudflare, поэтому работает с Full (strict). Но браузеры напрямую ему не доверяют: если открыть origin без Cloudflare, будет ошибка доверия. Для публичного прямого доступа лучше использовать Let's Encrypt или другой публично доверенный сертификат.

3) Исправить server_name и SNI — если сервер отдаёт дефолтный сертификат, проверьте виртуальные хосты. В Nginx блок с нужным server_name должен слушать 443 ssl, а сертификат — соответствовать этому имени. Не полагайтесь на первый default_server, особенно на серверах с несколькими сайтами.

Проверьте:

nginx -t

nginx -T | grep -A20 "server_name example.com"

После изменений выполните:

sudo systemctl reload nginx

4) Добавить все нужные имена в сертификат — если Cloudflare проксирует api.example.com, admin.example.com, www.example.com, каждый hostname должен быть в сертификате или покрываться wildcard-сертификатом *.example.com. Сам *.example.com не покрывает example.com без www — этот домен нужно добавлять отдельно.

5) Обновить сертификат на всех origin-узлах — если за Cloudflare стоит балансировщик, несколько VM, Docker Swarm, Kubernetes или autoscaling-группа, сертификат должен быть одинаково корректным на всех узлах. Иначе 526 может появляться периодически: один запрос попадает на обновлённый backend, другой — на старый.

6) Проверить контейнеры и volume — в Docker частая ошибка: certbot обновил сертификат на хосте, но Nginx в контейнере видит старый volume или другой путь. Проверьте монтирование /etc/letsencrypt, перезапуск контейнера и reload процесса внутри него. Если инфраструктура контейнерная, полезно держать под рукой базовые команды из статьи Основные команды Docker.

Особые случаи: прокси, балансировщики, Kubernetes и IPv6

Ошибка 526 часто выглядит простой, пока сайт не оказывается за несколькими слоями инфраструктуры. Тогда сертификат может быть правильным «где-то», но не там, куда реально подключается Cloudflare.

1) Cloudflare → внешний балансировщик → Nginx — сертификат может завершаться на балансировщике, а не на Nginx. В этом случае исправлять нужно именно LB: AWS ALB, HAProxy, Nginx reverse proxy, ingress-controller или панель хостинга. Если сертификат установлен только на backend, но TLS завершается раньше, Cloudflare его не увидит.

2) Cloudflare → Nginx reverse proxy → приложение — для 526 важен сертификат на первом HTTPS-слое, который принимает соединение от Cloudflare. Сертификаты внутри приложения уже не участвуют, если Nginx терминирует TLS. Про схему reverse proxy можно отдельно почитать в материале что такое Nginx reverse proxy.

3) Kubernetes ingress — проверьте tls.secretName, namespace секрета, hosts в ingress-ресурсе и фактический сертификат, который отдаёт ingress. После обновления секрета ingress-контроллер обычно перечитывает его сам, но при ошибках конфигурации может продолжить отдавать default certificate.

4) Несколько IP у одной DNS-записи — если в Cloudflare указано несколько A или AAAA, все origin-адреса должны отдавать валидный сертификат. Один забытый IPv6-адрес способен вызывать 526 только у части запросов.

5) Origin доступен и напрямую, и через Cloudflare — если пользователи, API-клиенты или поисковые роботы обращаются к origin напрямую, Cloudflare Origin Certificate может быть плохим выбором. Он решит 526 для Cloudflare, но прямые клиенты получат ошибку доверия сертификата.

6) Authenticated Origin Pulls — эта настройка добавляет проверку клиентского сертификата Cloudflare на origin. Неверная настройка чаще приводит к отказу на стороне сервера, но при сложной TLS-конфигурации может усложнить диагностику. На время расследования полезно разделить проблемы: сначала добиться валидного origin-сертификата, затем включать mTLS-проверки.

Если ошибка проявляется как TLS-сбой без явного 526, пригодится отдельный материал про ошибку TLS-рукопожатия.

Как проверить, что ошибка 526 исправлена

После изменений не ограничивайтесь перезагрузкой веб-сервера. Проверьте всю цепочку.

1) Проверка конфигурации веб-сервера — для Nginx:

sudo nginx -t

sudo systemctl reload nginx

Для Apache:

sudo apachectl configtest

sudo systemctl reload apache2

или, в зависимости от дистрибутива:

sudo systemctl reload httpd

2) Проверка origin напрямую — снова выполните:

curl -Iv --resolve example.com:443:203.0.113.10 https://example.com/

Ошибок валидации сертификата быть не должно.

3) Проверка сертификата через openssl — убедитесь, что Verify return code: 0 (ok), даты актуальны, а в SAN есть нужные имена.

4) Проверка через Cloudflare — откройте сайт обычным способом, без --resolve. Если страница кэшировалась или браузер показывает старый результат, используйте приватное окно или curl -I https://example.com/.

5) Проверка всех поддоменов — ошибка может быть исправлена для example.com, но остаться для www, api, static или другого hostname. Пройдитесь по всем проксируемым записям.

6) Проверка IPv4 и IPv6 — если есть AAAA, отдельно протестируйте IPv6-origin. Иногда сертификат обновляют на IPv4-балансировщике, а IPv6 ведёт на старый сервер.

7) Проверка мониторинга — если у вас настроен мониторинг доступности, он должен перестать получать 526 и вернуться к успешным HTTP-ответам. Например, Statuser может проверять сайт с заданным интервалом и прислать уведомление, когда вместо ожидаемого 200 появляется ошибка Cloudflare. Это удобно именно для таких сбоев: пользователи уже видят страницу ошибки, а приложение на origin может при этом выглядеть «живым» по внутренним метрикам.

Как предотвратить повторение ошибки 526

Ошибка 526 почти всегда связана с дисциплиной вокруг сертификатов, и её проще предупредить, чем расследовать в момент простоя.

1) Автоматизируйте продление сертификатов — если используете Let's Encrypt, проверьте certbot.timer:

systemctl status certbot.timer

Запустите тестовое продление:

sudo certbot renew --dry-run

Убедитесь, что после обновления сертификата веб-сервер перечитывает конфигурацию. Иногда сертификат успешно обновлён на диске, но Nginx продолжает держать старый в памяти до reload.

2) Мониторьте срок действия сертификатов — проверяйте не только сертификат на Cloudflare edge, но и origin-сертификат: это разные сущности. Внешний браузер может видеть валидный сертификат Cloudflare, пока origin уже близок к истечению. Подробнее — в статье почему важен мониторинг SSL-сертификатов.

3) Документируйте, где завершается TLS — в простой схеме это Nginx на сервере, в сложной — балансировщик, ingress, reverse proxy, service mesh. Команда должна понимать, где менять сертификат и какие сервисы перезагружать.

4) Не держите временные режимы постоянно — Full вместо Full (strict) скрывает проблему, но снижает контроль над безопасностью, а Flexible ломает end-to-end модель HTTPS между Cloudflare и origin.

5) Проверяйте сертификаты после миграций — смена хостинга, IP, балансировщика, ingress-контроллера, Docker-volume или DNS-записей должна сопровождаться TLS-проверкой через curl --resolve и openssl s_client.

6) Настройте алерты без шума — для доступности достаточно проверять ключевые URL с разумным интервалом и уведомлять о подтверждённом сбое. Если алерты срабатывают слишком часто и без причины, их начинают игнорировать. Для базового подхода можно посмотреть материал что такое uptime monitoring и как он работает.

Короткий чеклист устранения ошибки 526

Если нужно быстро пройтись по основному:

1) Посмотрите режим Cloudflare — SSL/TLS → Overview. При Full (strict) origin-сертификат должен быть валидным.

2) Узнайте IP origin — проверьте записи A и AAAA в Cloudflare DNS.

3) Проверьте сертификат напрямую — используйте curl -Iv --resolve example.com:443:ORIGIN_IP https://example.com/.

4) Проверьте SNI и цепочку — используйте openssl s_client -connect ORIGIN_IP:443 -servername example.com -showcerts.

5) Исправьте причину — продлите сертификат, добавьте нужный домен в SAN, замените cert.pem на fullchain.pem, настройте правильный virtual host, обновите сертификат на всех backend-узлах.

6) Перезагрузите веб-сервер — nginx -t && systemctl reload nginx или аналог для Apache/LB/ingress.

7) Верните Full (strict) — если временно переключались на Full, верните строгий режим после исправления.

8) Настройте мониторинг — проверьте срок действия сертификатов и доступность ключевых страниц, чтобы узнать о проблеме до массовых жалоб пользователей.

FAQ

Почему Cloudflare показывает 526, если в браузере сертификат выглядит нормальным?
Браузер видит сертификат Cloudflare на edge, а ошибка 526 относится к сертификату на origin-сервере. Это разные TLS-соединения.

Можно ли просто переключить Cloudflare с Full (strict) на Full?
Можно как временную меру, чтобы быстро вернуть сайт. Но постоянное решение — установить корректный сертификат на origin и снова включить Full (strict).

Подходит ли самоподписанный сертификат для исправления 526?
Обычный self-signed сертификат не подходит для Full (strict). Подойдёт сертификат публичного центра сертификации или Cloudflare Origin Certificate.

Почему ошибка 526 появляется только иногда?
Обычно это несколько origin-IP, балансировщик или IPv6: часть серверов отдаёт правильный сертификат, часть — старый, просроченный или выпущенный на другой домен.