Created time not in the future

What this check verifies

The created parameter is a Unix timestamp, in seconds, for when the signature was produced. This check confirms it is not in the future. A small allowance for clock skew applies: created may be up to 300 seconds ahead of the verifier’s clock and still pass. Past that, the check fails.

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

The 300-second window absorbs ordinary clock drift between the signer and the verifier. It is not a license to backdate or postdate signatures; it is slack for unsynchronized clocks.

Why it matters

A signature created in the future is a sign of a clock problem or a tampered timestamp. If a verifier accepted far-future created values, a signer could mint signatures that stay valid long after they should, sidestepping the freshness that created and expires are meant to provide. Bounding created to roughly now keeps the validity window anchored to real time.

In practice, the usual cause of a failure here is a signer whose system clock is wrong, not an attack. Either way the verifier sees a timestamp it cannot trust.

How to fix it

1. Set created from a correct clock at signing time, in Unix seconds: the moment you sign, not a planned future send time.
2. Keep the signer’s clock in sync. Run NTP or an equivalent time service so the signer does not drift more than a few seconds from real time.
3. Sign close to send time. Do not pre-generate signatures with a created set well ahead of when the request will actually go out.

If the failure persists with a correct clock, check that you are writing seconds, not milliseconds; a millisecond value lands far in the future when read as seconds.

References

• RFC 9421 defines the created parameter and its role in signature validity.
• How grading works explains how a future created affects the grade.