PacketSensei

AWS `SignatureDoesNotMatch`: What It Means and How to Fix It

PacketSensei

SignatureDoesNotMatch is the SigV4 signature failing to verify — almost always a malformed secret key, not a wrong one. It comes from All AWS APIs, and the message reads:

The request signature we calculated does not match the signature you provided.

If you are here mid-incident, skip to how to tell which cause you have — the command there narrows it down faster than reading the list.

Quick reference
Error SignatureDoesNotMatch
Service All AWS APIs
Message The request signature we calculated does not match the signature you provided.
Most common cause Trailing whitespace or a newline in the secret key

What it actually means

AWS recomputes the request signature from your secret access key and the canonical form of the request. A mismatch means one of the two inputs differs from what you think it is.

In practice it is nearly always the key material rather than the signing logic, and nearly always a whitespace or encoding problem rather than a genuinely wrong key. The message helpfully includes the string-to-sign AWS computed, which is worth comparing if you are implementing signing yourself.

Why it happens

Ranked by how often each one turns out to be the answer.

# Cause Fix
1 Trailing whitespace or a newline in the secret key The classic. A key copied into an environment variable, a .env file, or a Kubernetes secret with a trailing \n produces this every time. echo -n when creating secrets; check with `aws configure get aws_secret_access_key
2 The secret key was truncated or has a URL-encoded character Secret keys can contain / and +. A key passed through a URL, a shell without quoting, or a system that percent-encodes it will not verify.
3 Access key and secret key from different key pairs Mixing the access key ID of one credential with the secret of another. Regenerate both together.
4 A signed URL has expired or been altered Presigned S3 URLs carry the signature in the query string. Any change to the URL — an added tracking parameter, a proxy rewriting it, a mail client encoding it — invalidates it.
5 The clock is off A large skew produces RequestTimeTooSkewed, but a smaller one can surface here first depending on the service.
6 A proxy is modifying the request Anything that rewrites headers, changes the host, or re-encodes the path breaks the canonical request. Corporate TLS-inspecting proxies are the usual culprit.

How to tell which one you have

# Is there stray whitespace in the configured secret?
aws configure get aws_secret_access_key | xxd | tail -2   # look for a trailing 0a

# Does a minimal call work with the same credentials?
aws sts get-caller-identity

# See the canonical request the CLI builds.
aws s3 ls --debug 2>&1 | grep -A20 'CanonicalRequest'

If sts get-caller-identity succeeds and a specific service call fails, the credentials are sound and the problem is in that request — a proxy, a presigned URL, or a hand-rolled signer.

Preventing it

Stop handling long-lived access keys. On EC2 use an instance profile, on EKS use IAM Roles for Service Accounts or EKS Pod Identity, in CI use OIDC federation to assume a role. None of them involve a secret key that can acquire a trailing newline.

Where keys are unavoidable, inject them from Secrets Manager rather than copying them by hand.

Quota codes, limits and behaviour on this page were last checked against AWS documentation on 2026-08-22. AWS changes these; if something here does not match what you are seeing, trust the console and tell us.