ERR_CERT_AUTHORITY_INVALID: что значит и как исправить ошибку

ERR_CERT_AUTHORITY_INVALID означает, что браузер не доверяет удостоверяющему центру (CA), выпустившему SSL-сертификат сайта: цепочка не сходится к корню из его хранилища. Причины — самоподписанный сертификат, неполная цепочка, российский или корпоративный CA, антивирус с проверкой HTTPS, сбитые часы. Посетителю чаще всего помогают часы и антивирус, владельцу — fullchain и сертификат доверенного CA.

Ниже — как браузер строит цепочку доверия, шесть типовых причин NET::ERR_CERT_AUTHORITY_INVALID, диагностика через openssl, отдельные инструкции для владельца сайта и для посетителя, очистка SSL-кэша в Windows, Chrome и Яндекс Браузере, ошибка «Невозможно установить безопасное соединение» (включая сайты с шифрованием по ГОСТ) и сертификаты НУЦ Минцифры на Госуслугах, в банках и на других российских ресурсах.

Что значит NET::ERR_CERT_AUTHORITY_INVALID

При открытии HTTPS-сайта браузер проверяет цепочку доверия: сертификат сайта должен быть подписан промежуточным сертификатом (intermediate), а тот — корневым сертификатом из хранилища доверенных корней. Chrome с 2022 года использует собственное хранилище в рамках Chrome Root Program: если цепочка не сходится к корню из этого списка (или к корню, который администратор сам добавил в системное хранилище), соединение помечается как небезопасное и вместо страницы показывается ошибка ERR_CERT_AUTHORITY_INVALID. Сам протокол и роль сертификатов в TLS подробно описаны в документации MDN по Transport Layer Security.

На экране это выглядит как «Ваше подключение не защищено» с красным замком; сам код ошибки виден, если нажать «Дополнительные» (в некоторых версиях — «Подробнее»). Код ошибки NET::ERR_CERT_AUTHORITY_INVALID и ERR_CERT_AUTHORITY_INVALID — одно и то же: префикс NET:: просто указывает, что ошибка сетевого уровня. Кнопка «Перезагрузить» на странице ошибки обычно ничего не меняет: браузер снова получит тот же сертификат и снова ему не поверит — пока не устранена причина.

В других браузерах ошибка выглядит иначе, но механика та же: Firefox показывает SEC_ERROR_UNKNOWN_ISSUER или MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT, Safari — «Это соединение не является частным», Яндекс Браузер — «Невозможно установить безопасное соединение» или предупреждение о недоверенном сертификате. Важно: ошибка говорит о недоверии к издателю сертификата, а не об истёкшем сроке (для этого есть ERR_CERT_DATE_INVALID) и не о несовпадении имени (ERR_CERT_COMMON_NAME_INVALID, о ней — ниже отдельным разделом).

Браузер	Как выглядит ошибка доверия к CA	Где посмотреть издателя
Chrome, Edge, Opera	«Ваше подключение не защищено», код NET::ERR_CERT_AUTHORITY_INVALID	Значок слева от адреса → «Сертификат недействителен»
Яндекс Браузер	«Невозможно установить безопасное соединение» или предупреждение о недоверенном сертификате, код в подробностях	Значок слева от адреса → информация о сертификате
Firefox	«Предупреждение: вероятная угроза безопасности», SEC_ERROR_UNKNOWN_ISSUER	«Дополнительно» → «Просмотреть сертификат»
Safari	«Это соединение не является частным»	«Показать подробности» → «Просмотреть сертификат»

Причины ошибки ERR_CERT_AUTHORITY_INVALID

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

Сертификат подписан не удостоверяющим центром, а собственным ключом сервера. Такие сертификаты нормальны для локальной разработки и внутренних панелей (роутеры, NAS, dev-стенды), но публичный браузер им не доверяет по определению: издателя нет ни в одном хранилище корней. Подробно о том, где self-signed уместен и чем его заменить, — в статье про самоподписанные сертификаты.

Неполная цепочка: не отдан промежуточный сертификат

Самая частая причина на боевых сайтах. Сервер отдаёт только конечный (leaf) сертификат без промежуточного, и браузер не может достроить цепочку до корня. Коварство в том, что Chrome на десктопе часто скачивает недостающий intermediate сам (механизм AIA fetching), поэтому «у меня всё работает», а Firefox, мобильные браузеры и API-клиенты вроде curl падают с ошибкой. Разбор этого сценария — в статье о неполной цепочке сертификатов.

Недоверенный или неизвестный удостоверяющий центр

Сертификат выпущен CA, корня которого нет в хранилище браузера. Сюда попадают внутренние корпоративные CA, отозванные из доверия центры и российские удостоверяющие центры: корень Russian Trusted Root CA от Минцифры не входит в хранилища Chrome, Firefox и Safari, поэтому сайты с такими сертификатами дают ERR_CERT_AUTHORITY_INVALID у большинства посетителей, которые не установили этот корень.

Антивирус с SSL-инспекцией

Kaspersky, ESET, Bitdefender и другие антивирусы умеют «просматривать» HTTPS-трафик: они разрывают соединение и переподписывают его собственным корневым сертификатом. Если этот корень не установился в системное хранилище (или браузер использует своё, как Firefox), любой сайт начинает выдавать ошибку доверия. Диагностический признак: в цепочке сертификата виден издатель с именем антивируса.

Сбитые дата и время на устройстве

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

Корпоративный прокси или Wi-Fi с перехватом

Корпоративные шлюзы (Zscaler, Squid с SSL-bump, FortiGate) перехватывают TLS так же, как антивирусы. На рабочем ноутбуке корень компании обычно предустановлен и всё работает, а на личном устройстве в той же сети каждый HTTPS-сайт даёт ERR_CERT_AUTHORITY_INVALID. Это не поломка сайта — это политика сети. Похожий эффект дают гостевые Wi-Fi с портальной авторизацией: пока вы не вошли в сеть, вместо любого сайта приходит страница портала с чужим сертификатом.

Таблица: причина → кто чинит → решение

Причина	Кто чинит	Решение
Самоподписанный сертификат	Владелец сайта	Выпустить сертификат у доверенного CA (например, Let’s Encrypt)
Неполная цепочка (нет intermediate)	Владелец сайта	Указать в конфиге сервера fullchain, а не только leaf-сертификат
Неизвестный CA (в т. ч. российские УЦ)	Владелец сайта / пользователь	Перевыпустить у публичного CA; посетителю — браузер с нужным корнем или установка корня с официального сайта
Антивирус с SSL-инспекцией	Пользователь	Отключить проверку HTTPS в антивирусе или переустановить его корень
Сбитые дата и время	Пользователь	Включить автосинхронизацию времени, проверить часовой пояс
Корпоративный прокси	Пользователь / ИТ-отдел	Установить корневой сертификат организации или сменить сеть

Как исправить ошибку ERR_CERT_AUTHORITY_INVALID пользователю

Если ошибка появляется на чужом сайте (а тем более на многих сайтах сразу), проблема почти наверняка на вашей стороне. Действуйте по порядку — от самого частого к редкому:

1. Проверьте дату и время. Включите автоматическую синхронизацию времени и правильный часовой пояс — это лечит массовые ошибки сертификатов чаще всего. В Windows: «Параметры» → «Время и язык» → «Дата и время» → «Установить время автоматически», затем в командной строке от администратора w32tm /resync. В Linux: timedatectl (строка «System clock synchronized: yes») и sudo timedatectl set-ntp true. В macOS: «Системные настройки» → «Основные» → «Дата и время».
2. Проверьте антивирус. Временно отключите проверку защищённых соединений (HTTPS-сканирование). Если ошибка исчезла — переустановите корневой сертификат антивируса или оставьте инспекцию выключенной.
3. Смените сеть. Ошибка есть только на рабочем или общественном Wi-Fi? Трафик перехватывает прокси — обратитесь в ИТ-отдел или используйте мобильный интернет, чтобы проверить.
4. Откройте сайт в другом браузере или в режиме инкогнито — так вы исключите влияние расширений.
5. Посмотрите издателя сертификата. Нажмите на значок слева от адреса и откройте сведения о сертификате. Если издатель — ваш антивирус или прокси компании, причина найдена. Если издатель — Russian Trusted Sub CA, смотрите раздел про сертификаты Минцифры ниже.
6. Очистите SSL-кэш и кэш браузера — это последний шаг, а не первый (как именно — в следующем разделе).

Чего делать не стоит: не нажимайте «Перейти на сайт (небезопасно)» и не добавляйте постоянные исключения для сайтов, где вводите пароли или платёжные данные. Ошибка доверия — это ровно тот сигнал, который отличает настоящий сайт от подменённого атакующим. Общий порядок действий при красном экране «Подключение не защищено», когда код ошибки другой, разобран в статье «Подключение не защищено: что делать».

Как очистить SSL-кэш браузера

Сам сертификат браузер проверяет при каждом новом TLS-соединении, поэтому очистка кэша редко лечит ERR_CERT_AUTHORITY_INVALID. Но она помогает в трёх ситуациях: владелец сайта уже исправил цепочку, а у вас осталось старое соединение; для домена запомнена политика HSTS, из-за которой браузер не даёт открыть сайт; программы Windows держат в кэше состояние старого TLS-сеанса. Делайте очистку после того, как проверили часы, антивирус и сеть.

Windows: «Свойства браузера» → «Содержание» → «Очистить SSL»

В Windows есть системный кэш SSL-состояния, которым пользуются программы, работающие через встроенный TLS-стек Windows (старый Internet Explorer, Edge в режиме IE, ряд корпоративных клиентов и программ для электронной подписи).

1. Нажмите Win+R, введите inetcpl.cpl и нажмите Enter — откроется окно «Свойства браузера» (в старых версиях — «Свойства обозревателя»).
2. Перейдите на вкладку «Содержание».
3. Нажмите кнопку «Очистить SSL» и дождитесь сообщения об успешной очистке.
4. Полностью закройте браузер и откройте его заново.

Учтите: Chrome, Яндекс Браузер и другие браузеры на Chromium используют собственную реализацию TLS, поэтому для них кнопка «Очистить SSL» почти ничего не меняет — для них нужны шаги ниже.

Chrome: кэш, HSTS и пул соединений

1. Нажмите Ctrl+Shift+Delete, выберите «Всё время» и отметьте «Изображения и другие файлы, сохранённые в кеше» (файлы cookie можно не трогать, если не хотите выходить из аккаунтов).
2. Откройте chrome://net-internals/#sockets и нажмите «Flush socket pools» — браузер закроет открытые соединения и при следующем запросе заново получит сертификат.
3. Если сайт раньше работал по HTTPS, а теперь не открывается даже с кнопкой «Дополнительные», откройте chrome://net-internals/#hsts, в блоке «Delete domain security policies» введите домен и нажмите «Delete». Это сбрасывает только динамически запомненную политику HSTS; домены из предзагруженного списка так не удаляются.
4. Закройте все окна Chrome и запустите его снова.

Подробнее о том, как работает HSTS и почему из-за него исчезает кнопка «Перейти на сайт», — в документации MDN о заголовке Strict-Transport-Security.

Как очистить SSL-кэш в Яндекс Браузере

Яндекс Браузер построен на Chromium, поэтому шаги те же, только адреса служебных страниц начинаются с browser://:

1. Ctrl+Shift+Delete → период «За всё время» → «Файлы, сохранённые в кеше» → «Очистить».
2. browser://net-internals/#sockets → «Flush socket pools».
3. browser://net-internals/#hsts → «Delete domain security policies» → домен → «Delete».
4. Полностью перезапустите браузер (закройте все окна и проверьте, что он не остался в области уведомлений).

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

Невозможно установить безопасное соединение в Яндекс Браузере

Сообщение «Невозможно установить безопасное соединение» — так Яндекс Браузер показывает сразу несколько разных проблем. Что именно произошло, видно по коду в подробностях или по тексту под заголовком.

Ошибка сертификата: тот же ERR_CERT_AUTHORITY_INVALID

Если в подробностях указан ERR_CERT_AUTHORITY_INVALID, действуют все причины из этой статьи. Особенность Яндекс Браузера — он доверяет корню Russian Trusted Root CA Минцифры «из коробки», поэтому сайты с российскими сертификатами в нём обычно открываются. Если ошибка появляется именно здесь, чаще всего виноваты часы, антивирус, прокси или неполная цепочка на сервере. Как браузер обращается с недоверенными сертификатами, описано в справке Яндекс Браузера о недоверенных сертификатах.

Невозможно установить безопасное соединение по ГОСТ

Часть государственных и финансовых сервисов (личные кабинеты, системы электронного документооборота, площадки с входом по электронной подписи) используют TLS с российскими криптоалгоритмами ГОСТ. Обычный Chrome или Firefox такое соединение установить не может вообще. Яндекс Браузер умеет, но только если на компьютере установлен криптопровайдер (например, КриптоПро CSP) и включена поддержка ГОСТ:

1. Установите криптопровайдер, который требует сервис (обычно об этом написано в инструкции для входа), и перезагрузите компьютер.
2. В Яндекс Браузере откройте «Настройки» → «Системные» → «Сеть» и включите опцию «Подключаться к сайтам, использующим шифрование по ГОСТ».
3. Перезапустите браузер и откройте сайт заново.

Если ГОСТ-соединение всё равно не устанавливается, проверьте срок действия лицензии криптопровайдера, наличие корневых сертификатов удостоверяющего центра, выдавшего вашу электронную подпись, и не блокирует ли антивирус модуль криптопровайдера. Эта ситуация не связана с настройками сайта для обычных посетителей — для открытой части тех же сервисов ГОСТ, как правило, не нужен.

Другие варианты сообщения

Если в подробностях не ошибка сертификата, а, например, ERR_SSL_PROTOCOL_ERROR или ERR_SSL_VERSION_OR_CIPHER_MISMATCH, — дело не в доверии к CA, а в самом TLS-рукопожатии. Вторая ошибка разобрана в статье ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Госуслуги, Сбербанк, ЕГИССО: сертификаты Russian Trusted CA

С 2022 года часть российских банков и госресурсов использует сертификаты Национального удостоверяющего центра Минцифры (Russian Trusted Sub CA). Его корневой сертификат не включён в хранилища Chrome, Firefox и Safari, поэтому эти браузеры показывают на таких сайтах ERR_CERT_AUTHORITY_INVALID — это ожидаемое поведение, а не взлом. Отсюда запросы «госуслуги err cert authority invalid», «ЕГИССО код ошибки err cert authority invalid», «сбербанк», «ВТБ», «РЖД»: у пользователя браузер без российского корня, а конкретный сервис или его отдельный поддомен отдаёт сертификат НУЦ. Почему так сложилось и как устроена эта цепочка, мы разбираем в отдельной статье про российские удостоверяющие центры.

Проверить, ваш ли это случай, просто: откройте сведения о сертификате и посмотрите поле «Кем выдан». Если там Russian Trusted Sub CA или Russian Trusted Root CA — это сертификат НУЦ Минцифры. У посетителя есть два пути:

• Браузер с предустановленным российским корнем (Яндекс Браузер или Atom) — самый безопасный вариант: ничего не надо ставить в систему вручную.
• Установка корневого сертификата Минцифры вручную — скачивать его только с официальной страницы Госуслуг. Никогда не ставьте корневые сертификаты из мессенджеров, писем или со сторонних сайтов: установленный корень позволяет его владельцу выпускать сертификаты для любого домена, и поддельный корень означает полный перехват вашего HTTPS-трафика.

Как установить корневой сертификат вручную

На странице Госуслуг есть инструкции и установщик для Windows. Если ставите файл вручную, используйте штатные средства системы (имя файла замените на то, что скачали):

# Windows, командная строка от имени администратора
certutil -addstore -f Root russian_trusted_root_ca.cer

# Debian / Ubuntu (файл должен иметь расширение .crt и быть в формате PEM)
sudo cp russian_trusted_root_ca.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

# macOS
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain russian_trusted_root_ca.crt

После установки корня в Windows и macOS Chrome и Edge начинают доверять таким сайтам. Firefox использует собственное хранилище: сертификат нужно импортировать в «Настройки» → «Приватность и защита» → «Сертификаты» → «Просмотр сертификатов» → «Центры сертификации» → «Импортировать». На Android корень ставится через системные настройки безопасности («Шифрование и учётные данные» → «Установить сертификат» → «Сертификат ЦС»); точные названия пунктов зависят от производителя телефона.

Как исправить ERR_CERT_AUTHORITY_INVALID владельцу сайта

Шаг 1. Диагностика цепочки через openssl

Подключитесь к серверу и посмотрите, какие сертификаты он реально отдаёт. Флаг -servername обязателен: без него при SNI-хостинге сервер может вернуть другой сертификат.

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Смотрите на последнюю строку Verify return code. Ключевые значения:

• 20 (unable to get local issuer certificate) — не найден издатель сертификата: на сервере нет промежуточного сертификата или корня нет в хранилище клиента;
• 21 (unable to verify the first certificate) — сервер не отдаёт промежуточный сертификат: чините fullchain;
• 18 (self signed certificate) — самоподписанный сертификат: нужен выпуск у доверенного CA;
• 19 (self signed certificate in certificate chain) — цепочка упирается в неизвестный корень: внутренний или недоверенный CA, либо трафик перехватывается;
• 0 (ok) — цепочка валидна, ищите проблему на стороне клиента.

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

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Проверить, что leaf-сертификат действительно подписан вашим промежуточным, можно локально:

openssl verify -untrusted intermediate.pem certificate.pem

Шаг 2. Отдавайте полную цепочку (fullchain)

В nginx в директиве ssl_certificate должен быть файл, содержащий и сертификат сайта, и промежуточные сертификаты — для Let’s Encrypt это fullchain.pem, а не cert.pem:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
}

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

cat example.com.crt intermediate.crt > fullchain.pem
sudo nginx -t && sudo systemctl reload nginx

В Apache 2.4.8+ промежуточные сертификаты добавляются в тот же файл, что указан в SSLCertificateFile (отдельная директива SSLCertificateChainFile устарела). После правки перезагрузите веб-сервер и повторите проверку openssl — Verify return code должен стать 0.

Шаг 3. Перевыпустите сертификат у доверенного CA

Если сертификат самоподписанный или выпущен УЦ без корня в браузерах, единственное надёжное решение для публичного сайта — сертификат от публичного центра. Бесплатный вариант — Let’s Encrypt: certbot сам соберёт fullchain и настроит автопродление. Подробности — в официальной документации Let’s Encrypt.

sudo certbot --nginx -d example.com -d www.example.com

Если сайту нужен сертификат НУЦ Минцифры (например, по требованиям заказчика), разумная схема — держать параллельно сертификат публичного CA, чтобы посетители с обычными браузерами не упирались в ошибку.

Для внутренних сервисов и localhost

Для dev-стендов и внутренних панелей правильный путь — не «отключить ошибку», а сделать так, чтобы ваш браузер доверял вашему CA. Удобный инструмент — mkcert: он создаёт локальный корень, добавляет его в хранилища системы и браузеров и выпускает сертификаты для нужных имён.

mkcert -install
mkcert localhost 127.0.0.1 dev.example.local

В компании корпоративный корень распространяется на рабочие машины через групповые политики или систему управления устройствами — тогда ошибка не возникает ни у кого из сотрудников.

ERR_CERT_COMMON_NAME_INVALID: чем отличается

ERR_CERT_COMMON_NAME_INVALID — соседняя ошибка, которую часто путают с ERR_CERT_AUTHORITY_INVALID. Здесь сертификат может быть выпущен вполне доверенным CA, но он выдан на другое имя: например, сертификат на example.com открыли по адресу www.example.com, а www не указан в сертификате. Браузер сверяет адрес из строки с полем Subject Alternative Name (SAN).

Проверить, какие имена покрывает сертификат (OpenSSL 1.1.1 и новее):

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

Лечится перевыпуском сертификата с нужными именами (с certbot — добавьте все домены через -d) или редиректом на то имя, которое есть в сертификате. Посетителю тут сделать почти нечего — кроме случая, когда сайт открывается по опечатке или по IP-адресу вместо домена.

Ошибка	Что не так	Типичное решение
ERR_CERT_AUTHORITY_INVALID	Браузер не доверяет издателю сертификата	Fullchain, доверенный CA, проверка антивируса и прокси
ERR_CERT_COMMON_NAME_INVALID	Сертификат выдан на другое доменное имя	Перевыпуск с нужными именами в SAN
ERR_CERT_DATE_INVALID	Сертификат просрочен или часы устройства сбиты	Продление сертификата, синхронизация времени
ERR_SSL_VERSION_OR_CIPHER_MISMATCH	Нет общей версии TLS или набора шифров	Настройка протоколов и шифров на сервере

Как проверить сертификат и цепочку онлайн

Чтобы не собирать диагностику по частям, воспользуйтесь нашей бесплатной проверкой SSL-сертификата и цепочки: сервис покажет издателя, срок действия, полную цепочку до корня, отдаваемые сервером промежуточные сертификаты и предупредит, если fullchain настроен неверно. Это быстрый способ понять, увидят ли ошибку ваши посетители, — проверка идёт с внешнего сервера, а не из вашего браузера с его кешем, антивирусом и корпоративным прокси. Если внешняя проверка показывает валидную цепочку, а у вас ошибка остаётся, — причина точно на стороне вашего устройства или сети.

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

Частые вопросы

Можно ли просто нажать «Всё равно перейти»?

Для чужих сайтов — не стоит: ошибка доверия неотличима от активной атаки с подменой сертификата, и введённые данные может читать посредник. Исключение допустимо для собственного оборудования — роутера или dev-стенда с самоподписанным сертификатом, когда вы точно знаете, что это за узел и почему у него такой сертификат.

Как отключить ошибку ERR_CERT_AUTHORITY_INVALID?

Безопасного способа отключить проверку сертификатов для всех сайтов нет, и искать его не стоит: вместе с ошибкой пропадёт защита от подмены сайтов. Правильный путь — устранить причину: синхронизировать время, выключить HTTPS-проверку в антивирусе, установить нужный корень (Минцифры, корпоративный или локальный через mkcert).

Почему ошибка есть в Firefox, но нет в Chrome?

Классический признак неполной цепочки. Chrome на десктопе умеет докачивать недостающий промежуточный сертификат по ссылке AIA из сертификата, а Firefox и большинство мобильных браузеров этого не делают. Сайт «работает у владельца в Chrome» и падает у части посетителей. Решение одно — отдавать fullchain на сервере.

Чем ERR_CERT_AUTHORITY_INVALID отличается от ERR_CERT_DATE_INVALID?

ERR_CERT_AUTHORITY_INVALID — браузер не доверяет издателю сертификата (цепочка не сходится к доверенному корню). ERR_CERT_DATE_INVALID — сертификат просрочен или ещё не начал действовать. А ERR_SSL_VERSION_OR_CIPHER_MISMATCH вообще не про доверие: она про несовместимость версий протокола TLS и шифров между клиентом и сервером.

Поможет ли очистка кеша браузера?

Редко: проверка сертификата выполняется при каждом TLS-рукопожатии, а не берётся из кеша страниц. Очистка помогает, если сайт уже починили, а у вас висит старое соединение, или если для домена запомнена политика HSTS. Сначала проверяйте время, антивирус и саму цепочку через openssl или онлайн-проверку — это устраняет причину, а не симптом.

Сертификат от Let’s Encrypt точно уберёт ошибку?

Да, при правильной установке. Корень ISRG Root X1, к которому сходятся цепочки Let’s Encrypt, входит в хранилища всех современных браузеров. Важно отдавать fullchain.pem и настроить автопродление: сертификаты Let’s Encrypt живут 90 дней, и просроченный сертификат даст уже другую ошибку — ERR_CERT_DATE_INVALID.