curl: (77) error setting certificate file: /etc/pki/tls/certs/ca-bundle.crt

curl 7.81 и новее выводят «error setting certificate file: <path>» (или «error setting certificate path» для каталога CA); curl 7.74 и более ранние версии выводили «error setting certificate verify locations:», а за ним значения CAfile и CApath. Путь — тот, который указан в вашей конфигурации.

curl (OpenSSL backend) — CURLE_SSL_CACERT_BADFILE

Что это означает

curl не смог загрузить пакет сертификатов CA (CA bundle), который ему указали, поэтому вообще отказывается выполнять HTTPS-запросы. На сервер ничего не отправлено: сбой происходит до соединения, когда curl читает файл, указанный после двоеточия. Путь берётся из --cacert, CURL_CA_BUNDLE, SSL_CERT_FILE, файла .curlrc или из значения по умолчанию, заданного при сборке curl.

Почему это происходит

• Путь из другого дистрибутива

  часто

  Скрипты, Dockerfile и шаблоны CI, написанные для RHEL, экспортируют CURL_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crt; та же строка в Debian, Ubuntu или Alpine указывает на файл, которого там нет (и наоборот — с /etc/ssl/certs/ca-certificates.crt).

• В образе не установлен пакет сертификатов CA

  часто

  В минимальных образах часто нет пакета ca-certificates, поэтому путь по умолчанию, заданный при сборке curl, ни на что не указывает.

• Файл существует, но его невозможно прочитать

  иногда

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

• Относительный путь отсчитывается от другого каталога

  иногда

  --cacert certs/ca.pem работает в папке проекта и даёт сбой, когда задание cron, юнит systemd или шаг CI запускает curl из другого рабочего каталога.

Как исправить

1. 1.

   Выясните, откуда берётся путь

   Поищите настройку CA в переменных окружения и в ~/.curlrc, а TLS-библиотеку посмотрите в выводе curl -V: сборки с OpenSSL учитывают CURL_CA_BUNDLE и SSL_CERT_FILE, а сборки с Schannel и Secure Transport используют системное хранилище, если не указано иное.

   env | grep -E 'CURL_CA_BUNDLE|SSL_CERT_FILE|SSL_CERT_DIR'
   grep -sE 'cacert|capath' ~/.curlrc
   curl -V | head -1            # which TLS library this curl uses

2. 2.

   Используйте путь к пакету сертификатов этого дистрибутива или не задавайте его вовсе

   В большинстве случаев правильное решение — убрать переопределение: тогда curl использует путь к пакету сертификатов, заданный при сборке пакета curl. Если нужен собственный пакет сертификатов, укажите файл, который есть в этой системе.

   # Debian, Ubuntu, Alpine:        /etc/ssl/certs/ca-certificates.crt
   # RHEL, Fedora, Amazon Linux:    /etc/pki/tls/certs/ca-bundle.crt
   # openSUSE:                      /etc/ssl/ca-bundle.pem
   unset CURL_CA_BUNDLE        # let curl use the bundle it was built with
   ls -l /etc/ssl/certs/ca-certificates.crt

3. 3.

   Установите пакет сертификатов CA

   В облегчённых образах и образах на основе distroless добавляйте ca-certificates при сборке, чтобы путь по умолчанию существовал.

   apt-get install -y ca-certificates     # Debian/Ubuntu
   apk add --no-cache ca-certificates     # Alpine
   dnf install -y ca-certificates         # RHEL/Fedora

4. 4.

   Сделайте файл доступным для чтения и используйте абсолютный путь

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

   ls -l /opt/certs/bundle.pem
   sudo chmod 0644 /opt/certs/bundle.pem
   curl --cacert "$(realpath /opt/certs/bundle.pem)" https://api.example.com/

← Открыть всю базу ошибок подписей