Image Signature Verification

Image signature verification

Summary

For verification of Ping container images, use the Cosign utility along with the published Ping image signing trust material to verify by image digest. This process ensures the provenance of the image. If your environment requires policy enforcement, add verification to your promotion or deployment pipeline before the image is admitted to production.

Details

Provenance of software artifacts is a key component of ensuring the integrity and security of your environments. Container images are no different, and Ping recognizes this requirement and has taken steps to ensure your confidence.

Ping container images were historically signed using Docker Content Trust, which Docker deprecated in 2025. As of May 2026, Ping container images published to Docker Hub are signed with a utility known as Cosign using a managed KMS-backed signing key.

These Cosign signatures provide an extra layer of security, ensuring that images you pull were built and published by Ping. The following sections outline what Ping is doing and how you as a consumer of Ping container images can ensure that you are using our images.

The necessary information you will need to verify images can be found at two locations:

The first link includes verification details for Ping product zip files as well as container images. The second link contains the public key needed to validate the images. This information will be kept current; if the signing key is rotated in the future, these files will be updated with the new public key and fingerprint. Any such changes will be announced in multiple channels when they happen.

Verification uses the public key corresponding to the private key active at the time the image was signed. Ping has implemented asymmetric KMS-backed verification as its method of validation. To verify images, you will need the Cosign application installed.

As recommended by Sigstore, signing is performed on the digest rather than a tag, meaning that you should also verify by digest. While tags can move, a digest identifies the exact image manifest that was signed.

Since Ping signs with a private key rather than Sigstore’s keyless flow, no entries are written to the Rekor transparency log. This practice is why --insecure-ignore-tlog is required in all cosign verify commands below.

Signatures include an optional set of annotations:

signer.key.label — the alias associated with the signing key; useful for troubleshooting and human recognition, not a security gate
signer.key.fingerprint.sha256 — the SHA-256 fingerprint of the public key; can be used to confirm you have the correct public key

Verification steps

Step 1 — Download and verify the public key fingerprint

curl -O https://download.pingidentity.com/public/ping-cosign-prod-v1.pub

openssl pkey -pubin -in ping-cosign-prod-v1.pub -outform DER | \
  openssl dgst -sha256 | awk '{print $2}'
# Expected: a0047fc42c554bc105fed4642bab36eb1f5871b810a2c5115664f508958fe586

Step 2 — Pull the image and get its digest

PingFederate 2605 is used as an example.

docker pull pingidentity/pingfederate:2605
docker inspect --format='{{index .RepoDigests 0}}' pingidentity/pingfederate:2605
# or if you have crane installed
crane digest docker.io/pingidentity/pingfederate:2605

Step 3 — Verify the image signature

cosign verify \
  --key ping-cosign-prod-v1.pub \
  --insecure-ignore-tlog \
  docker.io/pingidentity/pingfederate@sha256:<digest>

Example using PingDirectory 2605:

cosign verify \
  --key ping-cosign-prod-v1.pub \
  --insecure-ignore-tlog \
  docker.io/pingidentity/pingdirectory@sha256:f9a83da90d2fd254f9b95b0f30148edaac61bb2a2dce2c1cf65a532f12320d1a

Expected output

A successful verification produces output similar to the following. The only difference from actual output is that the JSON block has been formatted for easier readability:

Verification for docker.io/pingidentity/pingdirectory@sha256:f9a83da90d2fd254f9b95b0f30148edaac61bb2a2dce2c1cf65a532f12320d1a --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - The signatures were verified against the specified public key

[
  {
    "critical": {
      "identity": {
        "docker-reference": "index.docker.io/pingidentity/pingdirectory"
      },
      "image": {
        "docker-manifest-digest": "sha256:f9a83da90d2fd254f9b95b0f30148edaac61bb2a2dce2c1cf65a532f12320d1a"
      },
      "type": "cosign container image signature"
    },
    "optional": {
      "signer.key.fingerprint.sha256": "a0047fc42c554bc105fed4642bab36eb1f5871b810a2c5115664f508958fe586",
      "signer.key.label": "alias/product-container-image-production-signing-key"
    }
  }
]

Some images published before June 2026 had duplicate signatures applied during pipeline processing. If you see repeated output blocks, there is no security concern; the pipelines have since been corrected.

Common errors

Error Meaning

Error	Meaning
`no signatures found`	Image is not signed — confirm you are using a multi-arch manifest tag, not a per-arch tag.
`no matching signatures`	Wrong public key — re-download from the canonical URL above and verify the fingerprint.
`error: signing config or tlog errors`	Transparency log lookup failed. Ping images are signed with a private key and have no Rekor entry. Add `--insecure-ignore-tlog` to your `cosign verify` command.

no signatures found

Image is not signed — confirm you are using a multi-arch manifest tag, not a per-arch tag.

no matching signatures

Wrong public key — re-download from the canonical URL above and verify the fingerprint.

error: signing config or tlog errors

Transparency log lookup failed. Ping images are signed with a private key and have no Rekor entry. Add --insecure-ignore-tlog to your cosign verify command.

Which images are signed?

Signed images are multi-arch manifests published to Docker Hub and archived images in Artifactory, beginning with the 2605 sprint release. Flex images are also signed using the same key.

Ping Identity Devops

Image Signature Verification