01
Zeitpunkt festhalten
Der UTC-Zeitstempel wird beim Laden einmal gesetzt. Nur die Schaltfläche Jetzt aktualisiert ihn. Das veröffentlichte S3-Beispiel ersetzt die Eingaben erst nach einer Vorschau und enthält einen bekannten Testwert.
Cloud-Werkzeuge
AWS SigV4 Signatur prüfen
Die tatsächlich signierten Anfragefelder eintragen und jeden Rechenschritt nachvollziehen.
AWS SigV4 Signatur prüfen
Anfrage
Signierergebnis
Berechnung nur im Browser; keine Anfrage wird gesendet. Nur Testdaten, keine produktiven Secrets verwenden.
Signieroptionen und Referenzen
UTC-Zeitstempel
Kanonische Referenzanfrage
Anfrage-URL eingeben.
Berichte schwärzen das Session Token; damit lässt sich die Signatur nicht neu berechnen.
Bei SignatureDoesNotMatch liegt der Fehler nicht zwangsläufig am Schlüssel. Mit AWS SigV4 Signatur prüfen vergleichen Sie die kanonische Anfrage aus Pfad, Query, Headern und Nutzlast-Hash mit dem Wert aus einer AWS-Fehlerantwort.
Ein veröffentlichtes S3-Testbeispiel liefert feste Eingaben und eine bekannte Signatur. Die Berechnung bleibt im Browser; IAM-Berechtigungen und die Annahme durch einen Dienst werden nicht geprüft.
Warum AWS SigV4 Signatur prüfen
Aus einem 403-Fehler werden überprüfbare Eingaben.
Kodierung und Reihenfolge offenlegen
AWS SigV4 Signatur prüfen sortiert die bereits kodierten Query-Namen und -Werte, behält doppelte Parameter und normalisiert Header-Leerzeichen. Ob `+`, `%20` oder ein zusätzlicher Schrägstrich den Unterschied verursacht, ist in der kanonischen Anfrage sichtbar.
Den Weg zur Signatur verfolgen
Hash der kanonischen Anfrage, Geltungsbereich und zu signierende Zeichenfolge sind getrennt zu sehen. Mit einer eingefügten Referenz markiert AWS SigV4 Signatur prüfen die erste abweichende Zeile, bevor ein optionaler Testschlüssel verwendet wird.
Eine feste Anfrage reproduzierbar untersuchen
02
Vor dem HMAC die Anfrage prüfen
Die Berechnung startet manuell oder mit Strg/Cmd+Enter. Vergleichen Sie URI, sortierte Query, normalisierte Header und Nutzlast-Hash. Bei S3 wird x-amz-content-sha256 aus dem gewählten Modus ergänzt.
03
Referenz gezielt vergleichen
Eine kanonische Referenz können Sie ohne geheimen Schlüssel vergleichen. Erst für den finalen HMAC-Abgleich sind Wegwerf-Testdaten nötig. Der allgemeine Bericht schwärzt Session Tokens; die exakte Anfrage wird gesondert kopiert.
Welche Teile der Signierung sichtbar werden
Sechs Teile der kanonischen Anfrage
Methode, URI, sortierte Query, kanonische Header, SignedHeaders und Nutzlast-Hash werden zusammengesetzt. Gleiche Query-Namen bleiben erhalten; `+` wird als `%2B` und nicht als Leerzeichen kodiert.
Zeichenfolge und Geltungsbereich
Der SHA-256-Hash der kanonischen Anfrage und Datum/Region/Dienst/aws4_request sind sichtbar. Eine falsche Region verändert sowohl die zu signierende Zeichenfolge als auch den abgeleiteten HMAC-Schlüssel.
Optionale Testsignatur
Auch ohne Secret lässt sich die Struktur untersuchen. Nur mit einem entbehrlichen Schlüsselpaar entstehen Signature und Authorization; weder Secret noch Zwischenstufen des Signing Key werden angezeigt.
Erste Abweichung der Referenz
Eine eingefügte kanonische Anfrage wird zeilenweise verglichen, eine 64-stellige Signatur als Wert. Die Diagnose erklärt eine SigV4-Signaturabweichung, bestätigt aber keine AWS-Berechtigung.
Grenzen der lokalen Berechnung
- Nur Authorization-Header
- Berechnet wird AWS4-HMAC-SHA256 für den Authorization-Header. Vorsignierte URLs, SigV4a, V2, Chunk-Uploads sowie das Einlesen von cURL- oder HAR-Dateien gehören nicht dazu.
- Keine Anfrage an AWS
- Weder AWS noch die eingegebene URL werden aufgerufen. Ein passender Test-HMAC beweist weder gültige Zugangsdaten noch IAM-Rechte oder unveränderte Bytes nach einem Proxy.
- Pfad und Body bleiben unverfälscht
- S3-Objektpfade werden nicht normalisiert. Mehrdeutige Punktsegmente und kodierte Schrägstriche führen zu einem Fehler. Der Body-Hash bezieht sich nur auf eingefügten UTF-8-Text, nicht auf Dateien oder Streams.
- Temporäre Zugangsdaten schützen
- Ein Session Token wird als x-amz-security-token signiert und kann in der exakten kanonischen Anfrage stehen. Der allgemeine Bericht schwärzt ihn und eignet sich danach nicht zur Neuberechnung.
Fragen zu AWS SigV4 Signatur prüfen
Wie behebe ich Signaturfehler bei SigV4-Anfragen an API Gateway?
Vergleichen Sie zuerst die kanonische Anfrage des Clients mit dem AWS-Fehlertext. AWS SigV4 Signatur prüfen zeigt die erste abweichende Zeile. Prüfen Sie danach URI-Kodierung, Query-Reihenfolge, signierte Header und Nutzlast-Hash.
Warum stimmt die berechnete Anforderungssignatur nicht überein?
Die bei AWS eingetroffenen Bytes können von den signierten Bytes abweichen, etwa durch einen Proxy. Auch Zeitstempel, Region, Dienst oder das Testschlüsselpaar können falsch sein. Ein lokaler Vergleich ersetzt keinen Diensttest.
Kann ich die kanonische Anfrage ohne Secret prüfen?
Ja. Kanonische Anfrage, SHA-256 und zu signierende Zeichenfolge benötigen keinen geheimen Schlüssel. Die finale HMAC-Signatur kann nur mit dem zugehörigen Secret neu berechnet werden.
Welche Header gehören in SignedHeaders?
Die Namen der tatsächlich signierten Header müssen kleingeschrieben und sortiert sein. Dieses Werkzeug ergänzt Host und x-amz-date; bei S3 auch x-amz-content-sha256. Stimmen zusätzliche Header nicht mit der gesendeten Anfrage überein, scheitert der Abgleich.
Kann ein Proxy die SigV4-Signatur ungültig machen?
Ja. Ändert er Pfad, Query, Host, andere signierte Header oder Body, berechnet der Dienst eine andere Signatur. Vergleichen Sie nach Möglichkeit die Anfrage vor und nach dem Proxy und die AWS-Fehlerantwort.
Noch eine Frage?
Jetzt AWS SigV4 Signatur prüfen
Beginnen Sie mit dem veröffentlichten S3-Testvektor und vergleichen Sie danach eine eigene Testanfrage. AWS SigV4 Signatur prüfen sendet dabei keine Anfrage.