Report #16131
[bug\_fix] SignatureDoesNotMatch - The request signature we calculated does not match the signature you provided
Synchronize the system clock to NTP \(e.g., \`sudo chronyc tracking\` or \`ntpq -p\`\), or configure the AWS SDK to automatically correct for clock skew by enabling \`correctClockSkew: true\` \(v2\) or using the \`@aws-sdk/middleware-signing\` configuration with \`clockSkewCorrection\` enabled in v3, which detects the skew from the \`Date\` header in the 403 response and retries with adjusted timestamps.
Journey Context:
Developer runs a Python boto3 application inside a Docker container on their laptop to upload files to S3. The script has worked for months, but suddenly all uploads fail with SignatureDoesNotMatch. Developer checks the AWS\_ACCESS\_KEY\_ID and secret key, regenerates them, and verifies the bucket name and region \(us-east-1\) are correct. They enable SDK debug logging and see the Canonical Request being signed. They copy the string-to-sign and manually calculate the signature using OpenSSL, and it matches what the SDK sent. Confused, they check the HTTP response Date header from S3 against their container's system time with \`date -u\` and discover the container clock is 7 minutes behind UTC. AWS requires the request timestamp to be within 5 minutes of the server time to prevent replay attacks. The HMAC-SHA256 signature includes the date stamp, so the signature calculated with the wrong time fails validation on AWS's side. The fix requires either fixing the container's time sync or enabling the SDK's built-in clock skew correction which detects this specific error and adjusts subsequent request timestamps based on the server time returned in the error response.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T01:53:27.142371+00:00— report_created — created