How to add Content Credentials to your own images, and what a self-signed certificate shows in a checker
People add Content Credentials to their own images with open-source tools such as c2patool, which writes a signed record into an output file. A certificate you make yourself is not on any trust list. A checker can then verify the signature and the match to the image, but cannot vouch for the name in the certificate.
How do people add Content Credentials to an image they made?
The open-source c2pa-rs project is a Rust library for the C2PA specification. Its page says the library can create and sign C2PA claims and manifests. The same page says the command-line tool, c2patool, now lives in its own repository.
The Content Authenticity Initiative's c2patool page says the tool can read a summary report of the manifests in a file, read a low-level report, and add a manifest to a file.
The usage page gives these commands:
- Read.
c2patool sample/C.jpgprints the manifest. Adding--infoprints a short report that says whether the manifest validated, and--certsprints the signing certificate chain. - Add.
c2patool sample/image.jpg -m sample/test.json -o signed_image.jpgadds the manifest described in a definition file to a new output file. The output type must match the source. If the output is the same as the source, the tool overwrites the source. - Say how it was made. The
--createoption takes an IPTC digital source type value, such asdigitalCapture.
Write only what is true of your own image. A signed record is a statement by whoever holds the certificate.
Which certificate does the signing use?
That choice decides what a checker can say. The CAI's signing page says that if no signer is configured, the tool uses a built-in test certificate and key, and that this is only suitable for development. It also says a private key placed in a settings file is for development and testing only.
The CAI's page on production certificates says you can make a self-signed certificate for development, and that manifests signed with it will not be trusted. Its overview of signing says the libraries' test certificates are not valid for actual signing.
The CAI's trust list page says conforming generator products must use a certificate that traces back to the C2PA Trust List. The pages we read describe that rule for products. We found no step on them for a person signing a single picture, so we do not claim one.
What does a checker show for a self-signed record?
The C2PA Specification 2.2 separates two questions. Section 15.7 says a validator checks for a chain of trust from the signing certificate to an entry on an applicable trust anchor list. If it cannot find one, the claim gets the code signingCredential.untrusted. Section 14.3.6 says a manifest is trusted only when it is valid and the signing credential receives the success code signingCredential.trusted. So a record can be sound and still untrusted.
We tested this. We drew a test picture and signed it with a development certificate that is on neither trust list we load. The record says the image came from a generative source. Our checker reads the file as "Content Credentials found; signer trust not established", even though the signature is intact and the image matches the record. We then loaded the development root as a test list, and the identical file read differently.
| Trust setup | Headline the checker gave |
|---|---|
| The two lists the live checker loads | Content Credentials found; signer trust not established |
| Our development root loaded as a test C2PA Trust List | Trusted Content Credentials declare AI use |
| Our development root loaded as a test Interim Trust List | Content Credentials found; legacy trust-list match |
The file did not change between rows. Only the list changed, so trust comes from the list, not from the signing. The two test lists exist only in our tests; the live checker never loads them.
The same headline appears on real files. The C2PA test image from the c2pa-rs project reads "signer trust not established" in our checker. Of the 32 real files in our set, 9 carry a record: 1 reads as trusted on the current list, 5 as a legacy match and 3 as "signer trust not established". The full counts are on our accuracy page.
Why does a record from a large company read differently?
A signer on a list reads differently because a list vouches for it. Adobe's help page says Adobe automatically applies Content Credentials where every pixel is generated with Firefly, with "Adobe Inc." as the issuer. The three Adobe Firefly files in our set read "Content Credentials found; legacy trust-list match", because their signer is on the frozen Interim Trust List.
Should a record name someone else, or claim something untrue?
No. Anyone can type any name into a certificate, so our checker never writes "Signed by" for an unlisted signer. It writes that the signing certificate names the signer, adds "It is on neither trust list, so that name is not verified; anyone can make a certificate with any name.", and notes that the image matches the record. It adds that the result "cannot tell a genuine record from one made with a self-made certificate". Can Content Credentials be faked? covers the forged cases we tested.
Will the record stay on the image when I share it?
Not in our test. We took the 9 real files that carry a record and redrew each one on a browser canvas, as a screenshot or a re-save would, then saved it as PNG and as JPEG. After the PNG, 0 of 9 still carried a record. After the JPEG, 0 of 9 did. A canvas is not a platform, and we contacted none.
What this means when you check an image
Open the checker, choose your signed copy, and look for the headline "Content Credentials found; signer trust not established". It means a record is present and that no trust list we load vouches for its signer. The detail under the headline says whether the image matches the record; for our own signed test file it did. It does not mean anyone vouched for the name in the certificate, and it does not tell you how the image was made.
The headline "Trusted Content Credentials declare AI use" means something different. A certificate on the C2PA Trust List signed the record, and the signed record says the image came from a generative source. Even then, a trusted signer shows who signed, not that the claim is true. Under both, the checker says its checks cannot determine whether an image is AI-generated.
Guides on this topic
- What are Content Credentials? is the main page on this topic.
- What "signer trust not established" means explains the result in full.
- How to check Content Credentials walks through every result.
- Cameras and phones that sign photos covers signing at capture.
Frequently asked questions
- Do I need a certificate to add Content Credentials?
- c2patool uses a built-in test certificate if none is configured. The CAI says that is only for development, and that records signed with a self-signed certificate will not be trusted.
- Will my own signed image read as trusted in a checker?
- Only if its signer chains to a list the checker loads. In our test, a development certificate read as "signer trust not established" until we loaded its root as a test list.
- Does signing an image prove what is in it?
- No. A signature shows the record and the image match. Whether the claims are true is a separate question. The C2PA specification (section 14.1) says its trust model concerns the signer's identity, and that a consumer uses that identity along with other signals to decide whether the assertions are true.