InvalidSignatureException: firma caducada

TL;DR: una solicitud AWS firmada debe llegar al servicio dentro de ~5 minutos después de la marca de tiempo incorporada en su firma. Este error significa que el reloj de su máquina está demasiado alejado de la hora del servidor AWS (desviación del reloj), por lo que la firma ha "caducado" o "aún no está actualizada". Repare el reloj client: habilite la sincronización horaria NTP.

Qué significa

InvalidSignatureException: Signature expired: 20260712T101500Z is now earlier
than 20260712T101700Z (20260712T102200Z - 5 min.)

Signature Version 4 firma cada solicitud junto con una marca de tiempo. AWS valida esa marca de tiempo contra su propio reloj y rechaza cualquier cosa fuera de una ventana de aproximadamente cinco minutos — ya sea Signature expired (reloj del cliente atrasado) o Signature not yet current (reloj del cliente adelantado). Es un HTTP 400, del lado del cliente; un reintento a ciegas vuelve a fallar hasta que se corrige el reloj.

Por qué ocurre

• Deriva del reloj del cliente — el host que ejecuta tu aplicación tiene un reloj inexacto (VM pausada/reanudada, contenedor sin sincronización de hora, dispositivo IoT/edge, runner de CI).
• NTP no está corriendo — nada mantiene disciplinado el reloj del SO, así que lentamente deriva más allá de la tolerancia de 5 minutos.
• Zona horaria/manejo de UTC incorrectos en un firmante hecho a mano que calcula mal la marca de tiempo de la solicitud.
• Proceso suspendido durante mucho tiempo — un portátil o un entorno estilo Lambda reanudado tras una larga pausa con una noción obsoleta del tiempo.

Cómo solucionarlo

1. Activa la sincronización de hora NTP en el host (chrony/systemd-timesyncd/w32time) y confirma que el reloj está dentro de un segundo del UTC real.
2. Compara relojes: revisa la hora UTC del cliente contra una fuente de confianza — si está desfasada por minutos, esa es la causa.
3. Reinicia el servicio de sincronización de hora (o vuelve a sincronizar manualmente) tras reanudar una VM o iniciar un contenedor.
4. Actualiza el AWS SDK — los SDK modernos detectan errores de desfase de reloj y reintentan automáticamente con un desplazamiento corregido; un SDK antiguo puede que no.

Prefiere los SDK oficiales de AWS a un firmante SigV4 escrito a mano para que la marca de tiempo y el manejo de reintentos por desfase se hagan por ti.

En DynoTable

DynoTable se apoya en el AWS SDK para firmar, que incluye corrección de desfase de reloj en las versiones modernas (Conectar una cuenta de AWS). Si este error aparece solo en un script propio pero DynoTable conecta sin problemas, el fallo está aislado en el reloj o el firmante de ese cliente — compáralo con Test Connection en el perfil, en Ajustes → Perfiles. En runners de CI o VMs que hibernan, activa NTP antes de ejecutar la app o tus tests.

Los AWS SDK modernos detectan los errores de desfase de reloj y reintentan con un desplazamiento corregido; si solo lo ves en un firmante hecho a mano, actualiza el SDK o activa NTP en el host antes de culpar a DynamoDB. DynoTable usa la ruta del SDK en exclusiva — nada de ensamblar SigV4 a mano. El query builder confirma que las lecturas funcionan una vez alineados el reloj y el perfil.

Errores relacionados

• The security token expired — las credenciales temporales caducaron (un tipo distinto de "expirado").
• The request signature we calculated does not match — discrepancia de firma por una clave incorrecta, no por el reloj.
• Credential should be scoped to a valid region — un fallo SigV4 de ámbito de región.

Fuentes

• AWS Signature Version 4 for API requests — IAM User Guide (verificado 2026-07-13 — ventana de repetición de cinco minutos)
• Troubleshoot Signature Version 4 signing for AWS API requests — IAM User Guide (verificado 2026-07-13)
• Error handling with DynamoDB — Amazon DynamoDB Developer Guide (verificado 2026-07-13)
• Clock-skew correction — AWS Developer Tools Blog (verificado 2026-07-13)