Signing key validity in README is overestimated

In https://github.com/anomalizer/ngx_aws_auth#security-considerations

Note that signing keys have a validity of just one week.

In my experience, they are valid for the date of signing key generation only, as they are date specific.

If you attempt to use a signing key generated on the day before, you will get a 400 Bad Request from S3 due to:

<Error><Code>AuthorizationHeaderMalformed</Code><Message>The authorization header is malformed; Invalid credential date. Date is not the same as X-Amz-Date.</Message>...

Verified over 2 days, in a container with a UTC timezone. Making requests against nginx right after midnight UTC fail, re-running generate_signing_key (well, my ported variant of it, identical in nature with test coverage) and reloading nginx allows successful requests to occur again.

Should the README be adjusted...?

anyone encounter this issue as well? I thought the signing key is suppose to last for a week

It's also possible users will need to follow this workaround for "dynamic upstreams", https://tenzer.dk/nginx-with-dynamic-upstreams/ - still waiting to see if it yields the results I expect or not but promising so far.

@CpuID can u explain more about your solution or provide with an example conf?

thanks

@melkayam92 https://tenzer.dk/nginx-with-dynamic-upstreams/ Ctrl+f "The free alternative". Basically change the proxy_pass to that. Article explains the rationale, tl;dr - nginx DNS resolution doesn't honor TTLs by default.

I can confirm I haven't been able to repro the issues I had since doing this.

@CpuID thanks, so basically u regenerate key every day + the dynamic upstreams?

But I still don't understand wats the DNS resolution has to do with key expire issue?

@melkayam92 yep got a crontab on midnight UTC currently to rotate it, plus dynamic upstreams.

Unconfirmed, but a theory I had is maybe AWS cycle out the S3 backend instances at midnight UTC instead of rotating the keys on the existing instances... 🤷‍♂ :)

Damn, my crontab alone didn't seem to resolve this entirely, managed to get the The authorization header is malformed; Invalid credential date. Date is not the same as X-Amz-Date. error again.