AWS SDK Error - Signature not yet current

问题:

I'm using the aws-sdk-php, the SesClient specifically, i've deployed an app in a customer server (hosted in DreamHost) and I'm getting this error:

Signature not yet current: 20130909T170846Z is still later than 20130909T170823Z (20130909T170323Z + 5 min.)

I'm guessing the server time is misconfigured, I'm trying to reach DH support to check on that, i bet that will take a while.

Any other ideas? The app has been deployed many times before and i've never seen this error.

回答1:

It seems that it's just a system date misconfiguration, check this

https://forums.aws.amazon.com/thread.jspa?threadID=103764#

That guy had the same issue.

回答2:

I had the similar issue. I was running my CI server from an Ubuntu EC2 instance and that has the time out of sync. I synchronised the time with NTP suing

sudo ntpdate ntp.ubuntu.com

It started working fine.

回答3:

I had the same issue recently. I did the following

sudo ntpd -q -g

The -g option is needed if your clock is way out of sync. It forces ntpd to continue till it's in sync.

回答4:

I just encountered the same problem with a Django app deployed to AWS. The site error was really vague, but the error log that was emailed to me said, "JSONResponseError: JSONResponseError: 403 Forbidden {'message': 'Signature not yet current: 20150224T185106Z is still later than 20150224T185033Z (20150224T184533Z + 5 min.)'}" after a file path that pointed to Boto and Elastic Transcoder. Do the following on the server:

1. ntpq -p will tell you if you have ntp installed
2. If you don't have ntp, do sudo apt-get install ntp
3. sudo service ntp stop
4. sudo ntpdate -s us.pool.ntp.org will align your server's time with atomic clocks in the U.S. (this will need to be adjusted to your country)
5. sudo service ntp start

Good luck! You can read more here: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html#configure_ntp

回答5:

Just need to be sure the time of you server is 5 minutes accuracy from current time. check the AM or PM time.

回答6:

I faced similar issue and after some investigation, found the root cause.

Reason was that, my AWS instance/server timezone and my local system timezone from where i was making RESTful call were different. AWS assumes that request is also being made from the same timezone (it just ignore gap of 5 mins, not more than that). I was able to validate this by making test call from the AWS console and checking details in the logs (giving below Java snippet)

private String getDateString() {
    Calendar cal = Calendar.getInstance();
    DateFormat dfm = new SimpleDateFormat("yyyyMMdd'T'HHmmss'Z'");
    dfm.setTimeZone(TimeZone.getTimeZone("UTC"));  //server timezone
    return dfm.format(cal.getTime());
}