Cloudflare 526: сертификат сервера сайта не прошёл проверку

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

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

Самая распространённая — истёк срок действия сертификата на сервере. Вторая — сертификат выдан на другое имя и не покрывает нужный домен или поддомен. Третья — сертификат самоподписанный, а режим требует доверенного центра. Четвёртая — на сервере отсутствует цепочка промежуточных сертификатов, из-за чего проверить его нельзя.

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

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

Сравните с настройками режима в панели Cloudflare: строгий режим требует сертификата, выданного доверенным центром, либо специального сертификата источника, который выпускает сама сеть доставки.

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

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

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

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

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

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