Skip to content

Unable to generate a valid self-signed certificate for C2PA signing (documentation unclear). Should i buy one? #199

Closed
Closed
Unable to generate a valid self-signed certificate for C2PA signing (documentation unclear). Should i buy one?#199
Assignees
crandmcktmathern
Labels
status: done

Description

@mimideannointed-star
mimideannointed-star
opened on Nov 30, 2025

Hi, I'm having ongoing difficulty generating a valid self-signed certificate for use in my development environment. I’ve been following the instructions in the C2PA Python documentation, including the OpenSSL commands for creating a test CA and signer certificate, but every certificate I generate is rejected by the C2PA Python signing APIs as “invalid”, “not v3”, or missing required extensions.

I’ve gone in circles with this for almost two weeks and I still cannot produce a certificate/key pair that C2PA considers valid for signing. I may be misunderstanding the documentation, or the documentation might be missing some essential details about what extensions or structure the certificate must have.

I would like to ask for clarification on the exact, correct procedure for generating a valid signer certificate and signer private key for use with the C2PA Python SDK.? Would I need to buy one?

Activity

  1. tmathern commented on Dec 1, 2025

    @tmathern
    tmathern
    on Dec 1, 2025
    Collaborator

    You don't need to buy a certificate for development, @mimideannointed-star.
    Most likely the certificate you generated is even fine to use with dev.

    I am going to make the assumption that in the details of what c2patool reports (or the tool you use to verify), you should see an "untrusted" error somewhere (Note that in the future, the Python SDK's Reader will behave the same).

    This happens because c2pa includes trust configurations (and a (certificates) trust list). Your locally generated developer certificate is not trusted, as it is not on the trust list (because locally generated...). But this is a setting you can change for local development. Please refer to https://learn.contentauthenticity.org/configuring-c2pa-tool-settings on how to do that.

    The settings you'll configure to include your dev certificate should be the same settings you will have to use with the Python SDK to make sure the certificates will read as valid once that change is also released in the Python SDK (using the load_settings API, albeit you'd need to convert your TOML settings to JSON for the SDK, and the API may slightly change after the release with that change (WIP)).

  2. crandmck commented on Dec 1, 2025

    @crandmck
    crandmck
    on Dec 1, 2025
    Collaborator

    You can use the c2patool trust subcommand to configure trust settings for C2PA Tool. See https://opensource.contentauthenticity.org/docs/c2patool/docs/usage#configuring-trust-support.

    But I agree we can clarify the docs in this area.

  3. mimideannointed-star commented on Dec 3, 2025

    @mimideannointed-star
    mimideannointed-star
    on Dec 3, 2025 via email
    Author

  4. tmathern commented on Dec 3, 2025

    @tmathern
    tmathern
    on Dec 3, 2025
    Collaborator

    Here is an example from the tests for the load settings API: https://github.com/contentauth/c2pa-python/blob/main/tests/test_unit_tests.py#L1456

    It's relatively easy to use:

    # import it
from c2pa.c2pa load_settings

# use it with json settings (stringified or not, both work)
load_settings('{"example": stringifed settings object}')

    Regarding the trust list, I recommend watching the video and reading the docs linked above. It will explain how to put it in toml, then you can convert the toml into json and feed the JSON into the load settings API (stringifed or not, both work).

    Here is an example of test settings containing trust: https://github.com/contentauth/c2pa-rs/blob/2fa36b24b365c7896c89945438717c3d50bd04d7/sdk/tests/fixtures/test_settings.toml#L13

    For your case, you need to do the following:

    1. Add your dev certificate to the trust chain
    2. Convert the TOML to JSON (some libraries, tools or even websites can do that for you)
    3. Feed the JSON (stringified or not) into the load_settings API. Given there will be certificates data, I would recommend to stirngify it.

    Just be aware that this API for loading settings will change in future releases (it's not totally stable yet, which is why it is not that public yet, as you may notice in the way to import it).

  5. crandmck commented on Dec 3, 2025

    @crandmck
    crandmck
    on Dec 3, 2025
    Collaborator

    @mimideannointed-star For your reference, here is the API reference doc for load_settings:
    https://contentauth.github.io/c2pa-python/api/c2pa/c2pa/index.html#c2pa.c2pa.load_settings

  6. mimideannointed-star commented on Dec 6, 2025

    @mimideannointed-star
    mimideannointed-star
    on Dec 6, 2025 via email
    Author
  7. tmathern
    self-assigned this
    on Dec 7, 2025

  8. tmathern commented on Dec 7, 2025

    @tmathern
    tmathern
    on Dec 7, 2025
    Collaborator

    Good to hear!

  9. tmathern
    closed this as completedon Dec 7, 2025
  10. github-actions
    added
    status: done
    on Dec 7, 2025
  11. tmathern
    assigned
    crandmck
    on Dec 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

status: done

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions