-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Signing key validity in README is overestimated #69
Comments
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 |
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 |
In https://github.com/anomalizer/ngx_aws_auth#security-considerations
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: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...?
The text was updated successfully, but these errors were encountered: