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

El texto del motivo es idéntico en las compilaciones de curl con OpenSSL 1.1.1, 3.0 y 3.5. Las versiones más recientes de curl (8.22.0 en nuestra prueba) lo formulan como «SSL certificate OpenSSL verify result: certificate has expired (10)». Los certificados que todavía no son válidos producen otro motivo: «certificate is not yet valid».

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

Qué significa

Uno de los certificados de la cadena que construyó curl tiene una fecha notAfter anterior a la hora actual del equipo donde se ejecuta curl. Suele ser el propio certificado del servidor, pero un intermedio caducado o una raíz con firma cruzada producen el mismo texto. La comprobación se hace contra el reloj local, así que un reloj mal ajustado se ve exactamente igual que un certificado caducado.

Por qué ocurre

• La renovación automática dejó de funcionar

  frecuente

  Temporizadores de certbot que nunca se habilitaron, desafíos ACME que ahora fallan detrás de una CDN o un firewall, un token de la API de DNS que caducó o un proceso manual del que nadie se responsabiliza. La vida útil de los certificados públicos se reduce a 200 días en 2026 y a 47 días para 2029, así que los fallos silenciosos de renovación salen a la luz enseguida.

• El certificado se renovó, pero el servidor sigue sirviendo el antiguo

  frecuente

  nginx, HAProxy, Postfix y los servidores Java cargan el certificado al arrancar. Un archivo renovado en disco no cambia nada hasta que el proceso se recarga; los balanceadores de carga y las CDN guardan su propia copia subida.

• Caducó un intermedio o una firma cruzada de la cadena servida

  ocasional

  Un servidor que incluye un intermedio antiguo (por ejemplo, uno con firma cruzada copiado de un fullchain desactualizado) puede hacer que los clientes construyan una ruta a través de un certificado caducado aunque el certificado hoja esté vigente. La caducidad en 2021 de la firma cruzada de la CA raíz DST Root CA X3 rompió así muchos clientes antiguos.

• El reloj del cliente es incorrecto

  ocasional

  Los dispositivos sin un reloj respaldado por batería, las máquinas virtuales restauradas desde instantáneas y los contenedores en un host cuyo reloj se desvía pueden tener meses de desfase. Si fallan a la vez todos los sitios HTTPS, comprueba la fecha antes que nada.

• Un cliente antiguo construye la ruta hacia una raíz que ha caducado

  rara

  Puede que los clientes con un bundle de certificados de CA desactualizado solo conozcan una versión caducada de una raíz y fallen aunque los clientes modernos elijan una ruta más nueva. Se arreglan actualizando ca-certificates.

Cómo solucionarlo

1. 1.

   Averiguar qué certificado ha caducado

   Imprime la fecha notAfter de cada certificado que envía el servidor. Si el certificado hoja ha caducado, renuévalo; si es un intermedio, sustituye el archivo de cadena por el que publica actualmente tu CA.

   # 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, recargar y comprobar qué se sirve realmente

   Después de renovar, recarga todos los procesos y dispositivos que terminan TLS para ese nombre y luego confirma la fecha desde el lado de la red, no desde el archivo en 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.

   Corregir el reloj del cliente

   Si el certificado funciona bien en otros equipos, sincroniza con NTP la hora del equipo que falla. En los contenedores el reloj viene del host, así que corrígelo allí.

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

4. 4.

   Actualizar el bundle de CA del cliente

   En sistemas que llevan mucho tiempo en servicio, un paquete ca-certificates actualizado elimina los certificados raíz retirados y añade los actuales, lo que permite a OpenSSL elegir una ruta válida en lugar de una caducada.

   # 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

← Explorar toda la base de datos de errores de firma