Я использую aws-sdk-php
, SesClient специально, я развернул приложение на клиентском сервере (размещенном в DreamHost), и я получаю эту ошибку:
Signature not yet current: 20130909T170846Z is still later than 20130909T170823Z (20130909T170323Z + 5 min.)
Я предполагаю, что время сервера неверно сконфигурировано, я пытаюсь связаться с DH, чтобы проверить это, я уверен, что это займет некоторое время.
Любые другие идеи? Приложение было развернуто много раз раньше, и я никогда не видел эту ошибку.
Кажется, что это просто неправильная настройка даты системы, проверьте это
https://forums.aws.amazon.com/thread.jspa?threadID=103764#
У этого парня была такая же проблема.
У меня была аналогичная проблема. Я запускал свой CI-сервер из экземпляра Ubuntu EC2 и у меня время синхронизации. Я синхронизировал время с NTP suing
sudo ntpdate ntp.ubuntu.com
Он начал нормально работать.
Недавно у меня была такая же проблема. Я сделал следующее
sudo ntpd -q -g
Опция -g
необходима, если ваши часы не синхронизированы. Он заставляет ntpd
продолжать, пока он не синхронизируется.
Я просто столкнулся с той же проблемой с приложением Django, развернутым в AWS. Ошибка сайта была очень расплывчатой, но журнал ошибок, который был отправлен мне по электронной почте, сказал: «JSONResponseError: JSONResponseError: 403 Forbidden {'message': 'Подпись еще не указана: 20150224T185106Z по-прежнему позже 20150224T185033Z (20150224T184533Z + 5 мин.)' } "после пути к файлу, указывающего на Boto и Elastic Transcoder. Выполните следующие действия на сервере:
ntpq -p
сообщит вам, если вы установили ntp sudo apt-get install ntp
sudo service ntp stop
sudo ntpdate -s us.pool.ntp.org
будет выравнивать время вашего сервера с атомными часами в США (это нужно будет скорректировать в вашей стране) sudo service ntp start
Удачи! Вы можете прочитать больше здесь: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html#configure_ntp
Просто нужно быть уверенным, что время вашего сервера составляет 5 минут от текущего времени. проверьте время AM или PM.
Я столкнулся с подобной проблемой и после некоторого расследования нашел основную причину.
Причина в том, что мой часовой пояс AWS-экземпляра / сервера и мой локальный системный часовой пояс от того места, где я звонил RESTful, были разными. AWS предполагает, что запрос также производится из одного и того же часового пояса (он просто игнорирует разрыв в 5 минут, не более того). Я смог проверить это, выполнив тестовый вызов с консоли AWS и проверив данные в журналах (давая ниже фрагмент Java)
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()); }