No. Sigstore certificates are short lived by design, but the signature stays verifiable because a log entry or timestamp proves it was made while the certificate was valid. A verifier asks whether the certificate was valid at signing time, not whether it is valid today.
Why certificates expire fast
Traditional signing relies on long lived keys and revocation lists. Sigstore's documentation says Fulcio was designed to avoid revocation by issuing short lived certificates instead. The signer generates a keypair in memory, gets a certificate binding that key to an identity, signs, and the private key is gone. The docs say the private key never touches disk and is never known to Sigstore services.
The gitsign README gives a concrete figure for the public instance: certificates last about ten minutes.
Proof of when
A ten minute certificate would be useless for verification next week unless there is evidence of when signing happened. That evidence comes from:
| Evidence | What it shows |
|---|---|
| Rekor log entry with signed entry timestamp | The signing event was recorded at a time inside the validity window |
| Inclusion proof | The entry is really in the append only log |
| RFC 3161 timestamp (optional) | A third party timestamp of the signature |
The bundle specification requires one of these timestamp forms when short lived certificates may be verified after they expire. The security documentation adds a caution: log timestamps are hard to forge over the long term, but short time windows are more exposed to a dishonest log operator, which is why monitoring matters.
What verifiers check
- The certificate chains to a trusted Fulcio root.
- The certificate identity and issuer match what you expect.
- The log entry or timestamp places signing inside the certificate's validity.
- The signature matches the artifact digest.
If you skip step 3, you will wrongly reject good old signatures. If you skip step 2, you accept signatures from anyone.
Practical guidance
- Keep the bundle, since it carries the verification material.
- Do not use expiry as a reason to re-sign everything on a schedule. Re-sign when the artifact changes.
- For long retention, make sure your verification tooling is updated so it still understands the trust roots.
- Remember keys: if you used your own key instead of keyless signing, expiry and rotation follow your key policy instead.
Where Safeguard fits
Safeguard's compliance and evidence automation can help retain release evidence, and SBOM scanning works on what you shipped regardless of when it was signed.
Quick check
Do I need to re-sign artifacts every ten minutes?
No. You sign once per artifact. The short lifetime applies to the certificate, and the log evidence keeps the signature checkable later.
What if the log is unavailable?
A bundle that already contains the log entry and timestamp lets a verifier check without a live call, though it still needs trusted roots.
Sources
Last reviewed: 19 October 2026.
