До основного вмісту

Помилки SSL у браузері: причини та виправлення

Безпека · 31.10.2026 · 6 хв читання
Ілюстрація до статті «Помилки SSL у браузері: причини та виправлення»

Браузер пише «З'єднання не захищене», «Сертифікат сервера не є довіреним» або показує код NET::ERR_CERT_DATE_INVALID. За такими повідомленнями стоїть одна з п'яти причин, і кожну розпізнає команда openssl за хвилину. Про те, як просто переглянути сертифікат, написано в статті Як перевірити SSL-сертифікат. Тут розбираємо причини помилки та способи виправлення.

Швидка діагностика із сервера

Спершу з'ясуйте, що саме не подобається стороні, яка перевіряє. Команда нижче підключається до сайту так, як це робить браузер, і друкує код перевірки, власника сертифіката та видавця.

openssl s_client -connect example.com:443 -servername example.com -verify_hostname example.com </dev/null 2>/dev/null | grep -E "Verify return code|subject=|issuer="

Код у рядку Verify return code вказує на причину. Зіставте його з таблицею.

ПричинаКод перевірки opensslДе проявляється
Строк дії минув10 (certificate has expired)Скрізь, в усіх відвідувачів
Самопідписаний сертифікат18 (self-signed certificate)Скрізь, в усіх відвідувачів
Немає проміжного сертифіката20 або 21 (unable to get local issuer certificate / unable to verify the first certificate)Часто лише на телефонах, у curl і в застосунках
Ім'я не збігається з доменом62 (Hostname mismatch)Скрізь, в усіх відвідувачів
Годинник на клієнті збито0 (ok) на серверіЛише в одного користувача або на одному пристрої

Причина 1: строк дії сертифіката минув

Найчастіша причина. Сертифікат діє обмежений час, і після дати завершення браузер перестає йому вірити. Дату та залишок строку покажуть дві команди: перша друкує notAfter, друга завершується з ненульовим кодом, якщо сертифікат уже прострочений.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -enddate
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -checkend 0

Виправлення: перевипустити сертифікат і перезавантажити вебсервер. Якщо ви користуєтеся Let's Encrypt, причина майже завжди в зламаному автопродовженні. Порядок налаштування описано в статті Nginx і Certbot. Переконайтеся, що продовження проходить без помилок, і перечитайте конфігурацію.

sudo certbot certificates
sudo certbot renew --dry-run
sudo systemctl reload nginx

Причина 2: сертифікат самопідписаний

Самопідписаний сертифікат випущено самим сервером, і ніхто його не засвідчив, тому в openssl ви побачите код 18, а в рядках subject та issuer будуть однакові значення. Для тестового стенда або внутрішньої служби це нормально, для публічного сайту ні: відвідувачі побачать попередження.

Виправлення для публічного сайту: отримати сертифікат у довіреному центрі сертифікації. Відмінності між видами сертифікатів описано в статті про типи сертифікатів DV, OV та EV. Для внутрішньої служби можна додати власний кореневий сертифікат до довірених на клієнтах.

Причина 3: не надіслано проміжну частину ланцюжка

Центр сертифікації підписує ваш сертифікат не кореневим ключем, а проміжним. Сервер зобов'язаний віддати клієнтові свій сертифікат разом із проміжними. Настільні браузери нерідко самі добудовують бракуючу ланку, тому на комп'ютері все відкривається, а на телефоні, у curl або в стороннім застосунку виникає помилка.

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E "^ *[0-9] s:|^ *i:|Verify return code"

У виводі нижче має бути щонайменше дві ланки: ваш сертифікат (рядок 0) і проміжний (рядок 1). Якщо ланка одна, а наприкінці стоїть код 20 або 21, ланцюжок неповний.

  • У Nginx вкажіть у ssl_certificate файл із повним ланцюжком (fullchain.pem), а не один сертифікат.
  • В Apache використайте файл ланцюжка, який видав центр сертифікації, у директиві SSLCertificateChainFile або об'єднайте ланцюжок в основний файл.
  • Після правки перезавантажте службу й повторіть команду: код має змінитися на 0.
ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

Причина 4: ім'я в сертифікаті не збігається з доменом

Сертифікат випущено на інші імена, ніж ті, за якими відкривають сайт. Типові випадки: сертифікат на example.com, а сайт відкривається як www.example.com; сертифікат старого домену після переїзду; звернення за IP-адресою. Сучасні клієнти дивляться лише на поле Subject Alternative Name, а не на Common Name.

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -ext subjectAltName

Виправлення: перевипустіть сертифікат так, щоб у ньому були всі потрібні імена, або налаштуйте редирект на те ім'я, яке покрито. Порядок встановлення описано в статті підключення SSL.

Причина 5: годинник на клієнті збито

Сертифікат діє з однієї дати по іншу. Якщо на пристрої стоїть хибна дата, браузер вважає чинний сертифікат таким, що ще не почався, або вже простроченим. Ознака: помилка лише на одному комп'ютері чи телефоні, а на сервері перевірка проходить із кодом 0. Перевірити час на самому сервері можна так.

date -u
timedatectl status
  • На клієнті ввімкніть автоматичне встановлення дати й часу та перевірте часовий пояс.
  • На сервері налаштуйте синхронізацію часу, інакше перевірки клієнтських сертифікатів і підписи токенів теж даватимуть збої.
  • Якщо помилка зникла після виправлення годинника, сертифікат ні до чого.

Часті питання

Що означає «сертифікат сервера не є довіреним»?

Клієнт не зміг побудувати ланцюжок від сертифіката сайту до кореневого сертифіката, якому він довіряє. Причини: самопідписаний сертифікат, відсутність проміжної ланки або невідомий центр сертифікації. Код перевірки в openssl s_client показує, який саме випадок перед вами, і підказує виправлення. Саме попередження браузера причину не називає.

Чому на комп'ютері сайт відкривається, а на телефоні помилка?

Найчастіше сервер не надсилає проміжний сертифікат. Настільний браузер може добудувати ланцюжок із кешу або за посиланням усередині сертифіката, а мобільні клієнти, curl і застосунки цього не роблять. Підключіть повний ланцюжок (fullchain) у налаштуваннях вебсервера й перезавантажте службу. Після цього відкрийте сайт із телефона ще раз.

Як зрозуміти, що сертифікат просто прострочений?

Виконайте openssl x509 з ключем -enddate за відповіддю сервера або перевірте код 10 у рядку Verify return code. Дата завершення в минулому означає прострочений сертифікат. Перевипустіть його та перезавантажте вебсервер. Якщо користуєтеся автопродовженням, знайдіть у журналах причину, чому воно не спрацювало, і перевірте пробний запуск продовження.

Чи можна просто натиснути «все одно перейти на сайт»?

Для чужого публічного сайту цього робити не варто: у разі підміни сертифіката трафік може перехопити третя сторона. Для власного тестового стенда припустимо, але краще випустити нормальний сертифікат або додати свій кореневий сертифікат до довірених на своїх пристроях. Натискання кнопки обходу помилку не усуває.

Чи була стаття корисною?
← Назад до бази знань Поставити питання підтримці