Cloudflare 525: не удалось согласовать шифрование с сервером сайта

Ошибка 525 возникает, когда Cloudflare пытается установить защищённое соединение с исходным сервером, но рукопожатие TLS не удаётся. Сервер не смог договориться с сетью доставки о параметрах шифрования: версии протокола, наборе шифров или сертификате. Браузер посетителя тут ни при чём, он благополучно соединился с сетью доставки, а проблема на втором участке пути.

Действует это так: у сайта включён режим, требующий шифрования до источника, а сервер отвечает нечто несовместимое или не отвечает на защищённом порту вообще.

Первая — на сервере не включено шифрование: порт для защищённых соединений закрыт или на нём слушает программа, не поддерживающая TLS. Вторая — у сервера нет сертификата для нужного имени, и он не может подтвердить свою подлинность. Третья — слишком старая конфигурация: сервер поддерживает только устаревшие версии протокола или набор шифров, который сеть доставки не использует.

Четвёртая — на общем сервере с несколькими сайтами неверно настроен выбор сертификата по имени, поэтому запрос от Cloudflare получает чужой сертификат или отказ. Пятая — межсетевой экран или обратный прокси перед сервером вмешивается в рукопожатие.

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

Если вы сами владелец, запомните идентификатор запроса из страницы ошибки: он поможет поддержке найти запись в журналах.

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

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

Чтобы не гадать, можно проверить защищённый порт сервера напрямую. Утилиты для проверки TLS показывают, какие версии протокола и шифры поддерживает сервер, какой сертификат он отдаёт и удаётся ли завершить рукопожатие. Если утилита сообщает, что соединение не установлено, значит, порт закрыт или на нём вообще не включено шифрование.

Обращайте внимание на имя, для которого вы проверяете: сервер с несколькими сайтами выбирает сертификат по имени, и запрос без указания имени получит сертификат по умолчанию. Сравните вывод с тем, что настроено в панели сети доставки. Если сервер поддерживает только очень старые версии протокола, обновите программное обеспечение веб-сервера и библиотеки шифрования: это устраняет и ошибку 525, и уязвимости, о которых предупреждают проверки безопасности.

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

Если сервер расположен за собственным обратным прокси или балансировщиком, проверяйте рукопожатие на каждом участке, а не только на конечном. Иногда сертификат корректно установлен на приложении, но промежуточный узел использует другой набор шифров и отклоняет соединение. Сравните настройки всех узлов и приведите их к единому современному профилю. Не забудьте проверить и поддомены: сертификат, подходящий для основного имени, может не покрывать дополнительные, и ошибка вернётся уже на них.