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

O curl 7.81 e posteriores imprimem “error setting certificate file: <path>” (ou “error setting certificate path” para um diretório de CAs); o curl 7.74 e anteriores imprimiam “error setting certificate verify locations:” seguido dos valores de CAfile e CApath. O caminho é o que sua configuração indicar.

curl (OpenSSL backend) — CURLE_SSL_CACERT_BADFILE

O que significa

O curl não conseguiu carregar o bundle de CAs que deveria usar, por isso se recusa a fazer qualquer requisição HTTPS. Nada foi enviado ao servidor: a falha acontece antes da conexão, enquanto o curl lê o arquivo indicado depois dos dois-pontos. O caminho vem de --cacert, CURL_CA_BUNDLE, SSL_CERT_FILE, de um arquivo .curlrc ou do padrão compilado no curl.

Por que acontece

• Um caminho de outra distribuição

  comum

  Scripts, Dockerfiles e templates de CI escritos para RHEL exportam CURL_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crt; a mesma linha no Debian, no Ubuntu ou no Alpine aponta para um arquivo que não existe ali (e vice-versa com /etc/ssl/certs/ca-certificates.crt).

• A imagem não tem um bundle de CAs instalado

  comum

  Imagens mínimas costumam omitir o pacote ca-certificates, então o caminho padrão compilado no curl não aponta para nada.

• O arquivo existe, mas não pode ser lido

  ocasional

  Um bundle que só o root consegue ler, um link simbólico quebrado depois de uma atualização ou um arquivo vazio truncado por uma cópia que falhou produzem a mesma mensagem.

• Um caminho relativo resolvido a partir de outro diretório

  ocasional

  A opção --cacert certs/ca.pem funciona na pasta do projeto e falha quando um job do cron, uma unidade do systemd ou uma etapa de CI executa o curl a partir de outro diretório de trabalho.

Como corrigir

1. 1.

   Descobrir de onde vem o caminho

   Procure uma configuração de CA no ambiente e no arquivo ~/.curlrc, e veja no curl -V qual é a biblioteca TLS: builds com OpenSSL respeitam CURL_CA_BUNDLE e SSL_CERT_FILE; builds com Schannel e Secure Transport usam o repositório de certificados do sistema, salvo configuração em contrário.

   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.

   Usar o caminho do bundle desta distribuição, ou nenhum

   Na maioria dos casos, remover a configuração que substitui o padrão é a correção certa: o curl passa a usar o caminho do bundle com que o pacote dele foi compilado. Se você precisa de um bundle personalizado, aponte para um arquivo que exista neste sistema.

   # 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.

   Instalar o pacote do bundle de CAs

   Em imagens slim e derivadas de distroless, adicione ca-certificates no build para que o caminho padrão exista.

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

4. 4.

   Tornar o arquivo legível e usar um caminho absoluto

   A conta que executa o curl precisa de permissão de leitura no bundle. Caminhos absolutos continuam funcionando quando o diretório de trabalho muda.

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

← Ver toda a base de erros de assinatura