Как исправить ошибку «Этот сайт не может обеспечить безопасное соединение»

Ошибка «This site can’t provide a secure connection» означает, что браузеру не удалось завершить TLS-рукопожатие с целевым сервером. Попытка подключения была прервана до того, как удалось установить зашифрованный канал, в результате чего браузер не смог проверить подлинность сервера или согласовать набор шифров.

Эта ошибка возникает в Chrome, Firefox, Edge и Safari и почти всегда сопровождается конкретным кодом ошибки — чаще всего ERR_SSL_PROTOCOL_ERROR, ERR_SSL_VERSION_OR_CIPHER_MISMATCH или SSL_ERROR_HANDSHAKE_FAILURE_ALERT. Каждый код указывает на отдельный уровень сбоя: конфигурацию сертификата сервера, TLS-стек клиента или сетевой путь между ними. Определение ответственного уровня до изменения каких-либо настроек сэкономит вам значительное время.

Что происходит во время TLS-рукопожатия

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

1. Браузер отправляет сообщение ClientHello, сообщая о поддерживаемых версиях TLS и наборах шифров.
2. Сервер отвечает сообщением ServerHello, выбирая версию протокола и шифр, а затем предоставляет цепочку сертификатов.
3. Браузер проверяет сертификат по доверенным корневым центрам сертификации (CA), проверяет срок действия, убеждается, что домен соответствует полю Subject Alternative Name (SAN), и подтверждает, что сертификат не был отозван (через OCSP или CRL).
4. Обе стороны формируют сеансовые ключи и начинают зашифрованный обмен данными.

Сбой на любом из этих четырёх этапов приводит к сообщению «can’t provide a secure connection». Код ошибки в панели сведений браузера точно указывает, на каком шаге произошёл сбой.

Первопричины, соответствующие кодам ошибок

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

Исправления на стороне клиента

1. Проверьте сертификат перед изменением каких-либо настроек

Нажмите на значок замка (или значок предупреждения) в адресной строке и выберите Соединение защищено > Сертификат действителен. Проверьте:

• Срок действия: дата «Not After» должна быть в будущем.
• Кому выдан: домен в поле SAN сертификата должен точно совпадать с URL, включая поддомены.
• Кем выдан: цепочка CA должна заканчиваться корневым CA, которому доверяет ваша ОС.

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

2. Синхронизируйте системную дату и время

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

Windows:

w32tm /resync /force

Либо щёлкните правой кнопкой мыши по системным часам, выберите Настройка даты и времени и включите Устанавливать время автоматически с помощью службы времени Windows.

Linux (systemd):

timedatectl set-ntp true
timedatectl status

macOS: Откройте Системные настройки > Основные > Дата и время и включите Устанавливать время и дату автоматически.

После синхронизации перезапустите браузер и проверьте снова.

3. Очистите SSL-состояние и кэш браузера

Браузеры кэшируют результаты проверки сертификатов и политики HSTS (HTTP Strict Transport Security). Устаревшая запись в кэше может блокировать доступ даже после устранения проблемы с сертификатом на стороне сервера.

Chrome — очистка данных браузера:

Перейдите по адресу chrome://settings/clearBrowserData, выберите За всё время, отметьте Файлы cookie и другие данные сайтов и Кэшированные изображения и файлы, затем нажмите Удалить данные.

Chrome — очистка записи HSTS для конкретного домена:

Перейдите по адресу chrome://net-internals/#hsts, введите домен в поле Удалить политики безопасности домена и нажмите Удалить. Это особенно полезно, когда домен ранее работал только по HTTPS, а теперь настроен некорректно.

Windows — очистка SSL-состояния на уровне ОС:

Control Panel > Network and Internet > Internet Options > Content tab > Clear SSL State

Это очищает кэш сертификатов, используемый Internet Explorer, Edge (устаревшим) и некоторыми приложениями Windows.

Firefox: Перейдите по адресу about:preferences#privacy, прокрутите до раздела Куки и данные сайтов и нажмите Удалить данные.

4. Отключите HTTPS-инспекцию антивируса

Продукты безопасности таких производителей, как Avast, AVG, Kaspersky, ESET и Bitdefender, выполняют перехват SSL/TLS — они действуют как локальный прокси-посредник, переподписывая сертификаты собственным корневым CA. Когда их корневой CA не установлен должным образом в хранилище доверия браузера или когда модуль перехвата работает некорректно, все HTTPS-соединения завершаются ошибкой.

Чтобы проверить, является ли это причиной:

1. Временно отключите функцию Веб-щит, HTTPS-сканирование или SSL-фильтрацию в настройках антивируса.
2. Перезагрузите проблемную страницу.
3. Если ошибка исчезла, виновник — антивирус.

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

5. Обновите браузер

Современный TLS требует поддержки браузером как минимум TLS 1.2, а TLS 1.3 — для оптимальной безопасности. Браузеры старше примерно Chrome 70, Firefox 63 или Edge 79 могут не поддерживать TLS 1.3 или иметь известные ошибки рукопожатия.

Chrome:

Перейдите по адресу chrome://settings/help. Chrome автоматически проверяет наличие обновлений и устанавливает их при перезапуске.

Firefox:

Перейдите по адресу about:support, затем выберите Проверить наличие обновлений в меню «Справка».

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

6. Проверьте настройки протокола TLS в браузере

Chrome и Edge (на основе Chromium):

Эти браузеры не предоставляют переключатели версий TLS в интерфейсе начиная с Chrome 84. TLS 1.0 и 1.1 отключены навсегда. Если сайт требует TLS 1.0 или 1.1, сайт необходимо обновить — обходного пути на стороне клиента нет, и его не должно быть.

Для проверки экспериментальных флагов TLS перейдите по адресу chrome://flags и выполните поиск по слову TLS. В большинстве производственных сборок никаких применимых флагов не появится.

Firefox:

Перейдите по адресу about:config и выполните поиск security.tls.version.min. Значение должно быть 3 (соответствует TLS 1.2). Установка значения 1 или 2 для работы с неисправным сервером является угрозой безопасности и должна выполняться только в изолированных тестовых средах.

Internet Explorer / устаревший Edge:

Перейдите в Свойства браузера > Дополнительно > Безопасность и убедитесь, что установлены флажки Использовать TLS 1.2 и Использовать TLS 1.3. Снимите флажки Использовать SSL 3.0, Использовать TLS 1.0 и Использовать TLS 1.1.

7. Отключите или проверьте расширения браузера

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

Перейдите по адресу chrome://extensions/ и отключите все расширения. Перезагрузите проблемную страницу. Если ошибка устранена, включайте расширения по одному, перезагружая страницу после каждого, пока не будет найдено проблемное расширение.

8. Смените DNS-резолвер

DNS не влияет напрямую на TLS, однако DNS-резолвер, возвращающий неверные IP-адреса (из-за отравления кэша, фильтрации или вмешательства провайдера), может направить браузер на сервер, предоставляющий сертификат для неправильного домена, что вызовет ошибку ERR_CERT_COMMON_NAME_INVALID.

Переключение на публичный резолвер устраняет манипуляции с DNS на уровне провайдера:

Windows — смена DNS через PowerShell:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses ("1.1.1.1","1.0.0.1")

Замените "Ethernet" на фактическое имя вашего интерфейса (используйте Get-NetAdapter для отображения списка интерфейсов).

Linux:

sudo nano /etc/resolv.conf

Добавьте:

nameserver 1.1.1.1
nameserver 8.8.8.8

Рекомендуемые публичные резолверы:

9. Сброс сетевого стека (Windows)

Повреждённый каталог Winsock или стек TCP/IP могут вызывать периодические сбои TLS, которые кажутся не связанными с сертификатами. Выполните следующие команды от имени администратора:

netsh int ip reset
netsh winsock reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

После выполнения всех пяти команд перезагрузите компьютер. Не пропускайте перезагрузку — netsh winsock reset в частности требует перезапуска для вступления в силу.

Исправления на стороне сервера для администраторов

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

Истёкший или неправильно настроенный SSL-сертификат

Истёкший сертификат — наиболее распространённая причина этой ошибки на уровне сервера. Если вы запускаете сайт в среде VPS Hosting, обновление сертификата должно быть автоматизировано.

Проверка срока действия сертификата из командной строки:

echo | openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | openssl x509 -noout -dates

Автоматизация обновления с помощью Certbot (Let’s Encrypt):

sudo certbot renew --dry-run

Добавьте задание cron или таймер systemd для запуска certbot renew дважды в день — сертификаты Let’s Encrypt истекают каждые 90 дней, а Certbot обновляет их только при наличии менее 30 дней до истечения срока.

0 0,12 * * * root certbot renew --quiet

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

Неполная цепочка сертификатов

Очень распространённая ошибка конфигурации: сервер предоставляет только конечный сертификат без промежуточных сертификатов CA. Браузер не может построить путь доверия до корневого CA, которому он доверяет, что приводит к ошибке ERR_CERT_AUTHORITY_INVALID.

Диагностика с помощью SSL Labs:

Проверьте свой домен через SSL Labs Server Test (внешний инструмент). Проблема с цепочкой будет выявлена немедленно.

Исправление в Nginx:

Директива ssl_certificate должна указывать на файл, содержащий полную цепочку — ваш сертификат, за которым следуют все промежуточные сертификаты:

cat your_domain.crt intermediate.crt > fullchain.crt

ssl_certificate /etc/nginx/ssl/fullchain.crt;
ssl_certificate_key /etc/nginx/ssl/your_domain.key;

Исправление в Apache:

SSLCertificateFile /etc/apache2/ssl/your_domain.crt
SSLCertificateKeyFile /etc/apache2/ssl/your_domain.key
SSLCertificateChainFile /etc/apache2/ssl/intermediate.crt

Устаревшие версии TLS и слабые наборы шифров

Браузеры удалили поддержку TLS 1.0 и TLS 1.1. Если ваш сервер предлагает только эти версии протокола, современные браузеры полностью откажутся от подключения.

Рекомендуемая конфигурация TLS для Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1d;
ssl_stapling on;
ssl_stapling_verify on;

Рекомендуемая конфигурация TLS для Apache:

SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
SSLHonorCipherOrder off
SSLSessionTickets off

После изменения конфигурации сервера выполните проверку с помощью:

openssl s_client -connect yourdomain.com:443 -tls1_2
openssl s_client -connect yourdomain.com:443 -tls1_3

Несоответствие домена в сертификате

Если ваш сертификат охватывает www.example.com, а пользователи обращаются к example.com (или наоборот), браузер сообщит о несоответствии домена. Правильное решение — выпустить сертификат с обоими именами в поле SAN или использовать wildcard-сертификат (*.example.com).

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

Блокировка смешанного контента

Страница, загруженная по HTTPS, которая ссылается на ресурсы HTTP (изображения, скрипты, таблицы стилей), вызывает предупреждения о смешанном контенте. Хотя это не приводит напрямую к ошибке «can’t provide a secure connection», это может вызвать частичные сбои страницы, которые ошибочно диагностируются как ошибки TLS.

Проверьте смешанный контент с помощью:

curl -s https://yourdomain.com | grep -Eo 'src="http://[^"]*"|href="http://[^"]*"'

Сравнение причин на стороне клиента и сервера

Особенности хостинговой среды

Хостинговая среда, которую вы используете, напрямую влияет на то, насколько легко вы можете устранить проблемы TLS на стороне сервера.

На виртуальном веб-хостинге управление сертификатами обычно осуществляется через панель управления. Большинство современных платформ виртуального хостинга включают бесплатную интеграцию с Let’s Encrypt, однако у вас ограниченный контроль над общесерверными настройками протокола TLS.

На VPS с cPanel вы получаете доступ к AutoSSL для автоматической выдачи сертификатов и можете напрямую настраивать параметры TLS Apache или Nginx. Это рекомендуемая среда для сайтов, где важна точность конфигурации TLS.

На физических выделенных серверах вы имеете полный контроль над всем стеком TLS — версией OpenSSL, выбором набора шифров, OCSP-сшиванием, предварительной загрузкой HSTS и закреплением сертификатов — но также несёте полную ответственность за поддержание актуальности конфигурации.

Практический контрольный список

Используйте этот контрольный список для систематической диагностики ошибки, а не для случайного применения исправлений:

• Ошибка появляется на всех HTTPS-сайтах или только на одном?
• На всех сайтах: сосредоточьтесь на системных часах, HTTPS-сканировании антивируса, обновлении браузера, хранилище корневых CA ОС.
• На одном сайте: проблема почти наверняка на стороне сервера.

• Что говорит конкретный код ошибки?
• ERR_CERT_DATE_INVALID: сначала проверьте системные часы, затем срок действия сертификата.
• ERR_CERT_AUTHORITY_INVALID: проверьте полноту цепочки сертификатов.
• ERR_SSL_VERSION_OR_CIPHER_MISMATCH: сервер использует устаревший TLS или неподдерживаемые шифры.
• ERR_CERT_COMMON_NAME_INVALID: SAN сертификата не совпадает с доменом.

• Ошибка исчезает в другой сети?
• Да: причина — брандмауэр, прокси или TLS-инспекция на уровне провайдера.

• Ошибка исчезает при отключённом антивирусе?
• Да: настройте исключение для домена в настройках HTTPS-сканирования антивируса.

• Вы являетесь администратором сервера?
• Запустите диагностику openssl s_client и тест SSL Labs перед изменением каких-либо файлов конфигурации.
• Автоматизируйте обновление сертификата сразу после устранения текущей проблемы.

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

Почему ошибка «This site can’t provide a secure connection» появляется только на одном сайте?

Когда ошибка изолирована на одном домене, первопричина почти всегда на стороне сервера: истёкший сертификат, неполная цепочка сертификатов, несоответствие имени домена в поле SAN сертификата или настройка сервера на использование только устаревших версий TLS (1.0 или 1.1), которые современные браузеры больше не принимают.

Может ли VPN вызвать эту ошибку?

Да. Некоторые VPN-клиенты направляют DNS-запросы через собственные резолверы или выполняют инспекцию трафика, которая мешает TLS-рукопожатиям. Если ошибка появляется только при активном VPN, отключите функцию «раздельного туннелирования» или «SSL-инспекции» VPN либо добавьте затронутый домен в список исключений.

Всегда ли очистка кэша устраняет SSL-ошибки?

Нет. Очистка кэша устраняет ошибки, вызванные устаревшими политиками HSTS или кэшированными недействительными ответами сертификатов. Она не влияет на проблемы с сертификатами на стороне сервера, неверное системное время или перехват антивирусом. Используйте очистку кэша как первый шаг, а не как универсальное решение.

Как проверить правильность настройки SSL-сертификата сервера без браузера?

Используйте OpenSSL с любого компьютера с сетевым доступом:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com

В выводе отображается полная цепочка сертификатов, согласованная версия TLS, выбранный набор шифров и любые ошибки проверки. Это наиболее надёжный метод диагностики проблем TLS на стороне сервера.

В чём разница между ERR_SSL_PROTOCOL_ERROR и ERR_SSL_VERSION_OR_CIPHER_MISMATCH?

ERR_SSL_PROTOCOL_ERROR означает, что сервер отправил ответ, не соответствующий ни одному известному формату TLS-записи — это часто вызвано тем, что сервер отправляет HTTP-ответ на порту 443, неправильно настроенным балансировщиком нагрузки или брандмауэром, прерывающим соединение в процессе рукопожатия. ERR_SSL_VERSION_OR_CIPHER_MISMATCH означает, что рукопожатие началось корректно, но клиент и сервер не смогли договориться о взаимно поддерживаемой версии TLS или наборе шифров, как правило, потому что сервер поддерживает только устаревшие протоколы.