--- title: Image Signature Verification description: 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. component: devops page_id: devops::docker-images/imageSignatureVerification canonical_url: https://developer.pingidentity.com/devops/docker-images/imageSignatureVerification.html llms_txt: https://developer.pingidentity.com/devops/llms.txt docs_for_agents: https://developer.pingidentity.com/build-with-ai/docs-for-agents.md section_ids: devops-image-signature-verification: Image signature verification devops-image-signature-verification-summary: Summary devops-image-signature-verification-details: Details devops-image-signature-verification-steps: Verification steps devops-image-signature-step-1: Step 1 — Download and verify the public key fingerprint devops-image-signature-step-2: Step 2 — Pull the image and get its digest devops-image-signature-step-3: Step 3 — Verify the image signature devops-image-signature-expected-output: Expected output devops-image-signature-common-errors: Common errors devops-image-signature-which-images: Which images are signed? --- # 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](https://docs.sigstore.dev/cosign/system_config/installation/). As recommended by [Sigstore](https://github.com/sigstore/cosign), 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 ```shell 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. ```shell 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 ```shell cosign verify \ --key ping-cosign-prod-v1.pub \ --insecure-ignore-tlog \ docker.io/pingidentity/pingfederate@sha256: ``` Example using PingDirectory 2605: ```shell 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: ```json 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 | | -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `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](flexImages.html) are also signed using the same key.