Hey folks, hoping someone can shed some light on a Sigstore/Rekor quirk that's been bugging me for a few days. I've been setting up artifact signing for my little home lab's agent workloads, specifically the containers I'm building for Nano-Claw on a couple of older Raspberry Pi 4s. I'm using `cosign` and everything works... except the timestamps in the Rekor transparency log are consistently showing up hours off from my local time.
I'm meticulous about time sync on my devices—I'm running `chronyd` and everything reports correct, synchronized UTC. My `date -u` on the build machine matches what I expect. But when I push a signed artifact and then pull the entry from Rekor, the timestamp in the log's `integratedTime` field is several hours behind. It's not a huge operational blocker, but it's throwing off my little verification scripts that check the recency of builds, and honestly, it just *bugs* me not to understand why.
Here's what I've checked so far:
* My system clock and timezone (set to UTC) are correct.
* The `cosign` command itself doesn't seem to have a flag to influence this timestamp at the point of signing.
* I've queried a few different public Rekor instances (like `rekor.sigstore.dev`) and they all show the same offset for my entries.
My gut feeling is this is probably a simple timezone parsing or representation issue somewhere between the client and the log server, but I can't pinpoint it. Has anyone else in the home-lab/self-hosting crowd run into this? Did you find a way to reconcile it, or is it just something we live with? I'd love to get my SBOM and signing logs perfectly tidy.
- Sue
My uptime is measured in grace.
The discrepancy you're seeing likely stems from where the timestamp is generated. The `integratedTime` in a Rekor entry isn't stamped by your client, it's set by the Rekor server when the entry is added to the Merkle tree. Your local system time is only used for the signature's timestamp within the signed payload itself.
You should verify the timestamps in the actual signed artifact payload against the Rekor log's inclusion time. They're separate values. A common pitfall is scripts checking only the `integratedTime` for recency, which reflects server processing, not the exact signing moment. The public Rekor instances you queried are probably all in a single geographic region, explaining the consistent offset.
For your verification scripts, you need to extract the signing time from the signed payload. You can use `cosign verify` with the `--certificate-identity` and `--certificate-oidc-issuer` flags to get the full verification output, which includes the precise signing time from the Fulcio certificate. That's the timestamp you should be comparing.
Show me the threat model.
Oh, that makes so much sense, thank you! I was getting hung up on the wrong timestamp entirely. I've been staring at the `integratedTime` in my little scripts.
So the *real* signing time is tucked away in the certificate from Fulcio? That's a huge help. I'll try that `cosign verify` command you mentioned. Does it usually show up clearly in the output, or do I need to parse the certificate myself?
Exactly. The crucial point is that `integratedTime` is a server-side administrative timestamp for log inclusion, not an assertion about the artifact's validity period. Relying on it for recency checks introduces a subtle risk.
If your verification logic depends on a timestamp, you must use the one baked into the signature's cryptographic binding, which is the Fulcio certificate's `NotBefore`. That's the only time the signer actually attested to. The offset you're seeing isn't a bug, it's a design feature separating proof-of-existence from proof-of-intent.
But this leads to a larger issue: how do you verify the signer intended the artifact to be valid *now* if the signing event happened hours ago, perhaps in a different timezone? The temporal gap between Fulcio issuance and Rekor inclusion creates a window where a signature is technically valid but the signer's context may have changed. Most teams ignore this, but for high-velocity deployments, it's a real gap.