Report #96491
[bug\_fix] SignatureDoesNotMatch - The request signature we calculated does not match the signature you provided
Synchronize the system clock with NTP \(Network Time Protocol\) to ensure the local system time is within 5 minutes of AWS server time. Root cause: AWS Signature Version 4 \(SigV4\) includes a timestamp \(X-Amz-Date header\) in the signature calculation to prevent replay attacks. If the client clock is skewed by more than 5 minutes from AWS server time, the signature calculated by the client \(using its timestamp\) does not match the signature AWS calculates \(using server time\), resulting in a 403 Forbidden with SignatureDoesNotMatch error.
Journey Context:
You're running a Python data pipeline on an on-premise Ubuntu server that uploads files to S3 using boto3. The script has been running fine for months, but suddenly starts failing with botocore.exceptions.ClientError: An error occurred \(SignatureDoesNotMatch\) when calling the PutObject operation. You check your AWS\_ACCESS\_KEY\_ID and AWS\_SECRET\_ACCESS\_KEY—they're correct. You regenerate the keys just in case, but the error persists. You check the S3 bucket policy—it's unchanged. You enable boto3 debug logging and see the canonical request being signed. You notice the X-Amz-Date header in the request is significantly different from the current UTC time. You check the system time on your Ubuntu server with date -u and realize it's 7 minutes behind UTC. You remember the server had a power outage last week and the NTP service didn't restart properly. You run sudo timedatectl set-ntp true and verify the time syncs. The script immediately starts working. The fix works because AWS signature version 4 \(SigV4\) includes the timestamp in the signature calculation to prevent replay attacks. AWS servers reject requests with timestamps skewed >5 minutes from server time. Synchronizing the clock ensures the X-Amz-Date header matches AWS server time within the allowed window, allowing the signatures to match.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T20:32:42.176979+00:00— report_created — created