Verify Component Versions

Sigstore (keyless)

Verify a Sigstore keyless signature. There’s no public key to install on this side either — you tell OCM which identity you trust, and it checks the signature was made by that identity.

If you’ve done classical key-based verification, here’s what changes:

Mental model: instead of asking “does this signature match the public key I was handed?” you ask “was this signed by jane.doe@example.com logging in via GitHub?” The verifier only needs to know who to trust.

You’ll end up with#

• Confidence that a component version was signed by an identity you trust

Estimated time: ~3 minutes

Prerequisites#

• OCM CLI installed
• A component version signed with Sigstore (see How-To: Sign Component Versions)
• The expected signer identity (their OIDC email and which provider they logged in with)

Steps#

1. Declare which identity you trust#

   In Sigstore, the verifier’s only job is to decide whose signatures to accept. You do that with a small spec file.

   Two values matter:

   • certificateIdentity — the email or workload identity of whoever signed (e.g. jane.doe@example.com)
   • certificateOIDCIssuer — which OIDC provider they logged in with (e.g. GitHub vs. Google — both could have a jane.doe@example.com)

   Create sigstore-verify.yaml:

   # sigstore-verify.yaml
   type: SigstoreVerificationConfiguration/v1alpha1
   certificateOIDCIssuer: https://github.com/login/oauth
   certificateIdentity: jane.doe@example.com

   That’s the entire trust configuration. No public key to fetch, no certificate to install.

   Pick the right certificateOIDCIssuer value

   On public Sigstore (oauth2.sigstore.dev), the issuer recorded in the signing certificate is the upstream identity provider’s issuer URL — not the Sigstore Dex endpoint. Pick the one matching the provider the signer logged in with:

   Signer logged in via	certificateOIDCIssuer value
   Google	https://accounts.google.com
   GitHub	https://github.com/login/oauth
   Microsoft	https://login.microsoftonline.com

   Both certificateOIDCIssuer and certificateIdentity are required. They’re what makes the signature meaningful — without them you’d be accepting any Sigstore signature from anyone.

2. Verify the component version#

   Run the verify command with the verifier spec:

   Local CTF Archive

   ocm verify cv \
     --verifier-spec ./sigstore-verify.yaml \
     /tmp/helloworld/transport-archive//github.com/acme.org/helloworld:1.0.0

   Remote OCI Registry

   ocm verify cv \
     --verifier-spec ./sigstore-verify.yaml \
     ghcr.io/<my-namespace>//github.com/acme.org/helloworld:1.0.0

   Expected output

   time=2026-05-19T18:49:13.316+02:00 level=INFO msg="verifying signature" name=default
   time=2026-05-19T18:49:13.856+02:00 level=INFO msg="signature verification completed" name=default duration=539.512209ms
   time=2026-05-19T18:49:13.856+02:00 level=INFO msg="SIGNATURE VERIFICATION SUCCESSFUL"

3. Verify a specific signature#

   If the component carries multiple signatures (e.g. an RSA signature and a Sigstore signature), select one with --signature:

   ocm verify cv \
     --verifier-spec ./sigstore-verify.yaml \
     --signature sigstore \
     ghcr.io/<your namespace>//github.com/acme.org/helloworld:1.0.0

   The verifier spec’s type field decides which verifier handles the signature. The --signature flag picks which signature on the component to verify.

Inspect the recorded identity (optional)#

If verification fails because of an identity mismatch, you can read the identity directly from the signature to see what to put in your spec:

ocm get cv /tmp/helloworld/transport-archive//github.com/acme.org/helloworld:1.0.0 -o yaml \
  | yq '.[0].signatures[] | select(.signature.algorithm == "sigstore")'

Look for the signer email and the OIDC issuer URL. Those are exactly what certificateIdentity and certificateOIDCIssuer are matched against.

Troubleshooting#

Symptom: “no matching CertificateIdentity found”#

Cause: The signature was made by a different identity than what your spec expects — or the same identity but via a different OIDC provider.

The full error names which side did not match. For an identity mismatch:

Error: SIGNATURE VERIFICATION FAILED: cosign verify-blob failed: exit status 1
stderr: Error: failed to verify certificate identity: no matching CertificateIdentity found, last error: expected SAN value "nobody@nowhere.invalid", got "john.doe@gmail.com"

For an issuer mismatch:

Error: SIGNATURE VERIFICATION FAILED: cosign verify-blob failed: exit status 1
stderr: Error: failed to verify certificate identity: no matching CertificateIdentity found, last error: expected issuer value "https://accounts.google.com", got "https://github.com/login/oauth"

Fix: Inspect the signature (see above) to read the actual identity, and update certificateIdentity / certificateOIDCIssuer to match. Watch for trailing slashes and capitalization.

Symptom: “keyless verification requires both an issuer constraint … and an identity constraint”#

Cause: Your verifier spec is missing certificateIdentity, certificateOIDCIssuer, or both.

The full error:

Error: SIGNATURE VERIFICATION FAILED: invalid verification config: keyless verification requires both an issuer constraint (CertificateOIDCIssuer or CertificateOIDCIssuerRegexp) and an identity constraint (CertificateIdentity or CertificateIdentityRegexp)

Fix: Both are mandatory — they’re how Sigstore knows whose signatures to accept. See Step 1 above.