SignatureDoesNotMatch
AWS SignatureDoesNotMatch (Signature Does Not Match) means AWS recalculated the SigV4 signature and it does not match the signature in the request. In Amazon S3, this error returns HTTP 403.
Last reviewed: April 21, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Signature Does Not Match Mean?
AWS recognized the credential identity but rejected the signed request because the canonical request, string to sign, or secret-derived signature did not match what AWS received on the wire. Authorization does not begin until the signing contract is correct.
Common Causes
- -Canonical request inputs differ between signer and AWS verifier (path, query, headers, or payload hash).
- -SigV4 credential scope uses wrong service, region, or date component for the target endpoint.
- -Secret access key does not match the access key ID used to sign the request.
- -Proxies, CDNs, or middleware alter signed headers after signature creation.
- -Presigned URL is generated for one method, host, or header set but consumed with another.
How to Fix Signature Does Not Match
- 1Reproduce the request with an official AWS SDK or AWS CLI to prove whether custom signing is the problem.
- 2Verify signed
Host, method, path, query, and payload hash exactly match what is transmitted on the wire. - 3Confirm credential scope (
YYYYMMDD/region/service/aws4_request) matches the final endpoint and operation. - 4Eliminate intermediary header or query mutation, or move signing to the final outbound hop.
Step-by-Step Diagnosis for Signature Does Not Match
- 1Capture request ID,
x-amz-date, signed headers list, credential scope, and the final HTTP method, host, path, and query from the failing request. - 2Compare the canonical request string used by the signer against the actual on-wire request bytes.
- 3Inspect URL encoding differences for reserved characters in canonical URI and canonical query string.
- 4Check reverse proxy/CDN behavior for host normalization, header folding, path rewriting, or query mutation after signing.
- 5Retest the same call without intermediaries to isolate whether the signer or the transport path changed the request.
Seen in Production
- -A backend release changes the final S3 endpoint to a regional hostname, but the signer still scopes the request for the previous region, so every write starts failing with
SignatureDoesNotMatch. - -A proxy rewrites the
Hostheader or normalizes the path after the app signs the request, so AWS receives different canonical inputs than the signer used. - -A presigned URL is generated for
PUTwith one content type, but the browser sendsPOSTor different headers after client-side wrapper changes. - -One worker shard loads the wrong secret access key after rotation while the access key ID remains unchanged, so only that shard returns signature mismatch errors.
Canonical Request and Wire Diff
- -Diff canonical URI, canonical query, and signed headers against wire-level request bytes (example:
%2Fnormalization differences change canonical path hash). - -Inspect intermediaries for header or query rewrites after signing (example: proxy rewrites
Hostwhilehostremains inSignedHeaders).
Scope, Secret, and Endpoint Alignment
- -Verify credential scope tuple and endpoint alignment (example: signing scope uses
us-east-1/s3while request is sent to another region endpoint). - -Prove the secret access key actually matches the access key ID used by the signer (example: rotated secret value never reached one worker even though the key ID stayed constant).
Decision Shortcut: Wrong Secret vs Mutated Request
- -If AWS CLI or an official SDK succeeds from the same runtime with the same identity, suspect canonicalization or on-path mutation before rotating credentials again.
- -If only one shard or environment fails while the same code path works elsewhere, compare final host, path, and secret source before debugging business logic.
- -If presigned URLs fail only after a browser, CDN, or upload proxy touches the request, prioritize method/header/path drift over IAM or account settings.
Wrong Fix to Avoid
- -Do not broaden IAM permissions when AWS is rejecting the signature before authorization is evaluated.
- -Do not keep retrying the same broken signed request; repeated sends of the same canonical mismatch will never self-heal.
- -Do not debug application payload semantics first if the canonical method, host, or query bytes are already wrong.
Implementation Examples
<Error>
<Code>SignatureDoesNotMatch</Code>
<Message>The request signature we calculated does not match the signature you provided.</Message>
<StringToSign>AWS4-HMAC-SHA256
20260415T074500Z
20260415/eu-west-1/s3/aws4_request
...</StringToSign>
</Error>AWS_REGION=eu-west-1 aws s3api head-object \
--bucket example-bucket \
--key reports/2026-04-15.csv \
--debug 2>&1 | rg 'CanonicalRequest|StringToSign|Authorization|SignatureDoesNotMatch'env | rg '^AWS_'
curl -v https://s3.eu-west-1.amazonaws.com/example-bucket/reports/2026-04-15.csv 2>&1 | rg '< Host:|> Host:'
aws sts get-caller-identityIncident Timeline
07:42 UTC
A deploy changes the request boundary without changing the signer assumptions
Signal: An endpoint, proxy, CDN rule, or secret rollout changes shortly before the first signature mismatch spike appears.
Why it matters: The first useful question is not “which API failed?” but “which canonical input changed between signer and AWS?”.
07:45 UTC
AWS receives bytes that no longer match the original canonical request
Signal: Logs or S3 error payloads show signature mismatch while one of host, method, query, payload hash, or credential scope differs from the signer output.
Why it matters: At this point the incident usually splits into two branches: wrong secret/scope vs mutated on-wire request.
07:49 UTC
Blind retries repeat the same broken signature
Signal: Retry middleware resends the same signed request or regenerates it with the same wrong scope, and every attempt fails identically.
Why it matters: SignatureDoesNotMatch is a contract bug, not a transient outage. The request must be re-signed with correct inputs.
07:57 UTC
The signer is aligned with the final outbound request and traffic recovers
Signal: The app signs against the final host, path, headers, and secret source, and the exact call starts succeeding without IAM changes.
Why it matters: That confirms the failure lived in signing inputs or transit mutation rather than authorization or business logic.
Seen in Production
Custom signer sorts query params differently than AWS canonical rules
Frequency: common
Example: Presigned URL works in staging but fails in production when extra query params are appended.
Fix: Use SDK presigner or enforce exact canonical query ordering and encoding in custom tooling.
Edge proxy rewrites Host header after request signing
Frequency: common
Example: Service signs against internal hostname, but outbound gateway rewrites host to public endpoint.
Fix: Sign with final outbound host or disable host rewrite on signed AWS traffic.
Signer uses the wrong region or service scope after endpoint migration
Frequency: medium
Example: Requests still sign for us-east-1/s3 while traffic now goes to a regional endpoint in another region.
Fix: Derive signing scope from the final endpoint and assert scope-to-endpoint parity in tests.
One shard loads the wrong secret after key rotation
Frequency: medium
Example: Access key ID remains correct but one worker keeps an old secret value in cache, so only that shard returns SignatureDoesNotMatch.
Fix: Invalidate secret caches and verify key ID plus secret pair integrity on every worker after rotation.
Wrong Fix vs Better Fix
Rotate permissions vs diff the canonical request
Wrong fix: Change IAM policies because the request is being rejected by AWS.
Better fix: Diff canonical request inputs, final wire bytes, and credential scope before touching authorization.
Why this is better: AWS has not reached the authorization phase yet. Policy changes only add noise until the signature matches.
Retry the same request vs re-sign with corrected inputs
Wrong fix: Let retries resend the same broken signature until the error clears.
Better fix: Fix host, path, headers, scope, or secret source, then generate a fresh signature from the corrected request.
Why this is better: Signature mismatch is deterministic for a given set of inputs. A fresh send only helps after the signing contract is repaired.
Debug handler output vs debug the signed transport boundary
Wrong fix: Start from application business logic or payload semantics before checking the signed request bytes.
Better fix: Capture the final outbound method, host, path, query, signed headers, and payload hash from the failing runtime first.
Why this is better: The fastest fixes come from proving what AWS actually received, not from reasoning abstractly about the intended request.
Debugging Tools
- -AWS SDK SigV4 debug logs
- -AWS CLI --debug
- -Canonical request diff tooling
- -Reverse proxy raw-header capture
- -CloudTrail request correlation
How to Verify the Fix
- -Replay the same API call and confirm SignatureDoesNotMatch is cleared.
- -Verify the final outbound method, host, path, query, and signed header set match the signer output in the fixed path.
- -Verify downstream authorization now evaluates normally (no fallback auth errors).
- -Confirm presigned URLs succeed through the same browser or proxy path that previously failed.
- -Track authentication error metrics and ensure signature mismatch rate returns to baseline.
How to Prevent Recurrence
- -Standardize all signing through maintained SDK clients and remove custom signer forks.
- -Sign requests as close to the final outbound hop as possible when proxies or gateways can mutate headers or paths.
- -Add integration tests that compare canonical request generation across languages/services.
- -Add deploy-time checks for region/service scope drift and endpoint rewrites on signed AWS traffic.
- -Monitor signature failure telemetry by endpoint and deploy version to catch regressions early.
Pro Tip
- -record the canonical request string hash in debug logs (not the secret) to rapidly diff signer output across services.
Decision Support
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.