Как да поправите грешката NET::ERR_CERT_AUTHORITY_INVALID

NET::ERR_CERT_AUTHORITY_INVALID е грешка при TLS ръкостискане на ниво браузър, която възниква, когато сертификатът, представен от уеб сървър, не може да бъде проследен до коренен Сертифициращ орган (CA), на когото браузърът се доверява чрез вградения си доверен магазин. Браузърът прекратява връзката преди да бъдат обменени каквито и да е данни, показвайки тази грешка, за да предотврати излагане на атаки тип „човек по средата” (MITM), прихващане на данни или трафик от фалшив сървър.

Това не е козметично предупреждение. Това е твърда криптографска грешка при проверка. Браузърът е прегледал веригата от сертификати, опитал се е да валидира всяка връзка до доверен корен и е установил, че веригата е прекъсната, липсваща или криптографски невалидна. Разбирането точно къде се прекъсва тази верига е разликата между петминутно решение и часове на погрешна диагностика.

Какво всъщност предизвиква тази грешка

Повечето документации изброяват повърхностни причини. Реалната картина е по-нюансирана и всяка основна причина изисква различен път за отстраняване.

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

Самоподписаният сертификат е такъв, при който издателят и субектът са идентични — сървърът е подписал собствения си сертификат, вместо да го подпише доверен CA. Те са стандартни в локални среди за разработка, вътрешни staging сървъри и частна инфраструктура. Никой публичен доверен магазин на браузъри не ги разпознава, така че валидирането на веригата незабавно се проваля.

Критичен нюанс: Дори ако добавите самоподписан сертификат към доверения магазин на вашата ОС, някои браузъри (особено Chrome на определени платформи) използват собствен магазин за сертификати и пак ще го отхвърлят, освен ако не е изрично конфигурирано.

Изтекъл SSL/TLS сертификат

Всеки сертификат съдържа полета `notBefore` и `notAfter`, кодирани в неговата X.509 структура. След като системният часовник премине клеймото `notAfter`, сертификатът е криптографски невалиден, независимо как е бил издаден. Браузърите прилагат това стриктно.

Краен случай: Ако часовникът на вашия сървър се отклони значително напред, сертификат, който технически все още е валиден, може да изглежда изтекъл за самия сървър по време на TLS ръкостискане, причинявайки тази грешка от страна на сървъра, а не от страна на клиента.

Непълна верига от сертификати (липсващ междинен CA)

Това е най-често погрешно диагностицираната причина в производствени среди. Доверен коренен CA не подписва директно крайни сертификати. Той подписва междинни CA, които след това подписват вашия сертификат. Когато инсталирате SSL сертификат на сървър, трябва да инсталирате пълната верига: вашия краен сертификат плюс всички междинни сертификати, наредени в правилен ред.

Ако междинният сертификат липсва от TLS отговора на сървъра, повечето браузъри не могат да завършат обхождането на веригата до доверен корен. Firefox е малко по-снизходителен тук, тъй като кешира междинни сертификати от предишни сесии (AIA fetching), но Chrome и Edge ще се провалят категорично.

Как да проверите: Изпълнете `openssl s_client -connect yourdomain.com:443 -showcerts` и проверете дали се връща пълната верига.

Несъответствие на Common Name или SAN на сертификата

Ако сертификатът е издаден за `www.example.com`, но потребителят достъпва `example.com` (или поддомейн, който не е покрит от wildcard), браузърът ще покаже свързана, но различна грешка. Въпреки това, при някои конфигурации това се проявява като грешка за невалиден орган, а не като грешка за несъответствие на имена, особено при по-стари формати на сертификати, на които им липсват Subject Alternative Names (SANs).

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

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. Ако автоматичната синхронизация се провали, отворете Command Prompt като Администратор и изпълнете: `w32tm /resync /force`

macOS:

1. Отворете Системни настройки > Общи > Дата и час.
2. Активирайте Задаване на дата и час автоматично и изберете близък NTP сървър (напр. `time.apple.com`).
3. Ако проблемът продължава, изпълнете в Terminal: `sudo sntp -sS time.apple.com`

Linux (сървър или десктоп):

“`bash

sudo timedatectl set-ntp true

sudo systemctl restart systemd-timesyncd

timedatectl status

“`

След синхронизирането рестартирайте браузъра и опитайте отново.

Стъпка 2: Изчистване на кеша, бисквитките и кешираните сертификати на браузъра

Браузърите кешират HSTS (HTTP Strict Transport Security) политики и данни за сертификати. Остарял запис в кеша може да поддържа грешката дори след като основният проблем е разрешен.

Google Chrome:

1. Навигирайте до `chrome://settings/clearBrowserData`.
2. Задайте времевия диапазон на Всички времена.
3. Отметнете Бисквитки и данни на сайтове и Кеширани изображения и файлове.
4. Кликнете Изчисти данните.

За изчистване на HSTS-специфичния кеш в Chrome, навигирайте до `chrome://net-internals/#hsts`, въведете домейна под „Изтриване на политики за сигурност на домейн” и кликнете Изтрий.

Mozilla Firefox:

1. Отворете Настройки > Поверителност и сигурност.
2. Под Бисквитки и данни на сайтове, кликнете Изчисти данните.
3. Изчистете също и Кешираното уеб съдържание.

Microsoft Edge:

1. Навигирайте до `edge://settings/clearBrowserData`.
2. Изберете Всички времена и изчистете кешираните данни и бисквитките.

Стъпка 3: Идентифициране и деактивиране на SSL инспекцията

Ако сте в корпоративна мрежа или използвате продукт за сигурност на крайни точки, SSL инспекцията е основен заподозрян.

1. Кликнете върху иконата на катинар (или иконата за предупреждение) в адресната лента на браузъра.
2. Прегледайте данните на сертификата. Ако издателят е вашият антивирусен доставчик (напр. „Avast Root,” „Kaspersky Anti-Virus,” „ESET SSL Filter CA”), а не публичен CA като DigiCert, Let’s Encrypt или Sectigo, SSL инспекцията е активна.
3. В настройките на вашия антивирус или защитна стена, намерете HTTPS сканиране, SSL филтриране или Web Shield и го деактивирайте.
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 Manager, където можете да поставите сертификата, частния ключ и 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 (изпълнете Command Prompt като Администратор):

“`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 пакети.

За натоварени работни натоварвания или такива, изискващи съответствие, при които управлението на сертификати е критично, Dedicated сървъри елиминират многонаемателните променливи, които могат да усложнят SSL конфигурацията. Ако управлявате множество домейни или поддомейни, VPS контролен панел опростява внедряването на сертификати за всички тях от един интерфейс.

Матрица за решения: Кое решение се отнася за вашата ситуация

Практически контролен списък с ключови изводи

• Потвърдете дали грешката е от страна на клиента (часовник, кеш, SSL инспекция) или от страна на сървъра (изтекъл сертификат, липсващ междинен) преди да предприемете каквото и да е действие.
• Изпълнете `openssl s_client -connect domain:443 -showcerts` като първа стъпка за диагностика при всяко разследване от страна на сървъра.
• Винаги конкатенирайте пълната верига от сертификати (краен сертификат + всички междинни) в конфигурацията на вашия уеб сървър.
• Автоматизирайте подновяването на сертификати с Certbot cron задачи или еквивалентни — ръчното подновяване е гарантиран път към бъдещи прекъсвания.
• След всяка промяна на сертификата, валидирайте с 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 fetching е ненадежден), така че веригата трябва да бъде изрично конфигурирана на сървъра.

Защо тази грешка се появява само в Chrome, но не и в Firefox?

Firefox поддържа собствен магазин за доверие на сертификати и също кешира междинни сертификати от предишни успешни връзки (механизъм, наречен AIA fetching с кеширане). Chrome разчита по-стриктно на доверения магазин на ОС и веригата, представена от сървъра. Липсващ междинен сертификат, който Firefox е кеширал от предишна сесия, все пак ще накара Chrome да се провали.

Безопасно ли е да кликнете „Продължи въпреки това” при предупреждението NET::ERR_CERT_AUTHORITY_INVALID?

Само в контролирани сценарии: достъп до известен вътрешен сървър, локална среда за разработка или staging сървър, който администрирате. На всеки публично достъпен сайт — особено такива, изискващи идентификационни данни за вход, информация за плащане или лични данни — продължаването е наистина опасно. Връзката е некриптирана от гледна точка на доверие, което означава, че всеки прехващач по мрежовия път може да чете или модифицира трафика.

Как да предотвратя повторната поява на тази грешка на моя производствен сървър?

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