Что сообщает curl с кодом 60
Строка вида «curl: (60) SSL certificate problem: unable to get local issuer certificate» или «certificate has expired» означает одно: curl установил TCP-соединение и начал TLS-рукопожатие, но не смог убедиться, что сертификат сервера заслуживает доверия. Соединение прерывается до отправки самого запроса.
Важно, что текст после двоеточия важнее числа 60. Он называет конкретную причину: не найден издатель, сертификат просрочен, имя хоста не совпадает, цепочка обрывается, сертификат самоподписанный. От этой фразы и стоит отталкиваться, а не перебирать советы наугад.
Утилита проверяет сертификат по собственному набору корневых сертификатов (файл пакета CA), который зависит от сборки и операционной системы. Поэтому одна и та же ссылка может открываться в браузере, но не в curl.
Причины по убыванию вероятности: curl (60)
Чаще всего сервер отдаёт неполную цепочку: есть только его собственный сертификат, без промежуточного. Браузеры умеют докачивать недостающее звено, а curl обычно нет, и получается ошибка про локального издателя.
Вторая по частоте причина находится на вашей стороне: устаревший пакет корневых сертификатов в системе, особенно в старых дистрибутивах, минимальных контейнерах и Windows-сборках, которые давно не обновлялись. Третья — неверные системные дата и время: сертификат кажется ещё не действующим или уже просроченным.
Дальше идут перехват шифрованного трафика корпоративным прокси или антивирусом, который подставляет свой сертификат, самоподписанный сертификат тестового сервера и, наконец, действительно просроченный сертификат у сайта.
Проверка по шагам: curl (60)
Сначала запустите команду с ключом -v: в выводе будут видны выданный сертификат, его издатель и точная причина отказа. Затем проверьте время на машине: расхождение в несколько минут не страшно, а вот год или месяц не на месте ломает всё.
Откройте тот же адрес в браузере и посмотрите сведения о сертификате: кто издатель, до какой даты действует. Если в браузере всё в порядке, а в curl нет, подозрение падает на цепочку или на набор корневых сертификатов. Проверьте адрес с другого компьютера или с другой сети: если там ошибки нет, причина локальная.
Отдельно посмотрите, не задана ли переменная окружения с путём к собственному файлу сертификатов и нет ли в настройках прокси. Иногда curl читает не тот файл, который вы ожидаете.
Проверьте также, какую именно версию curl вы используете: на одной машине их иногда две, системная и поставляемая с другой программой. Они читают разные файлы сертификатов, и поведение отличается, поэтому убедитесь, что запускаете ту, которую имеете в виду.
Как исправить безопасно
Обновите пакет корневых сертификатов средствами вашей системы: в дистрибутивах Linux это обычно пакет ca-certificates, в контейнерах его нужно установить явно. После обновления повторите запрос.
Если доверенный центр в вашей сети свой (корпоративный), укажите curl файл с этим корневым сертификатом ключом --cacert либо добавьте сертификат в системное хранилище. Так вы сохраняете проверку, лишь расширяя круг доверия осознанно.
Ключ -k (--insecure) отключает проверку целиком. Годится только для короткой диагностики на своём тестовом сервере: он снимает защиту от подмены сервера, и оставлять его в скриптах, которые ходят в интернет, не следует.
Когда виноват сайт
Если ошибка воспроизводится с нескольких устройств и разных сетей, а в сведениях сертификата видно, что срок действия вышел, либо в цепочке нет промежуточного звена, проблема на стороне сервера. Владельцу нужно продлить сертификат и настроить отдачу полной цепочки.
Проверить это можно любым сервисом или командой, которая показывает цепочку сертификатов сервера: она должна содержать сертификат сайта и промежуточные, а корневой обычно не обязателен. Если вы администратор, после исправления перезагрузите веб-сервер, иначе он продолжит отдавать старый файл.
Проверьте и то, как именно вызывается curl: в скриптах и CI часто встречаются старые обёртки, где путь к файлу сертификатов зашит жёстко и давно указывает на несуществующий файл. Тогда ошибка возникает после переноса скрипта на другую машину.
Особые случаи в скриптах и контейнерах
Внутри контейнеров и минимальных образов набора корневых сертификатов часто нет вообще, поэтому первый же запрос по HTTPS завершается кодом 60. Решение стандартное: установить пакет сертификатов при сборке образа и не отключать проверку в самом образе.
Если curl входит в состав другой программы, например менеджера пакетов или установщика, ошибка может относиться к его внутренней копии библиотеки со своим файлом сертификатов. Тогда обновление системных сертификатов не поможет, и нужно обновить саму программу либо указать ей путь к актуальному файлу. При автоматизации полезно логировать полный вывод с ключом -v: по нему через месяц вы поймёте, что именно сломалось.