Valid is not trusted: how C2PA certificates really work

You sign your first C2PA manifest. You run c2patool on the output and it comes back clean — the hash matches, the signature verifies, the assertions are all there. Then you drop the same file into a public validator and it reports something else entirely: signingCredential.untrusted.

Nothing broke. You have just met the part of C2PA nobody puts in the quickstart: a C2PA certificate is two separate things wearing one name, and only one of them is hard to get.

What the validator is actually telling you

A C2PA validator asks two independent questions about a file, in order.

First: is this manifest internally sound? Do the hashes over the content still match, is the claim well-formed, does the signature verify against the public key in the certificate? This is pure cryptography. It needs no external authority and no network call. Either the math works or it doesn't.

Second: should I trust whoever holds that key? The signature proves a specific private key signed the claim. It says nothing about whether the holder of that key is who they say they are. To answer that, the validator checks whether the signing certificate chains up to a certificate authority on a list it recognises — the C2PA Trust List.

Those two questions can disagree, and when they do, the second one wins. The C2PA specification's own security guidance is blunt about the consequence: a validator should not present manifest data to a consumer unless the content is considered valid and trusted. c2pa-rs, the reference Rust implementation, makes the split explicit in its output — it carries a top-level validation state, and "valid but untrusted" is a perfectly ordinary value for it to hold.

If you are developing against a test certificate, that is the state you are in. It is also the state you will ship in, right up until you have a production certificate on a recognised list.

The signature is cheap. The list is not.

Here is the part that surprises teams: generating a keypair and an X.509 certificate is a five-minute job with OpenSSL. You can sign spec-compliant manifests this afternoon, at any volume, for free. Nothing about the format is gated.

What is gated is recognition. A trust list is a curated set of certificate authorities that validators agree to honour, and getting a CA to issue you a C2PA signing certificate that lands on that list is a governance process, not a technical one.

Two facts about that process matter more than anything else right now.

The first is that the easy door closed. C2PA ran an Interim Trust List to bootstrap early adopters. As of 1 January 2026 the ITL was frozen: no new entries, no updates. Certificates already on it keep working for legacy purposes until they expire, and organisations holding one are told to apply for conformance evaluation before that happens.

The second follows from the first. The C2PA Conformance Program is now the only path to a trusted signing certificate. Only products evaluated and approved through it are eligible to receive certificates from the trusted certificate authorities — which is what lets any signed Content Credential be checked against a known trust anchor.

So the question "how do I get a C2PA certificate" has quietly become "how does my product pass a security evaluation." Those are very different projects.

What conformance actually asks of you

The Conformance Program is not a form you fill in and forget. It evaluates the product that does the signing, on the theory that a certificate is only as trustworthy as the software and infrastructure holding the key.

Applicants complete a product security architecture template covering the organisation, the product and its capabilities, and — the substantive part — the product's security architecture: how keys are generated, how they are stored, and what protects the system against misconfiguration and exploitation. Compliance with the program's Certificate Policy and Security Requirements documents is the bar.

The output is graded. The program defines two assurance levels for generator products, where level 2 signals greater confidence than level 1 in the claim that what the product signs reflects its intended behaviour. That level is not a marketing badge — it is encoded directly into the signing certificate as a custom X.509 v3 extension, so a validator can read it off the wire.

Read that structure back and the design intent is obvious. C2PA is not trying to verify that your content is true. It is trying to verify that the thing which signed is a well-run system whose signatures mean what they appear to mean. Everything downstream depends on that, which is why the evaluation looks at your key custody rather than your pixels.

The expiry problem nobody plans for

Certificates expire. That is not a flaw, it is the point — a credential that never lapses is a credential nobody can retire when a key leaks. But it collides awkwardly with provenance, because the whole promise of a signed manifest is that it still means something years later.

Think about what a validator has to decide when it opens a file signed three years ago with a certificate that expired eighteen months ago. Was that signature made while the certificate was valid, or was it forged last week by someone who got hold of an expired key nobody was watching any more? The signature alone cannot tell you. It carries no trustworthy notion of when.

This is a solved problem in the wider PKI world, and the solution is a time-stamping authority: a third party that signs a statement saying "this signature existed at this moment," so a validator can later check the signature against the certificate's validity window rather than against today's date. C2PA's conformance roadmap names exactly this — incorporating time-stamping authorities into the trust lists sits alongside the generator-product and validator work.

It is worth understanding because it changes what you should log on your side. If your provenance strategy is "the manifest is in the file and the file is in the bucket," you are one certificate rotation away from a validation state you cannot explain to anyone. Signing infrastructure needs to record which key signed what, and when, in something that outlives the key.

Our version of that is the transparency log entry. Each proof carries the signing key's identifier, and every historical public key stays served by that identifier — so a proof written under a key we rotated away from last year still checks out today, against the key that actually made it. The record does not get less verifiable as the keys age.

Three honest options

If you need Content Credentials on your output, you have three routes, and it is worth naming what each actually costs.

Run the whole thing yourself. Procure a certificate through conformance, build the signing service, hold the keys in an HSM or KMS, and own rotation, revocation, and re-issuance forever. This is the right answer when the signing identity has to be provably yours and nobody else's — a newsroom attesting to its own photography, a camera manufacturer signing at capture. It is a poor use of an engineering quarter if you just need your generated images to carry credentials.

Sign with an untrusted certificate and be honest about it. Your manifests will be structurally valid and cryptographically sound. Validators will flag the signer. This is a legitimate interim position — strictly better than shipping no provenance at all — but do not describe the output as "verified," because a validator will contradict you in one command.

Sign through a managed service. Someone else holds a conformant certificate and signs on your behalf, naming your brand as the claim generator. This separation is not a loophole; it is how the format is designed. The signer is whoever holds the key. The claim generator is the software and brand credited with creating the content. They were never required to be the same party, and that is precisely what makes managed signing work.

We run the third option, and we will tell you where we stand: 0byte's certificate is going through the Conformance Program, so today a validator reads a stamped file's manifest as structurally valid while noting the signer is not yet on the public trust list. We would rather you read that here than discover it in c2patool.

Why we do not treat the trust list as the whole answer

There is a deeper problem with leaning on signer trust alone, and it has nothing to do with who is on which list.

A trust list can only be consulted if the manifest is still attached to the file. Most platforms re-encode images on upload and drop metadata they do not need, and a Content Credential is metadata they do not need. Screenshots are worse: a screenshot is a genuinely new file with no byte relationship to the original, so nothing embedded can survive it by construction.

When that happens, the trust question never gets asked. There is no certificate to check, no chain to walk, no list to consult. The validator correctly reports that it found nothing — and a perfect, level-2, fully-conformant certificate is worth exactly as much as a self-signed one, which is to say nothing at all.

This is why the C2PA specification describes a soft binding alongside the hard cryptographic binding: an identifier derived from what the content looks like, stored outside the file, so a stripped manifest can be recovered by lookup. We operate one of those publicly. Every stamp writes a perceptual fingerprint into an append-only, Ed25519-signed transparency log built on the RFC 6962 pattern, and anyone can query it for free with no account and no key.

The two mechanisms answer different questions and fail in different places. A trusted certificate tells you the signature came from a well-run system. A registry match tells you this content was registered, by whom, and when — even when the file arrived with nothing in it. Neither substitutes for the other, and any vendor telling you one of them is sufficient is selling you something.

What to do this quarter

If you are shipping generative AI output into the world, the practical sequence is short.

Sign now, with whatever certificate you can get. A valid-but-untrusted manifest is real provenance, readable by any C2PA tool, and it puts machine-readable marking on your output today.

Start the conformance conversation early if you intend to hold your own certificate, because it evaluates your infrastructure and that takes longer than procurement.

And do not let embedded metadata be your only copy of the record. The gap between "we signed everything" and "anyone can still tell" is where provenance programmes quietly fail, and it opens the moment your content touches a platform.

Valid is a property of the file. Trusted is a property of the signer. Recoverable is a property of the system you built around both — and it is the only one that survives the internet.

Further reading: C2PA Conformance Program · Conformance program docs (Content Authenticity Initiative) · C2PA Security Considerations · c2pa-rs · C2PA FAQ