InvalidSignatureException : Signature expired

TL;DR — Une requête AWS signée doit atteindre le service dans un délai d'environ 5 minutes par rapport à l'horodatage intégré à sa signature. Cette erreur signifie que l'horloge de ta machine est trop éloignée de l'heure des serveurs AWS (décalage d'horloge), si bien que la signature a « expiré » ou n'est « pas encore valide ». Corrige l'horloge du client — active la synchronisation de l'heure par NTP.

Ce que ça signifie

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

Signature Version 4 signe chaque requête avec un horodatage. AWS valide cet horodatage par rapport à sa propre horloge et rejette tout ce qui sort d'une fenêtre d'environ cinq minutes — soit Signature expired (horloge du client en retard), soit Signature not yet current (horloge du client en avance). C'est une erreur HTTP 400, côté client ; une nouvelle tentative à l'aveugle échoue à nouveau tant que l'horloge n'est pas corrigée.

Pourquoi ça arrive

Dérive de l'horloge du client — l'hôte qui exécute ton application a une horloge imprécise (VM mise en pause/reprise, conteneur sans synchronisation de l'heure, appareil IoT/edge, runner CI).
NTP non actif — rien ne maintient l'horloge de l'OS synchronisée, elle dérive donc lentement au-delà de la tolérance de 5 minutes.
Fuseau horaire/gestion UTC incorrects dans un signataire fait maison qui calcule mal l'horodatage de la requête.
Processus suspendu longtemps — un ordinateur portable ou un environnement de type Lambda repris après une longue pause avec une notion périmée du temps.

Comment le corriger

Active la synchronisation de l'heure par NTP sur l'hôte (chrony/systemd-timesyncd/w32time) et confirme que l'horloge est à moins d'une seconde de l'UTC réel.
Compare les horloges : vérifie l'heure UTC du client par rapport à une source de confiance — si elle est décalée de plusieurs minutes, c'est la cause.
Redémarre le service de synchronisation de l'heure (ou resynchronise manuellement) après la reprise d'une VM ou le démarrage d'un conteneur.
Mets à jour l'AWS SDK — les SDK modernes détectent les erreurs de décalage d'horloge et réessaient automatiquement avec un décalage corrigé ; un vieux SDK peut ne pas le faire.

Préfère les SDK AWS officiels à un signataire SigV4 écrit à la main, pour que l'horodatage et la gestion des nouvelles tentatives en cas de décalage soient pris en charge à ta place.

Dans DynoTable

DynoTable s'appuie sur le SDK AWS pour la signature, qui corrige la dérive d'horloge sur les builds récents (Connecter un compte AWS). Si cette erreur n'apparaît que dans un script maison alors que DynoTable se connecte sans problème, le problème est circonscrit à l'horloge ou au signeur de ce client-là — compare avec Test Connection sur le profil dans Settings → Profiles. Sur des runners de CI ou des VM qui hibernent, active NTP avant de lancer l'app comme tes tests.

Les SDK AWS modernes détectent les erreurs de dérive d'horloge et réessaient avec un décalage corrigé ; si tu ne vois ça que dans un signeur écrit à la main, mets le SDK à jour ou active NTP sur l'hôte avant d'incriminer DynamoDB. DynoTable emprunte exclusivement le chemin du SDK — aucun assemblage SigV4 maison. Le query builder confirme que les lectures réussissent une fois l'horloge et le profil alignés.

Erreurs liées

The security token expired — des identifiants temporaires ont expiré (un autre type d'« expiration »).
The request signature we calculated does not match — une non-concordance de signature due à une mauvaise clé, pas à une horloge.
Credential should be scoped to a valid region — un échec SigV4 lié à la portée de région.

Sources

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.