Ошибка SSL означает, что браузер не смог подтвердить защищённое соединение с нужным сайтом или загрузить его ресурсы по HTTPS. Сначала запишите точный код ошибки, адрес и время. По одной фразе «соединение не защищено» нельзя определить, истёк ли сертификат, не совпало ли имя или вмешался сетевой прокси.
Если вы посетитель, не вводите пароль или платёжные данные через предупреждение браузера. Проверьте адрес, дату и время устройства, повторите открытие в обновлённом браузере и другой сети. Если ошибка сохраняется, передайте владельцу URL и код ошибки. Добавление неизвестного сертификата в доверенные не является обычным способом исправления сайта.
Для владельца сайта начальная проверка SSL-сертификата покажет доступные сведения: издателя, имена, срок действия и параметры одного TLS-соединения. Оценка reChecker не заменяет проверку всей цепочки доверия, всех протоколов и совместимости браузеров. Если поле не получено из-за таймаута, это отсутствие результата, а не подтверждение исправности.
Быстрая диагностика по коду ошибки
| Признак | Что проверить сначала | Следующее действие |
|---|---|---|
ERR_CERT_DATE_INVALID | Срок сертификата и часы устройства | Проверить обновление и реально выдаваемый сертификат |
ERR_CERT_COMMON_NAME_INVALID | Полный hostname и SAN сертификата | Выпустить сертификат для нужного имени или исправить выбор виртуального хоста |
ERR_CERT_AUTHORITY_INVALID | Доверие к издателю и промежуточные сертификаты | Проверить цепочку и используемое хранилище доверенных CA |
ERR_SSL_VERSION_OR_CIPHER_MISMATCH | Переговоры TLS, настройки прокси и сервера | Сравнить параметры соединения и конфигурацию |
ERR_CERT_REVOKED | Отзыв сертификата и состояние ключа | Выяснить причину отзыва и заменить сертификат |
Mixed Content в Console | HTTP-ресурсы внутри HTTPS-страницы | Исправить конкретные URL и повторить загрузку |
Коды зависят от браузера. Сравнивайте сам адрес и обстоятельства, а не только похожий текст предупреждения. Ошибка на www.example.com и успешное открытие example.com относятся к разным именам.
Срок сертификата: ERR_CERT_DATE_INVALID
Проверьте Not Before и Not After, затем часы клиента и сервера. Сертификат может быть ещё не действующим, уже истёкшим или корректным при неверном времени на устройстве. Не назначайте причину только по возрасту последнего выпуска.
Если сертификатом управляет Certbot, проверьте настроенное задание обновления и выполните проверку продления:
sudo certbot renew --dry-runПосле успешного продления убедитесь, что веб-сервер загрузил новый сертификат и публичный адрес выдаёт именно его. Команда обновления может сработать, а сервер продолжит использовать старый файл или сертификат на другом балансировщике. Порядок обновления и хуки описаны в руководстве Certbot.
Для регулярного контроля срока используйте SSL Monitor. Мониторинг предупреждает о наблюдаемом состоянии; он не выпускает сертификат и не исправляет настройки сервера автоматически.
Имя домена: ERR_CERT_COMMON_NAME_INVALID
Сопоставьте hostname из адресной строки с именами SAN в реально полученном сертификате. Проверьте основной домен, www, нужные поддомены и адрес после перехода. Wildcard для одного уровня поддоменов не означает покрытие любого адреса на любой глубине.
Если сервер обслуживает несколько сайтов, проверьте SNI и выбор виртуального хоста. Ошибка может возникать из-за сертификата другого сайта на том же IP. При подключении к IP без hostname вы можете получить сертификат виртуального хоста по умолчанию.
Редирект с HTTPS-адреса не устраняет ошибку его сертификата: браузер проверяет TLS до получения HTTP-ответа с переходом. Сначала обеспечьте корректное соединение для исходного имени, затем настраивайте перенаправление. Проверка редиректов помогает изучить цепочку HTTP после установления соединения.
Цепочка доверия: ERR_CERT_AUTHORITY_INVALID
Проверьте сертификат сервера и промежуточные сертификаты. В Nginx файл ssl_certificate должен содержать сертификат сайта, затем необходимые промежуточные сертификаты. Не добавляйте корневой сертификат наугад и не исправляйте проблему отключением проверки доверия. Пример и порядок приведены в документации Nginx.
Пример подключения к вашему серверу с SNI и проверкой имени:
openssl s_client -connect example.com:443 \
-servername example.com -verify_hostname example.com \
-verify_return_error -showcerts </dev/nullЗамените example.com своим доменом. Команда использует доверенные CA текущего окружения. -showcerts показывает сертификаты, присланные сервером, и сам по себе не подтверждает доверенную цепочку. Параметры проверки описаны в документации OpenSSL.
Если соединение работает на одном устройстве и не работает на другом, сравните версии ОС, браузера, доверенных CA и сеть. Корпоративный прокси может подставлять собственный сертификат. Проверьте его издателя и передайте данные администратору сети; не устанавливайте случайный CA ради обхода предупреждения.
TLS и шифры: ERR_SSL_VERSION_OR_CIPHER_MISMATCH
Успешное соединение одного проверяющего клиента показывает выбранный протокол и шифр для этой попытки. Оно не описывает все варианты, поддерживаемые сервером. Для глубокой проверки используйте профильный TLS-сканер и изучите фактическую конфигурацию сервера, CDN и балансировщика.
Сначала определите, на каком участке не устанавливается соединение: браузер → CDN или CDN → origin. Проверьте, что целевой сервер действительно слушает HTTPS на ожидаемом порту и использует нужный сертификат. Не включайте устаревшие протоколы вслепую, чтобы убрать одну ошибку: это меняет условия безопасности для остальных посетителей.
Сохраняйте версию клиента, команду, время и результат. После правки повторите ту же проверку и открытие в проблемном браузере. Если проверка недоступна, оставьте этот сценарий неподтверждённым.
Отозванный сертификат: ERR_CERT_REVOKED
Выясните причину отзыва у центра сертификации. Если скомпрометирован приватный ключ, нужен новый ключ и сертификат; простой повторный выпуск со старым ключом не закрывает проблему. Затем замените файлы, обновите конфигурацию и проверьте выдаваемый сертификат на всех узлах.
Проверка срока не является проверкой отзыва. Даже действующий по датам сертификат может быть отозван. Зафиксируйте, каким инструментом и по какому источнику проверено это состояние.
Mixed content: сертификат исправен, ресурсы блокируются
Откройте DevTools → Console и Network. Найдите конкретный HTTP-запрос из HTTPS-страницы: скрипт, изображение, стиль, iframe или API. Проверьте, существует ли ресурс по HTTPS, и измените его адрес в шаблоне, настройках CMS или источнике данных.
Для ресурса того же сайта часто подходит относительный путь /image.jpg. Для внешнего ресурса нужен работающий HTTPS-URL. Глобальная замена всех http:// в базе может повредить внешние ссылки и сериализованные значения. Сделайте резервную копию и используйте инструмент миграции, который понимает формат данных вашей CMS.
После правки загрузите страницу заново и проверьте ключевое действие: форму, оплату, изображение или встроенный виджет. Исчезновение одной строки в Console не подтверждает работу всего сценария. Проверка сертификата отдельно не обнаруживает все смешанные ресурсы страницы.
CDN: публичный сертификат и origin проверяются отдельно
Для Cloudflare Full (strict) origin должен выдавать подходящий по имени и сроку сертификат от публичного CA либо Cloudflare Origin CA. Обычный самоподписанный сертификат не равен Origin CA. Условия перечислены в документации Cloudflare.
Запишите, какой участок проверяет каждый инструмент. Успешное соединение с публичным доменом через CDN не подтверждает состояние прямого origin. И наоборот, сертификат Origin CA предназначен для соответствующего соединения с CDN и не означает доверие обычного браузера к прямому адресу сервера.
Как подтвердить исправление
- Сохраните исходный URL, код ошибки, время и проверяющий клиент.
- Запишите конкретную правку: имя сертификата, обновление, цепочка, настройка сервера или URL ресурса.
- Повторите исходный тест с тем же адресом и параметрами.
- Откройте сайт в браузере и проверьте важное пользовательское действие.
- Если есть несколько узлов или CDN, проверьте необходимые варианты и отметьте непроверенные.
- Включите контроль срока и сохраните результат повторной проверки.
SSL Checker, SSL Monitor и проверка заголовков безопасности дают разные свидетельства. Используйте их для своих задач, а цепочку доверия, отзыв, ресурсы страницы и совместимость подтверждайте отдельными проверками. В журнале пишите «не получены данные», если запрос не завершился, и «исправлено», только когда исходный симптом перестал воспроизводиться.