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: March 23, 2026|Editorial standard: source-backed technical guidance
What Does Signature Does Not Match Mean?
Signature verification failed after AWS reconstructed the canonical request, so authenticated API traffic is blocked until signing inputs, credential scope, and request transit behavior are aligned.
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.
How to Fix Signature Does Not Match
- 1Generate the request using an official AWS SDK to avoid manual canonicalization bugs.
- 2Verify signed
Host, path, query, and payload hash exactly match what is transmitted. - 3Confirm credential scope (
YYYYMMDD/region/service/aws4_request) matches endpoint and operation. - 4Regenerate signature with known-good credentials and resend without intermediary header mutation.
Step-by-Step Diagnosis for Signature Does Not Match
- 1Capture request ID,
x-amz-date, signed headers list, and credential scope from the failing request. - 2Compare canonical request string used by client against 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, or query rewrites.
Canonical Request 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).
SigV4 Scope and Time Checks
- -Verify credential scope tuple and endpoint alignment (example: signing scope uses
us-east-1/s3while request is sent to another region endpoint). - -Audit signing timestamp and clock skew boundaries (example: skewed node clock triggers signature-adjacent failures near
RequestTimeTooSkewed).
How to Verify the Fix
- -Replay the same API call and confirm SignatureDoesNotMatch is cleared.
- -Verify downstream authorization now evaluates normally (no fallback auth errors).
- -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.
- -Add integration tests that compare canonical request generation across languages/services.
- -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
Compare Guide
401 Unauthorized vs 403 Forbidden: Auth vs Access Denied
Fix 401 Unauthorized vs 403 Forbidden by separating authentication failures from authorization denials, then apply the right login or permission fix fast.
Compare Guide
403 Forbidden vs 404 Not Found: When to Hide Resources
Use 403 for explicit access denial, or 404 to conceal resource existence when security policy requires reducing endpoint and object enumeration risk.
Playbook
Auth Incident Playbook (401 / UNAUTHENTICATED)
Use this playbook to separate missing, expired, or invalid identity proof from authorization and transport failures, and apply credential-source-correct fixes safely.
Playbook
Authorization Denial Playbook (403 / AccessDenied / PERMISSION_DENIED)
Use this playbook to triage policy-based access denials after authentication succeeds, isolate the deny layer, and apply least-privilege remediation safely.
Official References
Provider Context
This guidance is specific to AWS services. Always validate implementation details against official provider documentation before deploying to production.