Constructeur de Canonical Request AWS SigV4｜La chaîne intermédiaire et les deux hashes SHA-256

Saisissez une méthode HTTP, une URI, une query, des en-têtes et un payload : cet outil assemble la Canonical Request d'AWS Signature Version 4, la liste SignedHeaders, le SHA-256 du payload et le SHA-256 de la canonical request elle-même. Il montre la chaîne intermédiaire que la plupart des tutoriels SigV4 passent sous silence, donc lorsque votre SDK renvoie une erreur de signature, vous alignez chaque valeur sur un seul écran. Pas de backend : collez et lisez.

💡 À propos de cet outil

Chaque signature SigV4 passe par une Canonical Request avant que la Signature finale n'existe. Cette canonical request est une chaîne au format strict : la méthode, l'URI normalisée, la query normalisée, le bloc d'en-têtes canoniques, la liste SignedHeaders et le hash du payload, le tout joint par des sauts de ligne. Les SDK AWS et boto3 la construisent et la hashent en interne, mais dès que vous écrivez votre propre signataire, un seul caractère décalé dans cette chaîne renvoie SignatureDoesNotMatch — et le corps de l'erreur ne montre que le hash final, jamais l'endroit où les chaînes ont divergé.

Cet outil construit la canonical request exactement comme l'exige SigV4. L'URI et la query reçoivent le percent-encoding de la RFC 3986 (tout sauf l'ensemble unreserved A-Z a-z 0-9 - . _ ~), les paires de la query sont triées par clé, et les noms d'en-tête sont mis en minuscules avec les espaces internes réduits avant d'être triés par nom. Il émet le corps de la canonical request, SignedHeaders, le SHA-256 du payload et le SHA-256 de la canonical request en même temps, pour que vous compariez la sortie de votre signataire aux quatre valeurs et repériez l'étape de normalisation qui a dérivé.

Il s'adresse à celles et ceux qui écrivent des signataires sans le SDK : Lambda@Edge, signature IoT, flux CloudFront de bas niveau — partout où vous devez inspecter chaque valeur intermédiaire de SigV4. Collez une copie de vos en-têtes réels et traitez la sortie comme la référence que votre code doit reproduire.

🧐 Questions fréquentes

Quelle est la différence entre la Canonical Request et le StringToSign ? La canonical request est la chaîne de requête normalisée — c'est ce que produit cet outil. Le StringToSign est l'étape suivante : il enveloppe le hash de la canonical request avec le nom de l'algorithme, la date et le credential scope, et c'est ce qui est signé en HMAC avec la clé de signature. Cet outil s'arrête à la canonical request et à son SHA-256.

Comment les en-têtes sont-ils normalisés ? Les noms passent en minuscules, les valeurs sont rognées et les suites d'espaces internes réduites à un seul, puis l'ensemble est trié par nom. Les noms d'en-tête en double sont joints par une virgule. SignedHeaders correspond aux noms triés joints par des points-virgules.

Quel hash produit un payload vide ? Le SHA-256 de la chaîne vide : e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. Les requêtes GET et DELETE sans corps utilisent cette valeur, et l'outil l'affiche par défaut.

Comment la query est-elle triée ? Les paires sont triées par ordre croissant sur la clé encodée, et les égalités sont départagées par la valeur. Une clé sans valeur (key) est traitée comme key= avec une valeur vide. Cet ordre est une exigence de SigV4 : s'il est faux, la signature ne correspond pas.

Une partie de ce que je saisis quitte-t-elle ma machine ? Non. Chaque entrée — méthode, en-têtes et payload compris — est traitée dans votre navigateur, et le SHA-256 est calculé localement avec la Web Crypto API. Vous pouvez coller une requête réelle que vous cherchez à signer, rien n'est envoyé à un serveur.

📚 Pourquoi SigV4 normalise avant de signer

Si SigV4 se donne la peine d'une canonical request, c'est qu'une même requête logique peut avoir de nombreuses représentations d'octets. La query b=2&a=1 et a=1&b=2 veulent dire la même chose mais ne donnent pas le même hash, et la casse des en-têtes ou un espace superflu peuvent changer en transit. Une signature n'est que le hash d'une chaîne : une différence d'un seul caractère dans la représentation produit un hash totalement différent, et le vérificateur la rejette. En forçant les deux côtés à passer par la même normalisation fixe — trier la query, mettre en minuscules et réduire les en-têtes, encoder l'URI — SigV4 garantit que l'émetteur et AWS aboutissent à la chaîne identique avant que l'un ou l'autre ne la hashe. Le plus ingénieux n'est pas la signature ; c'est que figer la requête dans une forme canonique avant de signer est ce qui rend possible un vérificateur sans état, et c'est précisément là que les signataires faits main ont tendance à casser.