La firma della richiesta che abbiamo calcolato non corrisponde

TL;DR — AWS ha ricalcolato la firma SigV4 per la tua richiesta DynamoDB e ha ottenuto un valore diverso da quello inviato. Le solite cause: una chiave segreta errata/non corrispondente, disallineamento dell'orologio tra la tua macchina e AWS o una richiesta canonica lanciata manualmente che è stata creata leggermente in modo errato. Correggi la chiave o l'orologio oppure lascia semplicemente firmare un AWS SDK per te.

Cosa significa

InvalidSignatureException: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.

Ogni richiesta DynamoDB viene firmata con SigV4 utilizzando la chiave segreta su un modulo canonico della richiesta. AWS deriva nuovamente la firma lato server; se è diverso, ottieni questo HTTP 400. Si tratta di un errore di autenticazione (l'identità/firma), distinto da un rifiuto di autorizzazione. Normalmente non è possibile riprovare senza modifiche, ma se si tratta di uno spostamento dell'orologio, può apparire intermittente.

Perché succede

Chiave di accesso segreta errata: AWS_SECRET_ACCESS_KEY non corrisponde a AWS_ACCESS_KEY_ID (chiavi mescolate, un segreto ruotato/vecchio, uno spazio finale vagante o una nuova riga).
Disallineamento dell'orologio: l'ora della macchina si discosta da AWS; SigV4 inserisce il timestamp della richiesta nella firma, quindi un orologio sbagliato lo interrompe (classico in VM/contenitori, ad esempio dopo che una VM si riattiva dall'ibernazione).
Richiesta canonica creata manualmente: un firmatario personalizzato che ordina intestazioni/parametri di query errati, codifica erroneamente l'URI o esegue l'hashing del payload errato.
Caratteri speciali nella chiave gestiti in modo errato — i segreti contenenti -, +, / o % possono essere alterati da shell o script che creano file di credenziali; AWS suggerisce di rigenerare la chiave.
Legacy SigV2: firma con Signature Version 2, che servizi come Amazon S3 e le regioni più recenti non supportano più.
Un proxy o gateway che modifica la richiesta dopo la firma (aggiungendo/riordinando le intestazioni, ricodificando il percorso).

Come risolverlo

Ricontrolla la coppia di chiavi. Rigenera o ricopia la chiave di accesso + il segreto e impostali in modo pulito (fai attenzione agli spazi bianchi/riga finali e rigenera se il segreto contiene caratteri speciali che i tuoi strumenti alterano).
Correggi l'orologio. Abilita NTP in modo che l'ora dell'host sia precisa:
```
timedatectl status        # verify "System clock synchronized: yes"
```
Preferisci un AWS SDK/CLI: lascia che costruisca e firmi la richiesta; l'intera classe di bug relativi alle richieste canoniche scompare.
Se devi firmare a mano, segui esattamente le regole di richiesta canonica SigV4 (intestazioni ordinate, percorso codificato URI, x-amz-date, payload con hash) e confrontalo con l'output --debug della CLI.
Conferma che l'identità funziona con un cliente noto:
```
aws sts get-caller-identity
```

Riproducilo

Firma con un ID chiave di accesso reale ma con il segreto sbagliato. Tutto il resto della richiesta è valido, quindi l'errore isola la firma:

import boto3
boto3.client(
    'dynamodb',
    region_name='us-east-1',
    aws_access_key_id='AKIA...',                      # a real key id
    aws_secret_access_key='deliberately-the-wrong-secret',
).list_tables()

Produzione reale:

InvalidSignatureException: The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
HTTP 400

Nota la classe. Il messaggio è il familiare "la firma che abbiamo calcolato non corrisponde", ma DynamoDB lo restituisce come InvalidSignatureException — non SignatureDoesNotMatch, che è ciò che molti altri servizi AWS utilizzano per la stessa situazione. Se si cattura per classe anziché per corrispondenza del messaggio, questa distinzione è la differenza tra un gestore che si attiva e uno che non si attiva mai.

Vedilo in DynoTable

DynoTable non ti chiede mai di firmare manualmente le richieste: utilizza lo stesso AWS SDK catena di credenziali come CLI (Connetti un account AWS). Se aws sts get-caller-identity ha esito positivo ma DynamoDB genera ancora questo errore, verificare la presenza di proxy o middleware tra l'app e AWS; DynoTable parla con DynamoDB direttamente dalla tua macchina senza intermediari. Dopo aver riparato le chiavi o disallineamento dell'orologio, premere ⌘P per confermare il profilo attivo ed eseguire Test Connessione in Impostazioni → Profili prima di aprire nuovamente le tabelle.

Errori correlati

Il token di sicurezza incluso nella richiesta non è valido — le credenziali/il token stesso vengono rifiutati.
IncompleteSignatureException: l'intestazione dell'autorizzazione non è corretta, non solo non corrisponde.
Il token di sicurezza è scaduto

Fonti

Risoluzione dei problemi relativi alla firma della versione 4 della firma per le richieste AWS API — Guida per l'utente IAM (verificato il 13-07-2026)
Errori di risoluzione dei problemi per la AWS CLI - Guida per l'utente della AWS CLI (verificato il 13-07-2026)
Crea una richiesta AWS API firmata - IAM Guida per l'utente (verificato il 13-07-2026)

Riprodotto il 26-07-2026 rispetto al servizio live DynamoDB negli Stati Uniti-est-1: l'output sopra è letterale.