01
Figer l’heure
L’horodatage UTC est rempli une seule fois au chargement. Le bouton Maintenant le renouvelle explicitement. L’exemple S3 utilise des valeurs publiques et affiche un aperçu avant de remplacer votre saisie.
Outils cloud
déboguer une signature AWS SigV4
Saisissez les champs réellement signés et suivez chaque étape du calcul.
déboguer une signature AWS SigV4
Demande saisie
Résultat de signature
Calcul dans le navigateur, sans envoi. Utilisez des identifiants de test, jamais un secret de production.
Options et références
Horodatage UTC
Requête canonique de référence
Saisissez une URL pour commencer.
Le rapport masque le Session Token ; sa requête masquée ne permet pas de recalculer la signature.
Une erreur SignatureDoesNotMatch ne désigne pas forcément la clé. Pour déboguer une signature AWS SigV4, confrontez le chemin, la requête canonique, les en-têtes et le hachage du corps à ce que renvoie le service.
L’exemple S3 publié par AWS fournit des clés fictives et une date fixe. Le calcul reste dans le navigateur : il ne vérifie ni les autorisations IAM ni la réponse d’un point de terminaison.
Pourquoi déboguer une signature AWS SigV4 ici
Transformez un échec de signature en différences de texte observables.
Voir l’encodage et le tri
Pour déboguer une signature AWS SigV4, l’outil trie les noms et valeurs de paramètres après encodage, garde les doublons et normalise les espaces des en-têtes. `+`, `%20` et une barre oblique supplémentaire deviennent visibles dans la requête canonique.
Suivre les étapes de la signature
Le SHA-256 de la requête canonique, la portée des identifiants et la chaîne à signer sont séparés. Une référence collée indique la première ligne différente avant même de fournir une clé de test.
Reproduire une demande avec des valeurs fixes
02
Lire la normalisation avant le HMAC
Lancez le calcul manuellement ou avec Ctrl/Cmd+Entrée. Vérifiez l’URI, le tri des paramètres, les en-têtes et le hachage du corps. Pour S3, x-amz-content-sha256 suit le mode de charge utile choisi.
03
Comparer sans exposer les clés
La requête canonique peut être comparée sans secret. Seule la signature finale exige une paire de test jetable. Le rapport courant masque le Session Token ; la copie exacte de la requête est une action distincte.
Les éléments visibles du calcul SigV4
Six parties canoniques
Méthode, URI, paramètres triés, en-têtes normalisés, SignedHeaders et hachage du corps forment la requête canonique. Les paramètres répétés restent distincts et `+` devient `%2B`, jamais un espace de formulaire.
Chaîne à signer et portée
Le SHA-256 de la requête canonique et la portée date/région/service/aws4_request sont affichés. Une mauvaise région change à la fois la chaîne à signer et la clé HMAC dérivée.
Signature de test facultative
L’analyse de structure fonctionne sans clé. Une paire de test éphémère permet de calculer Signature et Authorization localement ; ni le secret ni les clés intermédiaires ne sont montrés.
Première ligne différente
Comparez une requête canonique collée ligne par ligne et une signature hexadécimale de 64 caractères. Ce diagnostic d’écart ne prouve pas qu’AWS accepterait la demande.
Ce que le calcul hors ligne ne couvre pas
- En-tête Authorization uniquement
- L’outil calcule AWS4-HMAC-SHA256 pour l’en-tête Authorization. Il ne produit pas d’URL pré-signée, SigV4a, V2, signature par blocs, et ne lit pas les fichiers cURL ou HAR.
- Aucune validation par AWS
- Aucune demande n’est envoyée à AWS ou à l’URL saisie. Un HMAC local identique ne valide ni les identifiants, ni les droits IAM, ni les octets transmis après un proxy.
- Chemin et corps sans réparation
- Les chemins d’objets S3 ne sont pas normalisés. Les segments point ambigus ou les barres encodées provoquent une erreur. Le corps traité est seulement le texte UTF-8 collé, pas un fichier ou un flux.
- Jetons temporaires sensibles
- Le Session Token entre dans x-amz-security-token et peut figurer dans la requête canonique exacte. Le rapport général le masque ; cette version masquée ne peut pas servir à recalculer la signature.
Questions pour déboguer une signature AWS SigV4
Comment résoudre un écart de signature SigV4 avec IAM sur API Gateway ?
Comparez d’abord la requête canonique de votre client à celle de la réponse AWS. Pour déboguer une signature AWS SigV4, la première ligne différente guide l’examen de l’URI, du tri des paramètres, des en-têtes signés et du hachage du corps.
Pourquoi la signature calculée ne correspond-elle pas ?
Les octets reçus peuvent différer de ceux signés : un proxy modifie parfois le chemin ou les en-têtes. Vérifiez aussi l’heure, la région, le service et la paire de clés de test. Le calcul local ne remplace pas le journal du service.
Puis-je vérifier la requête canonique sans clé secrète ?
Oui : sa forme, son SHA-256 et la chaîne à signer sont calculables sans secret. Le HMAC final exige la clé correspondante ; aucune signature fictive n’est affichée si elle manque.
Un message AccessDenied prouve-t-il que la signature est valide ?
L’interprétation dépend du service et de son ordre de contrôles. Cette page ne contacte pas AWS et ne lit pas la politique IAM. Consultez les journaux et les outils d’autorisation du service.
Un proxy peut-il invalider la signature SigV4 ?
Oui, s’il modifie un en-tête signé, l’hôte, le chemin, les paramètres ou le corps. Comparez si possible la requête avant et après le proxy avec le texte attendu dans la réponse AWS.
Une autre question ?
Déboguer une signature AWS SigV4 maintenant
Commencez par le vecteur S3 public, puis comparez une demande de test personnelle. Vous pouvez déboguer une signature AWS SigV4 ici sans envoyer la demande.