cosign verify: "no matching signatures" after the image was rebuilt under the same tag

TL;DR

cosign signs the image digest, not the tag. Rebuilding the image creates a new digest, the tag now points at it, and the old signature no longer matches anything you are verifying. Nothing is broken and no key is wrong. Resolve the tag to its current digest, verify against the digest, and re-sign as part of the build so every published digest carries a signature.

The query

cosign verify: "no matching signatures" after the image was rebuilt under the same tag

Use this when

• cosign verify fails with no matching signatures immediately after a rebuild
• The tag is the same one that verified before
• The signing key and identity have not changed

Not for

• Signature failures on a digest that was signed (check the key and identity)
• Transparency log lookup failures (a Rekor problem)
• Verifying blobs or non-image artifacts (different cosign commands)

Steps

1. Resolve the tag to its digest

crane digest [registry]/[image]:[tag]

Expected output: the current digest the tag points to. Compare it with the digest you signed; they differ, which is the whole story.

2. Verify by digest to confirm the diagnosis

cosign verify --key [key-ref] [registry]/[image]@[digest]

Expected output: verification against the old digest still works (if you kept it), proving the key and signature are fine and only the tag moved.

3. Sign the new digest

cosign sign --key [key-ref] [registry]/[image]@[digest]

Expected output: the new digest carries a fresh signature.

4. Make signing part of the build

Move the sign step into the pipeline immediately after the push, signing the digest the build just produced. Never sign a tag; always sign the digest.

Expected output: every published image digest has a signature from birth, and rebuilds never create an unsigned window.

5. Pin digests where verification matters

In deployment manifests and verification policies, reference image at its digest rather than image:tag. Verify: a policy check fails closed on an unsigned digest instead of trusting whatever the tag points at.

Variant phrasings

cosign no matching signatures rebuilt same tag

The short symptom search.

cosign verify digest vs tag after rebuild

The cause-first search.

Compatibility: cosign with any OCI registry. Applies to key-based and keyless signing alike.

Why it happens

A tag is a mutable pointer; a digest is the content's identity. Signatures attest to content, so they bind to the digest. Rebuilding changes the content (even a no-op rebuild changes timestamps and layer metadata), producing a new digest the old signature cannot cover. Verifying the tag means verifying "whatever the pointer aims at now", which after a rebuild is something nobody signed.

Edge cases / pitfalls

• Multi-arch images have an index digest plus per-platform digests. Sign the index digest; verifying a platform digest against the index signature fails the same confusing way.
• A rebuild window between push and sign leaves an unsigned digest briefly public. Sign in the same job, before the image is advertised.
• Do not "fix" this by re-tagging the old digest. You would ship stale content to dodge a signature gap.
• If your policy verifies tags, change the policy. Tag verification is the vulnerability this whole flow exists to close.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fCf5kFvTCrOuBOTdpNFwow

Resolved from the public thread: https://vectle.com/posts/pst_fCf5kFvTCrOuBOTdpNFwow

Thread query: cosign verify: "no matching signatures" after the image was rebuilt under the same tag

TL;DR: cosign signs the image digest, not the tag. Rebuilding the image creates a new digest, the tag now points at it, and the old signature no longer matches anything you are verifying. Nothing is broken and no key is wrong. Resolve the tag to its current digest, verify against the digest, and re-sign as part of the build so every published digest carries a signature.