Signed but untrusted is one of the most misunderstood C2PA outcomes. It does not mean the file is fake. It usually means cryptography succeeded while trust policy did not. Security and editorial teams see this status daily during pilots — often triggering unnecessary escalations until trust design is documented.
This article walks through signature validation versus trust evaluation, the role of X.509 chains, and practical steps to resolve or correctly accept untrusted outcomes in production workflows.
Valid signature versus trusted signer
Signature validation confirms that manifest bytes match the embedded signature and that the signing certificate was valid at signing time. Trust evaluation asks an additional question: does this certificate chain terminate on a source your organization recognizes?
Think of validation as “was this manifest tampered with since signing?” and trust as “do we accept this signer for publication?” A self-signed development certificate can pass the first test and fail the second — by design.
C2PA Signer separates these layers so reviewers can distinguish broken signatures from policy mismatches.
Signed but untrusted is often the correct outcome for sandbox keys, partner onboarding, or assets signed before your trust list was updated — not evidence of fraud.
Role of the X.509 certificate
C2PA signing identities are expressed through X.509 certificates. The certificate binds a public key to an issuer and subject name, with validity windows and key usage constraints. Reports should surface issuer, subject, serial number and validity dates for auditability.
Extended Key Usage (EKU) and certificate policies matter: a TLS web server certificate is not interchangeable with a document-signing identity. Verifiers and trust programs enforce these constraints to prevent key misuse across contexts.
When reviewing reports, capture certificate fingerprints and validity windows in your audit log — they are essential for incident response if a key is later compromised or revoked.
Certification chain
A signing certificate rarely stands alone. Verifiers walk the chain from the end-entity certificate through intermediate CAs toward a root. Missing intermediates, expired certificates or mismatched extended key usage can break validation or downgrade trust.
Common chain failures include:
- Intermediate bundle not embedded in the manifest or not supplied by the verifier configuration.
- Clock skew causing “not yet valid” errors during verification.
- Certificate revoked after signing but before review (OCSP/CRL handling varies by implementation).
- Cross-signed roots where the verifier’s trust store prefers a different path than the signer expected.
Trust list
Even with a complete chain, trust depends on configured trust anchors and recognized program authorities. Newsrooms, brands and platforms may maintain different trust lists for production versus experimentation.
Trust lists typically include root CAs, program-specific constraints and sometimes allow-lists of organization names. Updating a trust list is a governance action — version it, review it quarterly, and tie changes to change-management tickets.
See Recognized authorities and trust chains documentation for C2PA Signer-specific configuration guidance.
Test certificates
Sandbox and development workflows often use test certificates that validate cryptographically but are not anchored in production trust programs. These commonly appear as Signed but untrusted — which is the correct outcome for internal test signing.
Never publish test-signed assets to production CMS paths. Separate storage buckets, filename prefixes (e.g. TEST_) and CMS metadata flags reduce the risk of accidental publication.
Common causes and fixes
| Symptom | Likely cause | Recommended action |
|---|---|---|
| Signed but untrusted | Test or unknown CA | Confirm environment; update trust list if partner is approved |
| Signed but untrusted | Missing intermediate | Re-sign with full chain embedded; verify with updated bundle |
| Invalid | File edited after signing | Reject asset; request re-export from source |
| Invalid | Expired signing certificate | Rotate keys; re-sign with valid certificate |
| No credentials | CDN stripped manifest | Fix delivery pipeline; verify live URL in browser |
Status examples in C2PA Signer
- Trusted — signature valid and chain matches configured trust expectations.
- Signed but untrusted — signature valid, trust policy not satisfied.
- Invalid — manifest or signature failed cryptographic validation.
- No credentials — no C2PA manifest detected in the reviewed context.
See also the Content Credentials verifier overview and interactive demo for hands-on examples with sample files.
Enterprise trust checklist
- Document production trust anchors and approved signing programs.
- Separate test and production keys with distinct certificate profiles.
- Require full chain embedding in manifests from partner APIs.
- Log certificate subject, issuer and serial for every published asset.
- Train editors: untrusted ≠ fake; invalid ≠ untrusted.
- Review trust list updates after each new partner or CA onboarding.