Як виправити помилку NET::ERR_CERT_AUTHORITY_INVALID

NET::ERR_CERT_AUTHORITY_INVALID — це збій TLS-рукостискання на рівні браузера, який виникає, коли сертифікат, наданий веб-сервером, неможливо відстежити до кореневого Центру сертифікації (CA), якому довіряє вбудоване сховище довіри браузера. Браузер розриває з’єднання до обміну будь-якими даними, відображаючи цю помилку, щоб запобігти атакам типу «людина посередині» (MITM), перехопленню даних або трафіку з підробленого сервера.

Це не косметичне попередження. Це жорстка криптографічна помилка перевірки. Браузер перевірив ланцюжок сертифікатів, спробував підтвердити кожну ланку аж до довіреного кореня та виявив, що ланцюжок порушений, відсутній або криптографічно недійсний. Точне розуміння того, де цей ланцюжок обривається, — це різниця між п’ятихвилинним виправленням і годинами неправильної діагностики.

Що насправді викликає цю помилку

Більшість документації перераховує поверхневі причини. Реальна картина більш нюансована, і кожна першопричина вимагає окремого шляху усунення.

Самопідписані сертифікати

Самопідписаний сертифікат — це сертифікат, у якому видавець і суб’єкт ідентичні: сервер підписав власний сертифікат, а не попросив довірений CA підписати його. Вони є стандартними у локальних середовищах розробки, внутрішніх тестових серверах і приватній інфраструктурі. Жодне публічне сховище довіри браузера їх не розпізнає, тому перевірка ланцюжка одразу завершується невдачею.

Важливий нюанс: Навіть якщо ви додасте самопідписаний сертифікат до сховища довіри ОС, деякі браузери (зокрема Chrome на певних платформах) використовують власне сховище сертифікатів і все одно відхилять його, якщо не налаштовано явно.

Прострочений SSL/TLS сертифікат

Кожен сертифікат містить поля `notBefore` та `notAfter`, закодовані у його структурі X.509. Як тільки системний годинник перевищує мітку часу `notAfter`, сертифікат стає криптографічно недійсним незалежно від того, як він був виданий. Браузери суворо дотримуються цього правила.

Граничний випадок: Якщо годинник вашого сервера значно відстає або поспішає, сертифікат, який технічно ще дійсний, може здаватися простроченим самому серверу під час узгодження TLS-рукостискання, що спричинить цю помилку на стороні сервера, а не клієнта.

Неповний ланцюжок сертифікатів (відсутній проміжний CA)

Це найчастіше неправильно діагностована причина у виробничих середовищах. Довірений кореневий CA не підписує кінцеві сертифікати безпосередньо. Він підписує проміжні CA, які потім підписують ваш сертифікат. Коли ви встановлюєте SSL-сертифікат на сервер, ви повинні встановити повний ланцюжок: ваш кінцевий сертифікат плюс усі проміжні сертифікати, об’єднані по порядку.

Якщо проміжний сертифікат відсутній у TLS-відповіді сервера, більшість браузерів не може завершити перехід ланцюжка до довіреного кореня. Firefox дещо поблажливіший у цьому відношенні, оскільки кешує проміжні сертифікати з попередніх сесій (отримання AIA), але Chrome та Edge завершаться жорсткою помилкою.

Як перевірити: Запустіть `openssl s_client -connect yourdomain.com:443 -showcerts` та перевірте, чи повертається повний ланцюжок.

Невідповідність Common Name або SAN сертифіката

Якщо сертифікат був виданий для `www.example.com`, але користувач звертається до `example.com` (або субдомену, не охопленого символом підстановки), браузер видасть пов’язану, але окрему помилку. Однак у деяких конфігураціях це проявляється як помилка недійсного центру сертифікації, а не помилка невідповідності імені, особливо зі старими форматами сертифікатів, у яких відсутні Subject Alternative Names (SAN).

Розбіжність годинника на стороні клієнта

TLS-сертифікати обмежені часом. Якщо годинник клієнтської машини встановлено на дату до поля `notBefore` сертифіката або після його поля `notAfter`, браузер відхилить його. Це надзвичайно поширено на віртуальних машинах, щойно розгорнутих серверах або машинах, які були вимкнені протягом тривалого часу без синхронізації NTP.

SSL-інспекція програмним забезпеченням безпеки

Корпоративні брандмауери, засоби захисту кінцевих точок і деякі антивірусні продукти виконують SSL/TLS-інспекцію (також звану перехопленням HTTPS). Вони розривають TLS-з’єднання на рівні пристрою безпеки, перевіряють відкритий текст, а потім повторно шифрують його за допомогою динамічно згенерованого сертифіката, підписаного власним CA пристрою. Якщо цей CA пристрою відсутній у сховищі довіри браузера, кожен HTTPS-сайт буде викликати цю помилку.

Застаріле сховище кореневих сертифікатів

На старих операційних системах (Windows 7 без оновлень, застарілі дистрибутиви Linux) системний пакет кореневих CA може не містити новіших кореневих сертифікатів. Наприклад, ISRG Root X1 від Let’s Encrypt спричинив масові помилки на Android 7 і нижче та на непатчених системах Windows, коли перехресний підпис DST Root CA X3 закінчився у вересні 2021 року.

Порівняння першопричин

Покрокові виправлення

Крок 1: Синхронізуйте системну дату та час

Це найшвидше виправлення, коли помилка раптово з’являється на машині, яка раніше працювала нормально.

Windows:

1. Відкрийте Параметри > Час і мова > Дата і час.
2. Увімкніть Встановлювати час автоматично та Встановлювати часовий пояс автоматично.
3. Натисніть Синхронізувати зараз у розділі «Синхронізація годинника».
4. Якщо автоматична синхронізація не вдається, відкрийте командний рядок від імені адміністратора та виконайте: `w32tm /resync /force`

macOS:

1. Відкрийте Системні параметри > Основні > Дата і час.
2. Увімкніть Встановлювати час і дату автоматично та виберіть найближчий NTP-сервер (наприклад, `time.apple.com`).
3. Якщо проблема не зникає, виконайте у Терміналі: `sudo sntp -sS time.apple.com`

Linux (сервер або робочий стіл):

“`bash

sudo timedatectl set-ntp true

sudo systemctl restart systemd-timesyncd

timedatectl status

“`

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

Крок 2: Очистіть кеш браузера, файли cookie та кешовані сертифікати

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

Google Chrome:

1. Перейдіть до `chrome://settings/clearBrowserData`.
2. Встановіть часовий діапазон на Весь час.
3. Позначте Файли cookie та інші дані сайтів та Кешовані зображення та файли.
4. Натисніть Видалити дані.

Для очищення кешу HSTS у Chrome перейдіть до `chrome://net-internals/#hsts`, введіть домен у розділі «Видалити політики безпеки домену» та натисніть Видалити.

Mozilla Firefox:

1. Відкрийте Налаштування > Конфіденційність і захист.
2. У розділі Файли cookie та дані сайтів натисніть Очистити дані.
3. Також очистіть Кешований веб-вміст.

Microsoft Edge:

1. Перейдіть до `edge://settings/clearBrowserData`.
2. Виберіть Весь час та очистіть кешовані дані та файли cookie.

Крок 3: Визначте та вимкніть SSL-інспекцію

Якщо ви перебуваєте в корпоративній мережі або використовуєте продукт для захисту кінцевих точок, SSL-інспекція є головним підозрюваним.

1. Натисніть на значок замка (або значок попередження) в адресному рядку браузера.
2. Перевірте деталі сертифіката. Якщо видавцем є ваш антивірусний постачальник (наприклад, «Avast Root», «Kaspersky Anti-Virus», «ESET SSL Filter CA»), а не публічний CA, як DigiCert, Let’s Encrypt або Sectigo, то SSL-інспекція активна.
3. У налаштуваннях антивіруса або брандмауера знайдіть Сканування HTTPS, Фільтрація SSL або Веб-щит та вимкніть це.
4. Або додайте кореневий CA-сертифікат пристрою до сховища довіри браузера.

Не вимикайте програмне забезпечення безпеки назавжди. Увімкніть його знову після тестування або налаштуйте виключення для конкретних довірених доменів.

Крок 4: Перевірте та відновіть ланцюжок сертифікатів на стороні сервера (для адміністраторів серверів)

Це правильне виправлення для виробничих веб-сайтів, де відвідувачі бачать помилку.

Діагностика ланцюжка:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts 2>/dev/null | openssl x509 -noout -text | grep -E "Issuer:|Subject:"

“`

Або використайте повну перевірку ланцюжка:

“`bash

openssl s_client -connect yourdomain.com:443 -showcerts

“`

Порахуйте повернуті сертифікати. Ви повинні побачити принаймні два (кінцевий + проміжний). Якщо з’являється лише один, проміжний відсутній.

Виправлення в Apache (`httpd.conf` або файл віртуального хоста):

“`apache

SSLCertificateFile /etc/ssl/certs/yourdomain.crt

SSLCertificateKeyFile /etc/ssl/private/yourdomain.key

SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

“`

Виправлення в Nginx (`nginx.conf` або блок сервера):

Nginx вимагає об’єднання повного ланцюжка в один файл:

“`bash

cat yourdomain.crt intermediate.crt > fullchain.pem

“`

Потім посилайтеся на нього:

“`nginx

ssl_certificate /etc/ssl/certs/fullchain.pem;

ssl_certificate_key /etc/ssl/private/yourdomain.key;

“`

Після редагування завжди перевіряйте конфігурацію перед перезапуском:

“`bash

Apache

apachectl configtest

Nginx

nginx -t

“`

Потім перезавантажте службу:

“`bash

sudo systemctl reload apache2

or

sudo systemctl reload nginx

“`

Якщо ви використовуєте керований хостинг, VPS з cPanel надає графічний інтерфейс у розділі Менеджер SSL/TLS, де ви можете вставити сертифікат, приватний ключ та пакет CA безпосередньо, не торкаючись файлів конфігурації вручну.

Крок 5: Поновіть або замініть прострочений сертифікат

Якщо сертифікат прострочений, жодного обхідного рішення на стороні клієнта не існує. Сервер повинен надати дійсний сертифікат.

Для Let’s Encrypt (Certbot):

“`bash

sudo certbot renew –dry-run

sudo certbot renew

sudo systemctl reload nginx # or apache2

“`

Для сертифікатів, якими керують вручну: Отримайте новий сертифікат від вашого CA, завантажте його через панель керування та переконайтеся, що ланцюжок нового сертифіката є повним. Якщо вам потрібен довірений сертифікат для виробничого домену, SSL-сертифікати від визнаного CA повністю усувають проблему самопідписаних сертифікатів.

Автоматизуйте поновлення: Сертифікати Let’s Encrypt закінчуються кожні 90 днів. Додайте завдання cron або використовуйте таймери systemd для автоматизації поновлення:

“`bash

0 3 * * * /usr/bin/certbot renew –quiet –post-hook "systemctl reload nginx"

“`

Крок 6: Довіряйте самопідписаному сертифікату для внутрішнього використання

Якщо ви запускаєте внутрішні інструменти, сервер розробки або службу приватної мережі, де заміна сертифіката неможлива, ви можете додати самопідписаний сертифікат до сховища довіри ОС.

Windows:

1. Експортуйте сертифікат з браузера (натисніть на попередження > Сертифікат > Деталі > Копіювати у файл).
2. Відкрийте `certmgr.msc`.
3. Перейдіть до Довірені кореневі центри сертифікації > Сертифікати.
4. Клацніть правою кнопкою миші > Усі завдання > Імпорт та імпортуйте сертифікат.

macOS:

“`bash

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.crt

“`

Linux (Debian/Ubuntu):

“`bash

sudo cp cert.crt /usr/local/share/ca-certificates/

sudo update-ca-certificates

“`

Важливо: Chrome на Linux та Windows використовує сховище довіри ОС для більшості цілей, але також підтримує власну базу даних NSS. Якщо Chrome все одно відхиляє сертифікат після оновлення сховища ОС, імпортуйте його безпосередньо через `chrome://settings/certificates`.

Крок 7: Оновіть браузер та операційну систему

Застарілий браузер може не мати новіших кореневих CA-сертифікатів або не підтримувати поточні версії протоколу TLS (мінімум TLS 1.2 тепер є обов’язковим; TLS 1.3 є кращим варіантом).

Chrome: Перейдіть до `chrome://settings/help`. Chrome оновлюється автоматично; якщо оновлення очікує, воно встановиться тут.

Firefox: Перейдіть до Довідка > Про Firefox. Firefox перевірить наявність оновлень та застосує їх.

Операційна система: У Windows переконайтеся, що Windows Update актуальний. На серверах Linux виконайте:

“`bash

sudo apt update && sudo apt upgrade ca-certificates openssl

“`

Це особливо важливо для серверів, що працюють на старих дистрибутивах, де пакет CA (пакет `ca-certificates`) не оновлювався для включення новіших кореневих CA.

Крок 8: Скиньте мережевий стек та очистіть DNS

Неправильні конфігурації мережі, пошкоджені кеші DNS або застарілі записи Winsock іноді можуть сприяти збоям узгодження TLS.

Windows (запустіть командний рядок від імені адміністратора):

“`cmd

netsh int ip reset

netsh winsock reset

ipconfig /release

ipconfig /renew

ipconfig /flushdns

“`

Перезапустіть машину після виконання цих команд.

macOS:

“`bash

sudo dscacheutil -flushcache

sudo killall -HUP mDNSResponder

“`

Linux:

“`bash

sudo systemd-resolve –flush-caches

or for systems using nscd:

sudo service nscd restart

“`

Крок 9: Обійдіть попередження (лише для тестування)

Це суто діагностичний інструмент, а не рішення. Використовуйте його лише для підтвердження того, що помилка пов’язана із сертифікатом, а не з мережею чи додатком, або при доступі до відомого безпечного внутрішнього сервера під час розробки.

Chrome: Натисніть Додатково на сторінці помилки, потім Перейти на [домен] (небезпечно).

Firefox: Натисніть Додатково, потім Прийняти ризик і продовжити.

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

Перевірка виправлення

Після застосування будь-яких змін на стороні сервера перевірте результат за допомогою цих інструментів, перш ніж оголошувати проблему вирішеною:

• SSL Labs SSL Test (`ssllabs.com/ssltest/`): Надає повний аналіз ланцюжка, оцінку підтримки протоколів та виявляє конкретні слабкі місця конфігурації.
• `openssl s_client`: Перевірка через командний рядок, яка показує саме те, що сервер надає під час TLS-рукостискання.
• `curl -vI https://yourdomain.com`: Швидка перевірка, що показує деталі TLS-рукостискання та результат перевірки сертифіката.
• `whatsmychaincert.com`: Спеціально діагностує відсутні проміжні сертифікати.

Вибір правильної хостингової інфраструктури для запобігання повторенню

Багато помилок сертифікатів виникають через обмеження інфраструктури, а не через помилки адміністратора. Середовища спільного хостингу іноді обмежують налаштування ланцюжків сертифікатів або обмежують доступ до файлів конфігурації веб-сервера. Якщо ви постійно стикаєтеся з проблемами ланцюжка або поновлення, перехід на середовище VPS Хостинг надає вам повний контроль над вашим TLS-стеком — включаючи можливість безпосередньо налаштовувати Nginx або Apache, автоматизувати поновлення Certbot та встановлювати власні пакети CA.

Для навантажень з високим трафіком або чутливих до відповідності вимогам, де управління сертифікатами є критичним, Виділені сервери усувають змінні мультиорендного середовища, які можуть ускладнити конфігурацію SSL. Якщо ви керуєте кількома доменами або субдоменами, Панель керування VPS спрощує розгортання сертифікатів для всіх них з єдиного інтерфейсу.

Матриця рішень: яке виправлення підходить для вашої ситуації

Практичний контрольний список ключових висновків

• Перш ніж вживати будь-яких заходів, визначте, чи помилка є на стороні клієнта (годинник, кеш, SSL-інспекція) або на стороні сервера (прострочений сертифікат, відсутній проміжний).
• Запустіть `openssl s_client -connect domain:443 -showcerts` як перший діагностичний крок для будь-якого розслідування на стороні сервера.
• Завжди об’єднуйте повний ланцюжок сертифікатів (кінцевий + усі проміжні) у конфігурації вашого веб-сервера.
• Автоматизуйте поновлення сертифікатів за допомогою завдань cron Certbot або аналогів — ручне поновлення є гарантованим шляхом до майбутніх збоїв.
• Після будь-якої зміни сертифіката перевіряйте за допомогою SSL Labs перед закриттям інциденту.
• Ніколи не вимикайте SSL-сканування антивіруса назавжди; натомість налаштуйте виключення або правильно встановіть CA-сертифікат проксі.
• На серверах Linux підтримуйте пакети `ca-certificates` та `openssl` оновленими, щоб сховище кореневих сертифікатів відображало поточні довірені CA.
• Використовуйте `chrome://net-internals/#hsts` для очищення записів кешу HSTS, коли сертифікат домену було законно змінено, а Chrome все одно відмовляється підключатися.

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

У чому різниця між NET::ERR_CERT_AUTHORITY_INVALID та NET::ERR_CERT_COMMON_NAME_INVALID?

`ERR_CERT_AUTHORITY_INVALID` означає, що видавцю сертифіката не довіряють — ланцюжок не може бути перевірений. `ERR_CERT_COMMON_NAME_INVALID` означає, що сертифікат від довіреного CA, але був виданий для іншого домену, ніж той, до якого здійснюється доступ. Вони вимагають різних виправлень: перший вимагає нового сертифіката від довіреного CA або відновлення ланцюжка; другий вимагає перевипуску сертифіката з правильними Subject Alternative Names.

Чи може NET::ERR_CERT_AUTHORITY_INVALID з’являтися навіть з дійсним платним SSL-сертифікатом?

Так. Платний сертифікат від довіреного CA все одно викличе цю помилку, якщо проміжний сертифікат не включений у TLS-відповідь сервера. Браузер не завжди може автоматично отримати відсутні проміжні сертифікати (отримання AIA є ненадійним), тому ланцюжок повинен бути явно налаштований на сервері.

Чому ця помилка з’являється лише в Chrome, але не у Firefox?

Firefox підтримує власне сховище довіри сертифікатів і також кешує проміжні сертифікати з попередніх успішних з’єднань (механізм, що називається отриманням AIA з кешуванням). Chrome більш суворо покладається на сховище довіри ОС та ланцюжок, наданий сервером. Відсутній проміжний сертифікат, який Firefox кешував з попередньої сесії, все одно призведе до збою Chrome.

Чи безпечно натискати «Продовжити все одно» на попередженні NET::ERR_CERT_AUTHORITY_INVALID?

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

Як запобігти повторенню цієї помилки на моєму виробничому сервері?

Автоматизуйте поновлення сертифікатів (Certbot із завданням cron або таймером systemd), відстежуйте термін дії сертифікатів за допомогою зовнішнього інструменту (UptimeRobot, Zabbix або `ssl-cert-check`), завжди розгортайте повний ланцюжок сертифікатів та підтримуйте активну синхронізацію NTP вашого сервера. Для середовищ, де ручне управління схильне до помилок, розгляньте хостингову платформу з інтегрованим управлінням сертифікатами — VPS з cPanel автоматично обробляє поновлення AutoSSL для всіх розміщених доменів.