Ошибки SSL: что это такое и как их исправить

Ошибка SSL — это то, что браузер показывает, когда он не может открыть доверенное зашифрованное соединение с веб-сайтом. Вместо запрошенной страницы вы получаете экран предупреждения и короткий код заглавными буквами, например NET::ERR_CERT_AUTHORITY_INVALID или SSL_ERROR_NO_CYPHER_OVERLAP.

Именно этот код является полезной частью, и большинство руководств пропускают его. «Ошибка SSL» не является техническим термином, и никакой стандарт его не определяет. Это обычное название для целого семейства разных сбоев, поэтому общие советы, например очистить кэш, устраняют одни из них и совершенно не помогают с остальными.

Что на самом деле представляет собой ошибка SSL

Когда вы загружаете адрес, начинающийся с https://, ваш браузер и сервер проводят короткое согласование, называемое TLS handshake, прежде чем передать содержимое страницы. Во время handshake согласуется версия протокола и набор алгоритмов шифрования, а сервер подтверждает свою личность с помощью сертификата. Если какая-либо часть этого процесса не удаётся, браузер отказывается продолжать и показывает вам ошибку вместо страницы.

Стоит разграничить SSL и TLS, поскольку название вызывает реальную путаницу. SSL — это исходный протокол, и каждая его версия уже много лет считается устаревшей. То, что на самом деле использует ваш браузер, — это TLS. Слово «SSL» сохраняется в названиях продуктов, в директивах конфигурации и в кодах ошибок, поэтому вы до сих пор видите его повсюду. Когда страница или браузер говорят SSL, почти всегда имеется в виду TLS.

Это важно для устранения неполадок, поскольку популярное определение ошибки SSL слишком узкое. Часто можно прочитать, что ошибка SSL означает, что браузер не смог проверить сертификат сайта. Это верно для одной группы этих ошибок и неверно для остальных. Сервер, отвечающий на порту HTTPS обычным незашифрованным текстом, вызывает ошибку SSL и вообще никогда не отправляет сертификат. Две машины, которые не могут согласовать набор шифров, вызывают ошибку ещё до того, как рассматривается сертификат. Начинать с сертификата, когда сертификат вообще не был проблемой, — самая частая причина того, что люди тратят часы на решение, которое занимает пять минут.

На каком этапе соединения произошёл сбой

Каждое HTTPS-соединение проходит через одну и ту же последовательность, и ошибка SSL — это просто точка, в которой эта последовательность остановилась. Определение этапа сразу сужает круг возможных причин, поскольку у каждого этапа совершенно свой набор объяснений.

1. Соединение так и не стало TLS. Ваш браузер открыл соединение, но в ответ пришло не TLS, либо другая сторона закрыла соединение до завершения handshake. Сертификат здесь не участвует, и заменять его не нужно.
2. Handshake не удался во время согласования. Обе стороны использовали TLS, но не смогли договориться о версии протокола, наборе шифров или о том, какой сайт запрашивается. Handshake останавливается до проверки сертификата, а часто и до его отправки.
3. Сертификат был получен и отклонён. Это та группа, которую люди имеют в виду, говоря «ошибка SSL». Сюда относятся истечение срока действия, покрытие имени хоста, цепочка доверия, отзыв и надёжность подписи.
4. Handshake прошёл успешно, а сбой произошёл позже. Зашифрованное соединение было установлено корректно, а затем на более позднем уровне что-то сломалось. К этому моменту сертификат уже подтверждён как исправный, поэтому его замена ничего не изменит.

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

Найдите свою ошибку

Прочитайте код, напечатанный под сообщением о предупреждении. В Chrome и Edge он расположен заглавными буквами под текстом «Ваше подключение не защищено». В Firefox может потребоваться открыть дополнительные сведения на странице предупреждения. Затем найдите его ниже.

Этап 1: соединение так и не стало TLS

• SSL_ERROR_RX_RECORD_TOO_LONG в Firefox означает, что сервер ответил на запрос HTTPS чем-то, что не является TLS, почти всегда обычным HTTP на порту 443. Это проблема конфигурации сервера.
• PR_END_OF_FILE_ERROR в Firefox означает, что другая сторона закрыла соединение до завершения handshake. Причина часто находится между вами и сервером, а не на одном из концов.

Этап 2: handshake не удался во время согласования

• ERR_SSL_PROTOCOL_ERROR — это общий код Chrome для handshake, который не удался по причине, которую не удалось точно определить. Начните отсюда, если у вас именно этот код, поскольку первая задача — сузить причину.
• SSL_ERROR_NO_CYPHER_OVERLAP — это эквивалент в Firefox, столь же общий: он появляется при любом критическом сбое handshake, о котором сообщает сервер, независимо от реальной причины на стороне сервера.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH — это код Chrome для того же класса сбоев, возникающий для короткого и конкретного списка условий согласования.
• ERR_SSL_UNRECOGNIZED_NAME_ALERT означает, что сервер намеренно завершил handshake, поскольку запрошенное имя хоста не соответствует ни одному настроенному на нём сайту. Сертификат не отправляется, поэтому дело не в сертификате.
• ERR_BAD_SSL_CLIENT_AUTH_CERT действует в направлении, противоположном всем остальным ошибкам здесь: сайт запросил у вашего браузера сертификат и отклонил полученный, либо не получил его вовсе. Именно эта ошибка действительно устраняется на вашем устройстве.
• Ошибка Cloudflare 525 — это сбой handshake на другом участке пути: между Cloudflare и исходным сервером за ним, а не между вашим браузером и Cloudflare. Посетители не могут ничего с этим сделать.

Этап 3: сертификат был получен и отклонён

Ваше подключение не защищено — это экран предупреждения Chrome для всей этой группы, а не причина сама по себе, так что если это всё, что у вас есть, сначала прочитайте код под ним.

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

• NET::ERR_CERT_AUTHORITY_INVALID в Chrome и Edge.
• SEC_ERROR_UNKNOWN_ISSUER в Firefox — то же самое состояние под другим именем.
• Просроченный промежуточный сертификат, когда цепочка существует, но одно из звеньев над вами истекло.
• MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, когда цепочки нет вовсе, поскольку сертификат подписан сам собой.

Даты или имя не совпадают. Сертификат является доверенным, но не применим к этому моменту или к этому имени хоста.

• NET::ERR_CERT_DATE_INVALID, когда срок действия сертификата истёк или ещё не начался. Стоит знать, что неправильные часы на вашем собственном устройстве также вызывают эту ошибку.
• NET::ERR_CERT_COMMON_NAME_INVALID, когда имя хоста не указано в сертификате.
• DLG_FLAGS_SEC_CERT_CN_INVALID — та же проблема с именем хоста, о которой сообщает программное обеспечение, построенное на более старом веб-стеке Windows, в основном режим Internet Explorer в Edge и корпоративные приложения.

Сертификат доверенный и действующий, но не разрешён по другой причине.

• NET::ERR_CERT_REVOKED, когда Certificate Authority отменил его до истечения срока действия.
• NET::ERR_CERTIFICATE_TRANSPARENCY_REQUIRED, когда сертификат поступил без достаточного публичного доказательства выпуска.
• NET::ERR_CERT_WEAK_SIGNATURE_ALGORITHM, когда что-то в цепочке подписано с использованием SHA-1. Актуальный Chrome может сообщать о том же сертификате под другим кодом, но условие и способ решения не меняются.
• SEC_ERROR_REUSED_ISSUER_AND_SERIAL — конфликт внутри собственного хранилища сертификатов Firefox, а не сбой в соединении.
• NET::ERR_SSL_PINNED_KEY_NOT_IN_CERT_CHAIN, что относится к очень небольшому набору доменов, встроенных в браузер, поэтому обычный веб-сайт не может вызвать эту ошибку.

Сам файл сертификата некорректен. Эти две ошибки обнаруживаются на сервере, а не в браузере, и обычно они вообще не позволяют сайту обслуживать HTTPS.

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

Этап 4: handshake прошёл успешно, а сбой произошёл позже

Эти ошибки по привычке относят к ошибкам SSL. В каждом случае зашифрованное соединение уже работало, то есть сертификат был успешно проверен, и его повторный выпуск не поможет.

• ERR_SSL_BAD_RECORD_MAC_ALERT означает, что сервер получил зашифрованные данные, которые не смог проверить, что происходит после handshake, под сеансовыми ключами. Что-то на пути искажает или переписывает трафик.
• ERR_QUIC_PROTOCOL_ERROR — это сбой QUIC, транспортного протокола, лежащего в основе HTTP/3. Это не проблема сертификата, и обычная причина — брандмауэр или VPN, фильтрующий UDP.
• ERR_SPDY_PROTOCOL_ERROR — это сбой на уровне HTTP/2, который находится над завершённым handshake TLS.
• Смешанный контент — особый случай: страница отлично загрузилась по HTTPS, а затем запросила ресурс по обычному HTTP. Это не вызывает страницы ошибки вообще, только пониженный уровень замка и отсутствующие скрипты или изображения.

Ошибки, названные по устройству, а не по этапу

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

• Ошибки SSL на iPhone и iPad, включая сообщение «Произошла ошибка SSL, и безопасное соединение с сервером не может быть установлено». Первым делом стоит проверить настройку даты и времени.
• Ошибки соединения SSL на Android, где Chrome и другие приложения обращаются к разным хранилищам доверия, а отсутствующий промежуточный сертификат вызывает больше проблем, чем на компьютере.

Коды, которые больше не появляются

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

• NET::ERR_CERT_SYMANTEC_LEGACY был удалён в Chrome 136, выпущенном в апреле 2025 года.
• ERR_SSL_VERSION_INTERFERENCE был удалён в Chrome 76 в 2019 году, хотя описываемое им вмешательство до сих пор происходит и теперь проявляется иначе.
• ERR_SPDY_PROTOCOL_ERROR был переименован в ERR_HTTP2_PROTOCOL_ERROR в Chrome 77, также в 2019 году. Описываемый им сбой до сих пор актуален, поэтому он указан в четвёртом этапе выше.

Если вы посещаете сайт

Большинство ошибок SSL должен устранять сам веб-сайт, и никакие манипуляции с вашим собственным устройством не изменят их. Есть короткий список подлинных исключений, и стоит пройтись по нему, прежде чем делать вывод, что сайт неработоспособен.

• Проверьте часы. Проверка сертификата сравнивает даты сертификата с текущим временем вашего устройства. Часы, которые отстают или спешат на месяцы или годы, делают любой сертификат недействительным на первый взгляд, и это самая частая причина на стороне посетителя.
• Попробуйте другую сеть. Переключение с Wi-Fi на мобильные данные, или наоборот, за несколько секунд подскажет, перехватывает ли что-то трафик в сети. Публичный Wi-Fi и Wi-Fi в отелях — частые виновники.
• Временно отключите сканирование HTTPS. Антивирусные продукты и корпоративные прокси проверяют зашифрованный трафик, подставляя собственные сертификаты. Когда они делают это неправильно, вы получаете ошибку SSL на сайтах, которые нормально работают в других условиях.
• Попробуйте приватное окно и другой браузер. Если ошибка появляется в одном браузере, но не в другом, причина обычно локальная — в расширении или в сохранённых данных. Если она появляется во всех браузерах, проблема на стороне сайта.

Если ничего из этого не помогает, проблема на сервере, и честный ответ — вы не можете её устранить. Это полностью применимо к ошибке Cloudflare 525, где сбой происходит на соединении, в котором ваш браузер не участвует.

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

Если вы управляете веб-сайтом

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

Начните с внешней проверки

Проверьте домен с помощью нашего SSL Checker. Он показывает, что сервер на самом деле отправляет внешнему миру, что часто отличается от того, что находится в конфигурационном файле. Цепочка, которая выглядит полной на диске, но приходит к браузеру неполной, — самая частая находка, и именно она вызывает как NET::ERR_CERT_AUTHORITY_INVALID, так и SEC_ERROR_UNKNOWN_ISSUER.

То же самое можно увидеть из командной строки. Эта команда выводит все сертификаты, которые предлагает сервер, в том порядке, в котором он их предлагает:

openssl s_client -connect example.com:443 -servername example.com -showcerts

Читайте список сертификатов в этом выводе, а не строку Verify return code в конце. Эта строка гораздо менее информативна, чем кажется: она сообщает только вердикт OpenSSL по цепочке, игнорирует имя хоста, если вы явно не запросите такую проверку, и выводит 0 (ok) даже если сервер вообще не отправил сертификат, потому что handshake был прерван. Если в выводе написано no peer certificate available вместо строки subject=, значит ничего не было проверено, и сбой произошёл раньше.

Проверьте даты и имя хоста

Эти два фактора составляют значительную долю отказов сертификатов. Чтобы прочитать окно действия сертификата, который выдаёт сервер:

openssl s_client -connect example.com:443 -servername example.com </dev/null | openssl x509 -noout -dates -subject

Браузеры сопоставляют имя хоста с расширением subjectAltName и полностью игнорируют Common Name, поэтому именно это поле нужно проверять в локальном файле сертификата:

openssl x509 -noout -text -in certificate.crt | grep -A1 "Subject Alternative Name"

Чтобы OpenSSL применил такую же проверку имени хоста, что и браузер, добавьте флаг, а не предполагайте, что чистый результат уже покрывает эту проверку:

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com

На macOS эти команды требуют внимания. openssl, поставляемый с macOS, — это LibreSSL, который полностью отвергает -verify_hostname и сообщает об исправном результате на некоторых действительно повреждённых цепочках. Установите OpenSSL через Homebrew, затем снова выполните openssl version, чтобы убедиться, какой именно бинарный файл вы вызываете. Если он всё ещё сообщает о LibreSSL, значит ваш PATH сначала находит системную копию, поэтому вызывайте /opt/homebrew/bin/openssl по полному пути.

Затем исправьте и проверьте

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

• Отправляйте полную цепочку. Объедините ваш сертификат и промежуточные сертификаты, предоставленные вашим Certificate Authority, в файл, на который указывает ваш сервер. Не помещайте закрытый ключ в этот файл.
• Продлевайте до истечения срока и автоматизируйте это. Срок действия сертификатов сокращается, поэтому всё, что продлевается вручную, в конце концов будет продлено с опозданием. Автоматизация ACME устраняет этот дедлайн.
• Покрывайте каждое имя хоста, которое вы фактически обслуживаете. Сертификат для домена не покрывает его поддомены, если это не wildcard-сертификат или он явно их не перечисляет.

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

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

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

• Автоматизируйте продление. Максимальный срок действия сертификатов сокращается поэтапно в течение следующих нескольких лет, и ручное продление станет непрактичным задолго до окончания этого срока. Автоматизируйте сейчас, а не когда что-то сломается.
• Отслеживайте истечение срока независимо. Напоминание в календаре не сработает, если человек уйдёт из компании. Внешняя проверка, которая предупреждает вас за несколько недель, не подведёт.
• Проверяйте после каждого изменения. Миграции серверов, изменения CDN и обновления панели управления незаметно переписывают конфигурацию сертификатов. После этого проверяйте её извне.
• Тестируйте на телефоне, а не только на компьютере. Мобильные платформы строже относятся к неполным цепочкам, поэтому проблема с цепочкой часто проявляется на телефоне, тогда как на компьютере всё выглядит нормально.
• Устанавливайте правильно с первого раза. Наши руководства по установке охватывают шаги по цепочке и привязке для каждой платформы, а большинство ошибок с цепочкой возникает именно на этапе установки.

Часто задаваемые вопросы