Certum Open Source Code Signing Certificate

A Code Signing Certificate for individual developers publishing publicly available open-source software, with identity verification, protected signing keys, and Certum's Open Source Developer identity.

See Pricing Options
Open Source Code Signing €25 from
Product term1 year
SubscriberIndividual developer
ProjectPublic open source required
Key optionsCard or SimplySign cloud

€25 is the electronic code option for customers who already have a compatible cryptoCertum card and reader. The complete card and cloud variants are priced separately.

View Certum Pricing

Who Is This Certificate Actually For?

Certum Open Source Code Signing is defined by two things that must be true together: the subscriber is an individual developer and the software is tied to a publicly available open-source project. That makes eligibility and project verification central to the purchase decision, rather than treating this certificate as simply a lower-cost alternative to Certum Standard Code Signing.

Individual open-source developer

You develop and distribute software under an open-source model and can demonstrate your relationship with the public project.

Individual publishing proprietary commercial software

This is not the intended certificate. Review a Certum product intended for commercial software distribution.

Registered software company

Review Certum Standard Code Signing or another organization product that matches the publisher identity you need.

Organization requiring EV

Certum EV Code Signing has a separate organization validation model and should be evaluated against your signing requirements.

The Public Project Is the Eligibility Gate

The public project is the first practical eligibility test. Before you purchase, make sure the project is accessible without special credentials, that public project information identifies your role, and that Certum can reasonably connect you to the project from information available online.

01Project is publicThe project can be accessed publicly online.
02Your relationship is visiblePublic project information clearly connects you to the project.
03Open-source model is clearThe project is genuinely distributed as open source.
04Certum can verify itThe project can be identified from public information.
05ApplyProceed with identity and document verification.

What Appears in the Certificate?

The certificate identity tells users and software platforms who was validated as the signer. With Certum Open Source Code Signing, the certificate is intentionally presented around the Open Source Developer designation rather than a conventional company organization name, which is why the product should not be confused with a company based Standard or EV certificate.

Certificate identity
Open Source Developer

Certum states that Open Source Code Signing certificates are issued only to individuals and use the Open Source Developer designation in the certificate identity.

SubscriberIndividual
Organization fieldOpen Source Developer
Project relationshipVerified during issuance
Domain or IPNot included

Open Source vs Standard Code Signing

The most useful way to compare Certum Open Source with Standard Code Signing is to look at the publisher identity, the evidence required before issuance, and what type of software distribution each product is designed to support. The commercial-use restriction is particularly important because it changes which certificate family is appropriate when an open-source project becomes a commercial product.

Open Source

Audience: individual open-source developers

Project: public open-source project required

Identity: Open Source Developer

Commercial distribution: not permitted under this product

Standard

Audience: individuals or companies under applicable rules

Project: no public open-source project requirement

Identity: subscriber or company identity

Commercial distribution: supported use case

EV

Audience: organizations under Certum's EV requirements

Validation: organization-focused

Identity: organization information

Use: higher validation requirements and specific platform scenarios

What the Certificate Establishes

Code signing provides cryptographic evidence about the publisher identity associated with a release and whether the signed artifact has changed after signing. It is important to separate those guarantees from software security claims: a valid signature does not certify that the source code is vulnerability-free or that every release is safe to install.

Publisher identity

Identifies the certificate holder under Certum's Open Source Developer model.

Software integrity

Lets verification tools detect changes made to the signed artifact after the signature was created.

Signing authority

The protected private key creates the cryptographic signature used to authenticate the release.

What it does not prove

Code signing does not prove that software is malware-free, vulnerability-free, bug-free, or safe simply because the project is open source. The signature addresses publisher identity and artifact integrity.

How Certum Verifies the Developer

Certum documents multiple ways an individual subscriber may complete identity verification. The exact route can depend on the applicant and the verification method selected, but the overall process connects subscriber identity, address evidence and the public open-source project before the certificate is approved.

IdentityAutomatic verification, registration point, notarial confirmation, photo verification or documented reuse of existing Certum qualified certificate verification.
AddressUtility bill or other accepted address evidence issued for the subscriber.
Open-source projectPublic project URL and visible relationship between the applicant and project.
ReviewCertum evaluates the supplied information before issuing the certificate.

Documents to Prepare

Preparing the evidence before you begin can reduce avoidable delays during issuance. The key information is not limited to personal identity: the application also needs address evidence and enough public project information for Certum to establish that the applicant is connected to the open-source software being signed.

✓
Identity verificationComplete one of Certum's accepted verification methods.
✓
Address evidencePrepare an accepted utility bill or equivalent subscriber address document.
✓
Public project URLProvide the website or address of the ongoing open-source project.
✓
Project relationshipMake the applicant's relationship with the project clear from public information.
✓
Certum Store accountDocuments can be uploaded through the Data security products area.
✓
Signing methodDecide whether the certificate will use a compatible card or SimplySign cloud.

Application to First Signed Release

The application is more than a checkout transaction. After purchase, the subscriber information and supporting evidence must be processed, the public project relationship must be established, and the signing key must be provisioned in the selected protected environment before the first production release is signed.

01Choose productSelect Open Source Code Signing and the card or cloud model.
02PurchaseCreate or use your Certum Store account and complete payment.
03VerifySubmit subscriber, address and project evidence.
04ActivateGenerate or provision the protected signing key and activate the certificate.
05SignUse your signing tool to create and verify the release signature.

Where the Private Key Lives

Certum provides two distinct approaches for the Open Source product: a physical cryptographic card and the SimplySign cloud option. The choice affects how the developer authenticates during signing, how the workstation connects to the signing credential, and how the release environment should be configured, but neither should be treated as an invitation to export the private key into ordinary files.

CertificatePublic credential associated with the publisher identity
→
Protected private keyCryptographic signing material is not exposed as ordinary text
→
Card or cloudcryptoCertum card or SimplySign environment
→
Signing toolWindows, Java or other supported tooling

Card Based Signing

The card based model places the signing key on a dedicated cryptographic device and uses a compatible reader to connect that device to the workstation. Activation and card administration include PIN and PUK controls, so the signing environment has a separate security boundary from the normal developer filesystem.

cryptoCertum card

Current Certum shop documentation lists cryptoCertum 3.7 / IDPrime 940C for the Open Source set, with compatible reader options depending on the package.

Activation path
Connect reader
    ↓
Insert cryptographic card
    ↓
Configure PIN and PUK
    ↓
Use proCertum CardManager
    ↓
Generate key pair on card
    ↓
Complete certificate activation
    ↓
Use the protected key for signing
The card based workflow keeps the signing key inside the cryptographic device.

Open Source Code Signing with SimplySign

SimplySign is Certum's cloud delivery option for Open Source Code Signing. Instead of connecting a physical card and reader to the developer workstation, the signing environment uses Certum's cloud infrastructure, authentication flow and virtual cryptographic card model, which can simplify workstation setup while still requiring deliberate access controls for signing operations.

Mobile authentication

The SimplySign mobile application is used to generate access codes for the cloud signing environment.

Virtual cryptographic card

SimplySign Desktop connects the computer to the virtual cryptographic card in the cloud.

Protected cloud key

Certum lists FIPS 140-2 Level 3 or CC EAL4+ key storage for the cloud product.

Cloud usage limit

Certum's current cloud product page states a limit of 5,000 signatures per month. Exceeding that limit may lead to contact from Certum and possible blocking during the month in which the limit is exceeded.

What Can You Sign?

The certificate can be used in common software signing workflows, but file support should always be evaluated together with the platform, signing tool and release environment. Windows Authenticode and Java JAR signing are the clearest practical examples, while other formats should be checked against Certum's current documentation rather than assumed to be interchangeable.

Windows

EXE, MSI and DLL artifacts, plus supported driver workflows where the platform requirements are met.

Java

JAR and other Java artifacts supported by the relevant signing tools.

Other tooling

Certum documents signing with tools installed on Linux, Unix and macOS for supported workflows.

Certum Open Source on Windows

Windows is a major practical use case because the certificate can be used with Authenticode based signing workflows. The important release sequence is to finalize the exact artifact, access the protected signing key, create the signature, timestamp it, and then verify the certificate chain and signature before publishing the file.

Release artifact

The signing operation connects the Open Source Developer identity to the file while the digest protects against post-signing modification.

Typical Windows release flow
Build EXE / DLL / MSI
    ↓
Run security tests
    ↓
Select Certum certificate
    ↓
Access protected private key
    ↓
Sign with Authenticode tooling
    ↓
Add trusted timestamp
    ↓
Verify signature and chain
    ↓
Publish release
Use the current Certum documentation for the exact SignTool, card or cloud configuration for your environment.

Certum Open Source on Java

Java releases use their own signing tools and certificate provider configuration, but the security sequence is similar to other platforms. The JAR should be finalized first, the protected key should be accessed through the configured Certum environment, the artifact should be signed and timestamped, and the completed signature should be verified before distribution.

JAR release

Use the certificate with the applicable Java signing workflow and protect the private key through the selected card or cloud model.

Java workflow
Build JAR
  ↓
Select signing identity
  ↓
Access protected private key
  ↓
jarsigner / supported tooling
  ↓
Timestamp
  ↓
Verify signature
  ↓
Publish
The exact key alias and provider configuration depends on the selected Certum key-storage model.

Timestamping and Long Lived Releases

Timestamping adds trusted evidence about when a signature was created. This matters for open-source releases that remain downloadable for years because a certificate can eventually expire, while a properly timestamped historical signature can preserve evidence that the artifact was signed while the certificate was valid, subject to normal certificate status and verification checks.

Release is signedThe private key creates the signature over the release artifact.
Trusted timestamp is addedThe timestamp authority records evidence of the signing time.
Certificate later expiresExpiration does not by itself erase a properly timestamped historical signature.
Verification checks the evidenceVerification still needs to account for certificate status, chain and timestamp evidence. Timestamping does not make a revoked signature automatically trustworthy.

Certificate Validity

Certum's current Code Signing product family lists Open Source Code Signing as a 1-year product. That makes renewal planning part of release management: developers should know when the current certificate expires, allow time for any required checks, and test the replacement certificate before the next public release depends on it.

Open Source product

  • 1-year product
  • Plan renewal around the certificate expiry date
  • Keep signing infrastructure ready for the next certificate

Current validity environment

  • Certum introduced shorter maximum certificate validity rules for code signing in 2026
  • The current 1-year Open Source product is not presented as a multi-year certificate on Certum's product family page
  • Check current issuance terms before ordering

Renewal and Certificate Replacement

Renewal affects the signing identity, certificate configuration and release pipeline, so it should be planned alongside software release operations. Review the project relationship and required evidence, provision the replacement certificate and signing key, update the build environment, and verify a test signature before relying on the new certificate for a public release.

Before expiryReview the certificate, project relationship and signing environment before the current certificate expires.
Revalidate where requiredPrepare current identity, address and project evidence as applicable to the renewal.
Choose key strategyDecide whether the new certificate should use a newly generated signing key.
Update build configurationReplace the certificate reference and verify card or cloud access.
Test before releaseSign a test artifact, verify the chain and timestamp, then publish the next release.

The critical commercial-use restriction

Certum's current required-documents guidance states that if it determines an Open Source Code Signing certificate is being used to sign software distributed commercially, the certificate will be revoked. This product should therefore not be treated as a general-purpose commercial software certificate.

Open-source project

  • Public project
  • Applicant relationship can be verified
  • Open Source Developer identity
  • Use remains within the product's intended model

Commercial distribution

  • Do not assume Open Source Code Signing remains appropriate
  • Review Certum Standard or another commercial product
  • Reassess before signing commercial releases

What If the Project Changes?

An open-source project can change ownership, licensing, contribution structure or commercial model after a certificate has already been issued. When the software distribution model changes, review the certificate's eligibility and intended use before signing another release instead of assuming that an existing Open Source certificate remains appropriate indefinitely.

Project remains open source

Continue using the product within its documented eligibility and usage model.

Project becomes commercial

Review certificate eligibility and move to an appropriate commercial Code Signing product before continuing commercial releases.

You stop contributing

Review the certificate's eligibility and your continuing relationship with the public project rather than assuming the existing certificate remains suitable.

Project moves to another organization

Review certificate identity and eligibility before assuming an existing certificate can be transferred or reused.

Open Source Developer vs Company Publisher

Publisher identity is one of the main reasons certificate selection matters. The Open Source product identifies the subscriber under the Open Source Developer model, while Standard and EV products use different identity and validation structures designed for broader or organization-focused software distribution scenarios.

Open Source

Individual subscriber with the Open Source Developer designation and a verified relationship to a public open-source project.

Standard

Can represent individual or company information under the applicable Certum Standard product rules.

EV

Organization-focused certificate with a separate validation process and eligibility requirements.

Pricing and Setup Cost

Certum's Open Source offering has different purchase paths, so the displayed entry price should not be treated as the total cost of every implementation. The electronic code option is relevant when the customer already has the compatible cryptographic hardware, while the card set and SimplySign cloud variants add different provisioning and infrastructure considerations.

Electronic code
€25
from, Certum shop listing

For customers who already have a compatible cryptoCertum card and reader. Other variants have separate pricing.

View Certum Pricing
Electronic codeFrom €25
Card setFrom €69
SimplySign cloudFrom €49
Product term1 year for Open Source
AvailabilityCertum shop currently marks the displayed variants as out of stock in its crawled listings

Open Source vs Standard: Buying Checklist

Certificate selection should follow the publisher and distribution model first, then pricing and signing convenience. If the software is a public open-source project maintained by an individual developer, the Open Source product may match the documented model; if the software is commercial or requires a company identity, the Standard or EV product family should be evaluated instead.

Choose Open Source when

You are an individual, publish a public open-source project, can demonstrate your project relationship, and understand the restriction on commercial software distribution.

Review Standard when

You need a certificate for general software distribution, including commercial software, or need an organization or individual identity under Standard product rules.

When This Certificate Is Not Appropriate

Certain changes should immediately trigger a certificate review because they can move the software outside the intended Open Source product model. Commercial distribution, company ownership, a changed project relationship or the inability to demonstrate the public project connection are all reasons to reassess the certificate before signing another release.

Your software is commercial

Review Certum Standard or another commercial Code Signing product.

You are signing company-owned software

Review Standard or EV according to the publisher identity and validation requirements.

Your open-source project became commercial

Reassess certificate eligibility before continuing to sign releases for commercial distribution.

You cannot demonstrate the project relationship

Certum's documented requirement means the certificate may not be issued if the project cannot be identified from public information.

Private-Key Compromise Response

A private-key compromise can undermine the trust placed in every signature created with that key. Stop signing immediately, assess which releases may be affected, follow Certum's revocation process, create a new protected key and replace the certificate in the release environment before resuming distribution.

01Stop signingRemove the affected key from release workflows.
02Assess compromiseDetermine what signing assets and releases may be affected.
03RevokeFollow Certum's revocation process for the compromised certificate.
04Generate new keyUse a new protected signing key.
05Recover release processObtain replacement credentials and review affected releases.

Open Source Release Workflow

A signed open-source release should move through a controlled sequence from development to publication. Testing and artifact finalization happen before signing, while timestamping and independent verification happen after the signature is created; this keeps publisher authentication and artifact integrity connected to the wider release process rather than treating the certificate as a substitute for software security testing.

01DevelopBuild the open-source release.
02TestRun security and functional checks.
03Freeze artifactFinalize the exact file to publish.
04SignUse the Certum Open Source certificate.
05TimestampAdd trusted signing-time evidence.
VerifyCheck signature and certificate chain
→
PublishRelease the signed artifact
→
User downloadsPublisher identity is available for inspection
→
Integrity checkModification after signing can be detected

Buying and Eligibility Checklist

Use this checklist before placing an order so you can validate both eligibility and operational readiness. The goal is to avoid choosing the Open Source product based only on its price and then discovering during issuance or release preparation that the project, publisher identity or intended distribution model does not match the product requirements.

✓
I am an individualThe Open Source product is issued only to individuals.
✓
My project is publicThe ongoing project is publicly accessible.
✓
My relationship is visiblePublic information connects me to the project.
✓
I can complete identity checksI can provide the required verification evidence.
✓
I understand the certificate identityThe certificate uses the Open Source Developer designation.
✓
I understand commercial use is restrictedI will not use this product as a general commercial software certificate.
✓
I selected card or cloudI have planned the signing environment and authentication flow.
✓
I planned renewalThe certificate lifecycle is included in my release process.

Frequently Asked Questions

These answers focus on the questions developers are most likely to ask before purchasing or implementing Certum Open Source Code Signing. They cover eligibility, certificate identity, commercial-use restrictions, supported signing workflows, key storage, pricing and the lifecycle of the certificate.

What is a Certum Open Source Code Signing Certificate?

It is Certum's Code Signing product for individuals publishing publicly available open-source software. Certum identifies the subscriber using the Open Source Developer designation.

Who can get a Certum Open Source Code Signing Certificate?

It is intended for individuals who can demonstrate a relationship with a publicly available open-source project and complete Certum's required identity and address verification.

Does Certum require a public open-source project?

Yes. Certum's required-documents guidance asks for the website or address of the ongoing Open Source project and states that the project must be publicly available and clearly indicate the subscriber's relationship to it.

How does Certum verify my relationship with the project?

Certum states that it must be able to identify the project from publicly available information and establish the subscriber's relationship with it.

What documents does Certum require?

Certum documents identity verification, an address document such as an accepted utility bill, and the public address of the ongoing open-source project.

What name appears in the certificate?

Certum states that Open Source Code Signing certificates use the Open Source Developer designation and are issued only to individuals.

Why does the certificate say Open Source Developer?

The designation distinguishes the certificate's publisher identity and eligibility model from Certum Standard and EV Code Signing products.

Can I use the certificate for commercial software?

No. Certum's current required-documents guidance states that if it determines the certificate is being used to sign commercially distributed software, the certificate will be revoked.

What happens if Certum determines I am using it commercially?

Certum states that the certificate will be revoked if it determines that an Open Source Code Signing certificate is being used to sign commercially distributed software.

Can I sign Windows EXE files?

Certum's Open Source product documentation lists support for file types including .exe and describes Windows signing workflows.

Can I sign DLL and MSI files?

Certum's shop documentation lists .dll and .msi among file extensions supported depending on the signing tool.

Can I sign drivers?

Certum's activation documentation describes Code Signing as allowing software and drivers to be digitally signed. Driver distribution can also have additional platform requirements, so verify the current Microsoft workflow for your driver type.

Can I sign Java JAR files?

Yes. Certum lists Java compatibility and supports signing workflows using the applicable Java tooling.

Does Certum provide a cryptographic card?

Yes. The Open Source card set listed by Certum includes a cryptoCertum cryptographic card, with reader configuration depending on the package and availability.

Can I use SimplySign instead of a physical card?

Yes. Certum offers a dedicated Open Source Code Signing in the Cloud product through SimplySign.

Where is the private key stored?

For the card model, the key is generated on the cryptographic card. For the cloud model, Certum lists protected cloud key storage and a virtual cryptographic card workflow.

How long is the certificate valid?

Certum's current Code Signing family page lists the Open Source product with 1-year validity.

How much does Certum Open Source Code Signing cost?

Certum's current shop listings show the electronic code option from €25, the card set from €69, and the SimplySign cloud option from €49. Prices and availability can change.

What happens when the certificate expires?

Plan a renewal and new certificate activation before the next release requires it. Timestamped signatures should be evaluated separately from newly signed releases.

Can I use the certificate in CI/CD?

The product can be incorporated into automated release workflows where the selected signing environment and authentication model support the required process. The protected private key should not be exported into ordinary build artifacts or plaintext configuration.

What happens if my private key is compromised?

Stop signing with the affected key, follow Certum's revocation process, generate a new protected key and review releases that may have been signed with the compromised credential.

How is Certum Open Source different from Certum Standard Code Signing?

Open Source Code Signing is tied to an individual and a publicly available open-source project and uses the Open Source Developer designation. Standard Code Signing has a broader publisher model and is intended for general software distribution under its applicable rules.

Related Code Signing Resources

Continue with the topics that support certificate selection, signing and lifecycle planning.

Certum Code Signing Certificates Certum Standard Code Signing Certificate Certum EV Code Signing Certificate Code Signing Certificate Cost How to Choose a Code Signing Certificate What Is a Code Signing Certificate? Windows Code Signing: Complete Guide Microsoft Authenticode: Complete Guide Java Code Signing: Complete Guide Code Signing and Timestamping Explained Code Signing Certificate Lifecycle Code Signing Certificate Renewal How to Sign Software Without Exposing the Private Key What Happens If a Code Signing Private Key Is Compromised?

Certum Open Source Code Signing is built around one specific publisher model

The key question is not simply whether you need a Code Signing Certificate. It is whether you are an individual publishing a publicly available open-source project and can meet Certum's Open Source Developer eligibility requirements.

View Certum Product Options Review Eligibility