Signature validity window

What this check verifies

The validity window is the gap between created and expires. This check measures it and warns when it is longer than about one hour (3600 seconds). A window inside that bound passes; a longer one raises an advisory warning.

;created=1717603200;expires=1717606800;...

In the example above the window is exactly one hour. This is advisory: a long window is not a protocol violation and does not fail the check or make the signature invalid. The checker only flags it as something worth a second look.

Why it matters

expires bounds how long a captured signature can be replayed. The longer the window, the longer a copied signature stays usable if it leaks. A short window keeps that exposure small; an hours-long or days-long window widens it for no clear benefit, since a signed request is usually sent within seconds of being signed.

There are legitimate reasons for a wider window, such as pre-signing requests that sit in a queue before sending, or tolerating large clock skew across systems. That is why this is a warning and not a failure: the checker surfaces the long window so an operator can confirm it is intentional rather than an oversight.

How to fix it

This is advisory, so no fix is required for the grade. To clear the warning, shorten the window:

1. Set expires only as far past created as you need to cover the delay between signing and the request arriving.
2. For requests sent right after signing, a window of seconds to a few minutes is usually enough.
3. If you need a longer window for queuing or skew reasons, keep it as the documented exception and pair it with replay protection (a nonce or per-request freshness) so the wider window does not become a wider replay opportunity.

References

• RFC 9421 defines created and expires, which bound the validity window.
• Replay and freshness covers the related replay-protection advisory.
• How grading works explains how advisory warnings affect the score.