curl: (60) SSL certificate problem: certificate has expired

O texto do motivo é idêntico em builds do curl com OpenSSL 1.1.1, 3.0 e 3.5. Versões mais novas do curl (8.22.0 no nosso teste) formulam assim: “SSL certificate OpenSSL verify result: certificate has expired (10)”. Certificados que ainda não são válidos produzem outro motivo: “certificate is not yet valid”.

curl (OpenSSL backend) — CURLE_PEER_FAILED_VERIFICATION, X509_V_ERR_CERT_HAS_EXPIRED (10)

O que significa

Um certificado da cadeia montada pelo curl tem data notAfter anterior ao horário atual da máquina que executa o curl. Normalmente é o próprio certificado do servidor, mas um intermediário expirado ou uma raiz com assinatura cruzada produz o mesmo texto. A verificação é feita com o relógio local, então um relógio errado produz exatamente o mesmo erro que um certificado expirado.

Por que acontece

• A renovação automática parou de funcionar

  comum

  Timers do certbot que nunca foram ativados, desafios ACME que agora falham atrás de uma CDN ou firewall, um token de API de DNS que expirou ou um processo manual que não tem responsável. A vida útil dos certificados públicos está diminuindo para 200 dias em 2026 e 47 dias até 2029, então falhas silenciosas de renovação aparecem rápido.

• O certificado foi renovado, mas o servidor ainda serve o antigo

  comum

  O nginx, o HAProxy, o Postfix e servidores Java carregam o certificado na inicialização. Um arquivo renovado no disco não muda nada até o processo recarregar; balanceadores de carga e CDNs guardam a própria cópia enviada a eles.

• Um intermediário ou assinatura cruzada da cadeia servida expirou

  ocasional

  Um servidor que inclui um intermediário antigo (por exemplo, um com assinatura cruzada copiado de um fullchain desatualizado) pode fazer os clientes montarem um caminho por um certificado expirado, mesmo que o certificado folha esteja em dia. A expiração da assinatura cruzada da DST Root CA X3, em 2021, quebrou muitos clientes antigos dessa forma.

• O relógio do cliente está errado

  ocasional

  Dispositivos sem relógio alimentado por bateria, VMs restauradas de snapshots e contêineres em um host com relógio à deriva podem estar com meses de diferença. Se todos os sites HTTPS falharem de uma vez, verifique a data antes de qualquer outra coisa.

• Um cliente antigo monta o caminho até uma raiz que expirou

  rara

  Clientes com um bundle de CAs desatualizado podem conhecer só uma versão expirada de uma raiz e falhar mesmo quando clientes modernos escolhem um caminho mais novo. Atualizar o ca-certificates resolve o problema neles.

Como corrigir

1. 1.

   Descobrir qual certificado expirou

   Imprima a data notAfter de cada certificado que o servidor envia. Se o certificado folha expirou, renove-o; se for um intermediário, substitua o arquivo da cadeia pelo que sua CA publica atualmente.

   # Split the served chain into cert1.pem (leaf), cert2.pem, ... and print each expiry date
   openssl s_client -connect api.example.com:443 -servername api.example.com -showcerts </dev/null 2>/dev/null \
     | awk '/BEGIN CERT/{n++; f="cert" n ".pem"} /BEGIN CERT/,/END CERT/{print > f}'
   for f in cert*.pem; do openssl x509 -in "$f" -noout -subject -enddate; done

2. 2.

   Renovar, recarregar e verificar o que é servido de fato

   Depois de renovar, recarregue todos os processos e dispositivos que fazem a terminação TLS desse nome e confirme a data pelo lado da rede, e não pelo arquivo no disco.

   sudo certbot renew                    # or your ACME client / CA portal
   sudo systemctl reload nginx           # the server keeps serving the old file until reloaded
   echo | openssl s_client -connect api.example.com:443 -servername api.example.com 2>/dev/null \
     | openssl x509 -noout -enddate      # confirm the new date is what the network sees

3. 3.

   Corrigir o relógio do cliente

   Quando o certificado funciona em outras máquinas, sincronize via NTP a hora da máquina com falha. Em contêineres, o relógio vem do host, então corrija-o lá.

   date -u                       # compare with the real UTC time
   timedatectl status            # "System clock synchronized: yes"?
   sudo timedatectl set-ntp true

4. 4.

   Atualizar o bundle de CAs do cliente

   Em sistemas que ficam muito tempo em operação, um pacote ca-certificates atualizado remove raízes aposentadas e adiciona as atuais, o que permite ao OpenSSL escolher um caminho válido em vez de um expirado.

   # Old clients: refresh the root store so they stop building paths through retired roots
   sudo apt-get update && sudo apt-get install --only-upgrade ca-certificates   # Debian/Ubuntu
   sudo dnf upgrade ca-certificates                                             # RHEL/Fedora

← Ver toda a base de erros de assinatura