Як виправити помилку «Цей сайт не може забезпечити безпечне з’єднання»

Помилка "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 Time.

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, прокрутіть до Файли cookie та дані сайтів та натисніть Очистити дані.

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 / Legacy 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 Хостинг, поновлення сертифіката має бути автоматизованим.

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

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 або набір шифрів, зазвичай тому, що сервер підтримує лише застарілі протоколи.