Сертификат не проверяется: что это значит и что делать

Принесли задачу, разбираю вторые сутки, вынесу сюда, тема живучая и всплывает у всех.

Есть три площадки из сорока в прогоне. На них с сервера прилетает вот такое:

curl: (60) SSL certificate problem: unable to get local issuer certificate

В браузере с той же машины сайт открывается, замок на месте, никаких предупреждений. Срок у сертификата не вышел, я смотрел. Имя в сертификате совпадает с адресом. Часы на сервере ходят верно, проверял по внешнему источнику.

Хочу разложить причины по полочкам, потому что за словами «сертификат не проверяется» прячется штук пять разных историй, и лечатся они по-разному.

а браузер тогда почему молчит, у него же те же корни

Корни те же, повадки разные. Браузер умеет добирать недостающие звенья сам, консольные утилиты обычно нет. Вот с этого и предлагаю начать разбор, похоже, что мы упёрлись ровно в него.

Тогда смотрите цепочку целиком, там всё написано открытым текстом.

Механика проверки такая. Сайт при рукопожатии присылает свой сертификат и, по-хорошему, все промежуточные над ним, до того звена, корень которого лежит у вас в хранилище. Цепочка должна сомкнуться. Когда сайт присылает только свой сертификат и забывает промежуточный, у вас на руках остаётся кусок без опоры, и вы видите ровно ту фразу про local issuer.

Браузер в этот момент лезет по адресу, записанному внутри сертификата, скачивает недостающее звено сам и молча смыкает цепочку. Пользователь ничего не замечает. Утилита такого хода не делает и честно останавливается.

Одно звено в списке при том, что издатель указан чужой, и есть ваш ответ. У здорового сайта в этом месте два или три звена подряд.

Вторая по частоте история совсем другая, но выглядит один в один: хранилище корней на сервере старое или его нет вовсе. Особенно на голых образах и в контейнерах, там пакет с корнями часто выкидывают ради веса.

Проверяется в лоб:

ls -l /etc/ssl/certs/ca-certificates.crt
openssl version -d
apt-get install --reinstall ca-certificates && update-ca-certificates

Примета, по которой отличают от первой истории: при пустом хранилище отваливаются все сайты подряд. У вас отвалились три из сорока, значит хранилище на месте.

вот теперь понятно, спасибо

Подтверждаю версию hardline, у всех трёх площадок в ответе по одному звену. Издатель у них общий, промежуточный один и тот же. Занятно, что площадки друг с другом никак не связаны, просто одинаково собранный узел раздачи.

Раз уж пошёл разбор по полочкам, добавлю третью историю, она реже, но ловит больно.

Часы. Сертификат действителен внутри окна дат, и проверка сверяет его с системным временем. Уехавшие на сутки вперёд часы на свежем сервере дают ту же самую картину «проверка не прошла», при этом сертификат живой и цепочка полная. У меня так было на машине, которая поднялась без службы времени.

timedatectl status
chronyc tracking

Отличается от остальных двух мгновенно: при уехавших часах падают вообще все площадки и текст ошибки говорит про срок, certificate is not yet valid.

Четвёртую добавлю: посредник со своим сертификатом посередине. Тогда в цепочке вы увидите незнакомое имя издателя на самом верху, и оно будет одинаковым для всех площадок.

Раз перечисляем, скажу про самый частый ход в этой ситуации и почему он плохой.

Ход такой: увидели ошибку проверки, поставили ключ отключения и поехали дальше. Прогон снова зелёный, задача закрыта, все довольны. Через месяц выясняется, что половина выгрузки идёт с подменённого узла, и понять это невозможно: проверять-то нечем, вы сами убрали единственный признак, по которому отличают собеседника.

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

curl --cacert /opt/progon/chain.pem https://target.example/

В библиотеках то же самое делается одним параметром пути к пачке корней. Проверка остаётся на месте, площадка ходит, ключа отключения в скрипте нет.

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

И проверяйте пачку раз в квартал, корни тоже стареют.

Подобью итог, раз тема получилась развесистой.

По моим трём площадкам подтвердилась первая история: узел раздачи отдаёт один сертификат без промежуточного звена. Скачал промежуточный по адресу из поля издателя, сложил его вместе с системной пачкой в отдельный файл, прописал этот файл прогону. Все сорок площадок идут, ключ отключения нигде не появился.

Свёл в кучу приметы, чтобы искать по теме было проще:

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