Constructor de Canonical Request de AWS SigV4｜La cadena intermedia y ambos hashes SHA-256

Introduce un método HTTP, una URI, una query, cabeceras y payload, y esta herramienta arma la Canonical Request de AWS Signature Version 4, la lista SignedHeaders, el SHA-256 del payload y el SHA-256 de la propia canonical request. Muestra la cadena intermedia que la mayoría de los tutoriales de SigV4 omiten, así que cuando tu SDK lance un error de firma puedes alinear cada valor en una sola pantalla. Sin backend: pega y lee.

💡 Sobre esta herramienta

Cada firma SigV4 pasa por una Canonical Request antes de que exista la Signature final. Esa canonical request es una cadena con formato estricto: el método, la URI normalizada, la query normalizada, el bloque de cabeceras canónicas, la lista SignedHeaders y el hash del payload, todo unido con saltos de línea. Los SDK de AWS y boto3 la construyen y la hashean por dentro, pero en cuanto escribes tu propio firmante, un solo carácter desviado en esa cadena devuelve SignatureDoesNotMatch — y el cuerpo del error solo te muestra el hash final, nunca dónde se separaron las cadenas.

Esta herramienta construye la canonical request tal como exige SigV4. La URI y la query reciben percent-encoding de RFC 3986 (todo salvo el conjunto unreserved A-Z a-z 0-9 - . _ ~), los pares de la query se ordenan por clave, y los nombres de cabecera se pasan a minúsculas colapsando el espaciado interno antes de ordenarse por nombre. Emite el cuerpo de la canonical request, SignedHeaders, el SHA-256 del payload y el SHA-256 de la canonical request a la vez, para que compares la salida de tu firmante contra los cuatro valores y localices qué paso de normalización se desvió.

Está pensada para quien escribe firmantes sin el SDK: Lambda@Edge, firma para IoT, flujos de bajo nivel con CloudFront — donde necesitas inspeccionar cada valor intermedio de SigV4. Pega una copia de tus cabeceras reales y trata la salida como la referencia que tu código debería reproducir.

🧐 Preguntas Frecuentes

¿Qué diferencia hay entre la Canonical Request y el StringToSign? La canonical request es la cadena de la petición normalizada — eso es lo que produce esta herramienta. El StringToSign es la etapa siguiente: envuelve el hash de la canonical request con el nombre del algoritmo, la fecha y el credential scope, y es lo que se firma con HMAC usando la clave de firma. Esta herramienta llega hasta la canonical request y su SHA-256.

¿Cómo se normalizan las cabeceras? Los nombres se ponen en minúsculas, los valores se recortan y se colapsan las secuencias de espacios internos a uno solo, y luego se ordenan por nombre. Los nombres de cabecera duplicados se unen con una coma. SignedHeaders son los nombres ordenados unidos con punto y coma.

¿Qué hash produce un payload vacío? El SHA-256 de la cadena vacía: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855. Las peticiones GET y DELETE sin cuerpo usan este valor, y la herramienta lo muestra por defecto.

¿Cómo se ordena la query? Los pares se ordenan ascendentemente por la clave codificada, y los empates se rompen por el valor. Una clave sin valor (key) se trata como key= con valor vacío. Ese orden es un requisito de SigV4: si te equivocas, la firma no coincide.

¿Algo de lo que introduzco sale de mi equipo? No. Cada entrada — método, cabeceras y payload incluidos — se procesa en tu navegador, y el SHA-256 se calcula localmente con la Web Crypto API. Puedes pegar una petición real que estés intentando firmar y nada se envía a un servidor.

📚 Por qué SigV4 normaliza antes de firmar

La razón por la que SigV4 se molesta con una canonical request es que una misma petición lógica puede tener muchas representaciones de bytes. La query b=2&a=1 y a=1&b=2 significan lo mismo pero hashean distinto, y el case de las cabeceras o un espacio sobrante pueden cambiar en tránsito. Una firma es solo el hash de una cadena, así que una diferencia de un carácter produce un hash completamente distinto y el verificador la rechaza. Al forzar a ambos lados por la misma normalización fija — ordenar la query, pasar a minúsculas y colapsar las cabeceras, codificar la URI — SigV4 garantiza que el emisor y AWS lleguen a la cadena idéntica antes de que cualquiera la hashee. Lo ingenioso no es la firma; es que fijar la petición a una forma canónica antes de firmar es lo que hace posible un verificador sin estado, y es justo donde tienden a romperse los firmantes hechos a mano.