Signature not expired

What this check verifies

The expires parameter is a Unix timestamp, in seconds, for when the signature stops being valid. This check confirms it has not already passed. The same 300-second clock-skew allowance applies as for created: expires may be up to 300 seconds behind the verifier’s clock and still pass. Past that, the signature has expired and the check fails.

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

The allowance absorbs clock drift so a signature does not get rejected for being a few seconds late on a verifier whose clock runs fast.

Why it matters

expires is the deadline that limits how long a captured signature stays useful. If a verifier ignored it, an old signature could be replayed indefinitely. Rejecting expired signatures keeps the window short and bounds the replay opportunity to the lifetime the signer chose.

Two common causes of a failure here. The signer set a very short window and the request arrived after it closed, often because of network or queue delay between signing and sending. Or the signer’s clock is wrong, so expires was already in the past when the request went out. The fix differs depending on which it is.

How to fix it

1. Set expires a sensible interval after created, long enough to cover the time between signing and the request reaching the verifier, but no longer than needed.
2. Sign close to send time so the window is not partly spent before the request leaves.
3. Keep the signer’s clock in sync with NTP or an equivalent, so expires reflects real time.

If you are signing well ahead of sending (for example pre-signing requests in a queue), widen the window or sign later. A very long window passes this check but trips the validity window advisory.

References

• RFC 9421 defines the expires parameter and signature validity.
• How grading works explains how an expired signature affects the grade.