Signature expired: is now earlier than error : InvalidSignatureException

后端 未结 10 2234
滥情空心
滥情空心 2020-12-05 04:45

I am trying a small example with AWS API Gateway and IAM authorization. The AWS API Gateway generated the below Endpoint :

https://xyz1234.execute-api.us-e         


        
相关标签:
10条回答
  • 2020-12-05 04:46

    Complementing what as @miked-at-aws post about AWS sigV4, There are at least 2 main possible route causes for the clock skew:

    1. your CPU is overloaded (reaching 99% usage or in EC2 instances with CPU limits that run out on CPU credits).

    Why would this generate the time skew? because when the amazon SDK creates the time stamp to the moment the request is sent, normally there shouldn't be more than just a few nano or micro seconds, but if your CPU is overwhelmed it may take it several seconds or even minutes in some cases to process, so for this root cause you will experience not a 100% events lost but just some x% that may not be too big.

    1. for the second root cause which is that your machine clock isn't just adjusted, well probably 100% of your events are being lost and you just have to make sure that your machine clock is being set and adjusted correctly.
    0 讨论(0)
  • 2020-12-05 04:50

    You need to synchronize your machines local clock with NTP.

    for eg. on an ubuntu machine:

    sudo ntpdate pool.ntp.org
    

    System time goes out of sync quite often. You need to keep them in sync periodically.

    You can run a daily CRON job to keep your system time in sync as mentioned at this link: Periodically synchronize time in Linux

    Create a bash script to sync time called ntpdate and put the below into it

    #!/bin/sh
    # sync server time
    /usr/sbin/ntpdate pool.ntp.org >> /tmp/ntpdate.log
    

    You can place this script anywhere you like and then set up a cron I will be putting it into the daily cron directory so that it runs once every day So my ntpdate script is now in /etc/cron.daily/ntpdate and it will run every day

    Make this script executable

    chmod +x /etc/cron.daily/ntpdate
    

    Test it by running the script once and look for some output in /tmp/ntpdate.log

    /etc/cron.daily/ntpdate
    

    In your log file you should see something like

    26 Aug 12:19:06 ntpdate[2191]: adjust time server 206.108.0.131 offset 0.272120 sec
    
    0 讨论(0)
  • 2020-12-05 04:52

    I was also facing this issue , added

    correctClockSkew: true

    and issue fixed for me

    const nodemailer = require('nodemailer');
    const ses = require('nodemailer-ses-transport');
    
    
    
    let transporter = nodemailer.createTransport(ses({
            correctClockSkew: true,
            accessKeyId: **,
            secretAccessKey: **,
            region: **
        }));
    
    0 讨论(0)
  • 2020-12-05 05:03

    I have face this same problem while fetching video from Amazon Kinesis to my local website. So, in order to solve this problem i have install crony in my computer.This crony solved my problem.You can see the Amazon crony installation in this following link. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html

    0 讨论(0)
  • 2020-12-05 05:04

    This one command did the trick

    sudo ntpdate pool.ntp.org
    
    0 讨论(0)
  • 2020-12-05 05:06

    A request signed with AWS sigV4 includes a timestamp for when the signature was created. Signatures are only valid for a short amount of time after they are created. (This limits the amount of time that a replay attack can be attempted.)

    When the signature is validated the timestamp is compared to the current time. If this indicates that the signature was not created recently, then signature validation fails with the error message you mentioned.

    A common cause of this is when the local clock on the host generating the signature is off by more than a couple of minutes.

    0 讨论(0)
提交回复
热议问题