Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 12 additions & 33 deletions docs/signing/get-cert.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ title: Getting a signing certificate
Best practices for handling keys and certificates are beyond the scope of this documentation. Always protect your private keys with the highest level of security; for example, never share them through insecure channels such as email.
:::

To sign manifest claims, you must have an X.509 v3 security certificate and key that conform to the requirements laid out in the [C2PA specification](https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#x509_certificates). Additionally, the C2PA program provides a [Certificate Policy](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Certificate%20Policy.pdf) containing the requirements for a certification authority (CA) to follow when issuing C2PA claim signing certificates and the requirements for the use of such certificates.
To sign manifest claims, you must have an X.509 v3 security certificate and key that conform to the requirements laid out in the [C2PA specification](https://c2pa.org/specifications/specifications/2.3/specs/C2PA_Specification.html#x509_certificates). Additionally, the C2PA program provides a [Certificate Policy](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Certificate%20Policy.pdf) containing the requirements for a certification authority (CA) to follow when issuing C2PA claim signing certificates and the requirements for the use of such certificates.


## Purchasing a certificate
Expand All @@ -20,26 +20,18 @@ The process to purchase a certificate and key is different for each CA: You migh

The certificate chain starts with the certificate from the last tool that signed the manifest (known as the "end-entity") followed by the certificate that signed it, and so on, back to the original CA issuer. This enables a validating application to determine that the manifest is valid because the certificate chain goes back to a trusted root certificate authority.

### Types of certificates

The C2PA specification requires that an "end entity" signing certificate must be either:

- An S/MIME email certificate (`id-kp-emailProtection` EKU). This is usually the simplest and least expensive option.
- A document signing certificate (`id-kp-documentSigning` EKU). Obtaining these kinds of certificates typically have more stringent requirements (like proving your identity) and costs more.
### Certificate authorities (CAs)

For more details, see [Certificate requirements](#certificate-requirements) below.
To develop a conforming generator product, you must purchase a signing certificate from a certificate authority (CA) on the C2PA trust list, such as:

### Certificate authorities (CAs)

You must purchase a signing certificate from a certificate authority (CA). The following table provides some links to popular CAs for convenience. This information is for reference only; inclusion does not imply endorsement by CAI or Adobe, Inc.
- [Digicert](https://www.digicert.com/solutions/c2pa-media-trust)
- [Trufo](https://trufo.ai/tca)
- [SSL.com](https://www.ssl.com/article/c2pa-enterprise-content-authenticity-solutions/)

| CA | S/MIME email signing | Document signing |
|----|----------------------|------------------|
| Digicert | [S/MIME email signing](https://www.digicert.com/tls-ssl/secure-email-smime-certificates) | [Document signing](https://www.digicert.com/signing/document-signing-certificates) |
| GlobalSign | [S/MIME email signing](https://shop.globalsign.com/en/secure-email) | [Document signing](https://shop.globalsign.com/en/document-signing) |
| IdenTrust | [S/MIME email signing](https://www.identrust.com/digital-certificates/secure-email-smime) | [Document signing](https://www.identrust.com/digital-certificates/document-signing) |
| Sectigo | [S/MIME email signing](https://ssl.comodoca.com/s-mime) | [Document signing](https://ssl.comodoca.com/document-signing-certificates) |
| SSL.com | [S/MIME email signing](https://www.ssl.com/certificates/s-mime-certificates/) | [Document signing](https://www.ssl.com/certificates/document-signing-certificates/) |
:::note
The above list of CAs was complete as of January, 2026. Other CAs may have been added subsequently. See the [**Conformance Explorer > C2PA Trust List**](https://spec.c2pa.org/conformance-explorer/) for the most up-to-date list.
:::

### Certificate signing requests (CSRs)

Expand All @@ -55,22 +47,9 @@ You sign the CSR with your private key; this proves to the CA that you have cont

## Certificate requirements

:::note
The information in this section is superseded by the [C2PA certificate policy](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Certificate%20Policy.pdf) the that establishes the requirements governing the issuance of C2PA claim signing certificates.
:::

A signing certificate and key (credentials) must conform to the requirements in the [C2PA specification X.509 Certificates section](https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#x509_certificates); specifically, it must:

- Follow the public key infrastructure (PKI) X.509 V3 specification.
- Have the Key Usage (KU) extension, which must be marked as critical.
- Assert the `digitalSignature` bit.
- Have the Extended Key Usage (EKU) extension. If the Basic Constraints extension is absent or the certificate authority (CA) Boolean is not asserted, the EKU must be non-empty.
- The `anyExtendedKeyUsageEKU` field (2.5.29.37.0) must not be present.
- If the configuration store does not contain a list of EKUs, a certificate that signs C2PA manifests must be valid for the `id-kp-emailProtection` (1.3.6.1.5.5.7.3.4) purpose and/or the `id-kp-documentSigning` (1.3.6.1.5.5.7.3.36) purpose.

### Extended key usage (EKU) fields
The [C2PA certificate policy](https://github.com/c2pa-org/conformance-public/blob/main/docs/current/C2PA%20Certificate%20Policy.pdf) establishes the requirements governing the issuance of C2PA claim signing certificates.

You must select at least one of the extended key usage (EKU) fields that specify what the certificate can be used for: **email protection** and **document signing**. Applications that use the CAI SDK won't accept the certificate unless it has one of these EKUs.
A signing certificate and key (credentials) must conform to the requirements in the [C2PA specification X.509 Certificates section](https://c2pa.org/specifications/specifications/2.3/specs/C2PA_Specification.html#x509_certificates); specifically, it must:

### Organization name

Expand All @@ -80,7 +59,7 @@ If you want the [Inspect tool on Adobe Content Authenticity (Beta)](https://insp

The following table describes the signature algorithms and types that the CAI SDK supports. You must supply credentials (certificates and keys) that correspond to the signing algorithm (`signatureAlgorithm`). Signing/validation will fail if the the supplied credentials don't support the signature type.

This table is provided for convenience, and is based on information in the [C2PA specification](https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html#x509_certificates). The specification is authoritative; refer to it for more details. The C2PA specification also covers two other certificates for timestamp responses and OCSP certificate revocation, which are not covered here.
This table is provided for convenience, and is based on information in the [C2PA specification](https://c2pa.org/specifications/specifications/2.3/specs/C2PA_Specification.html#x509_certificates). The specification is authoritative; refer to it for more details. The C2PA specification also covers two other certificates for timestamp responses and OCSP certificate revocation, which are not covered here.

| Certificate `signatureAlgorithm` | Description | Recommended signature type | RFC Reference |
| -------------------------------- | ------------ | -------------------------- | ------------- |
Expand Down
2 changes: 1 addition & 1 deletion docs/signing/local-signing.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,7 @@ Accessing a private key and certificate directly from the file system is fine du

[Getting a certificate](get-cert.md) provides a general overview of getting a signing certificate from a certificate authority (CA).

Here is an example of getting signing credentials using [GlobalSign](http://globalsign.com/) certificate authority (CA) and then using them with C2PA Tool. GlobalSign is just one of many CAs. For a list of some others, see [Getting a security certificate](get-cert.md#certificate-authorities-cas).
Here is an example of getting signing credentials and then using them with C2PA Tool.

:::note
This example uses an inexpensive personal certificate, which is fine for development and testing, but in production, an enterprise certificate is strongly recommended. An enterprise certificate is required for [Inspect tool on Adobe Content Authenticity (Beta)](https://inspect.cr) to display your organization name when for signed assets.
Expand Down
Loading