Open Source Code Signing Certificates: Who Qualifies and What They Cost

The three tiers at a glance

Code signing comes in three validation tiers, and Open Source is the narrowest of them. Standard (OV) is the workhorse most publishers use; EV is the highest-assurance tier organizations reach for when policy or kernel drivers demand it. Open Source sits below both: cheapest, cloud-only, and reserved for individuals shipping non-commercial open-source software. The figure lines them up so you can see where the Open Source tier gives something up and where it saves you money.

One rule holds across all three: since March 1, 2026, every publicly trusted code signing certificate is capped at 460 days of validity under CA/Browser Forum Ballot CSC-31, so the tier you pick changes what's verified and what's shown, not how long the certificate lasts. Our guide to the 460-day limit covers how that reshapes multi-year plans into reissues.

What an Open Source certificate is

An Open Source Code Signing certificate is a publicly trusted code signing certificate that a certificate authority issues to an individual developer for use on open-source software. Functionally it does the same job as any code signing certificate: it stamps your verified identity onto an executable, installer, or script, so the operating system can confirm who published the file and that nobody altered it after signing. What sets the Open Source tier apart is who it's issued to and how the identity is presented, not the cryptography, which is identical to the paid tiers.

The tier exists because the economics of code signing are awkward for hobbyists. A community maintainer shipping a free Windows utility faces the same "Unknown Publisher" friction as a commercial vendor, but without revenue to justify a full organization certificate. The Open Source tier answers that: lighter, individual-level verification and a lower price, in exchange for a fixed non-commercial scope. Certum is one of the few certificate authorities that still offers it, which is why it shows up on My-SSL's code signing lineup alongside Standard and EV.

Who qualifies — and the restrictions

Eligibility comes down to two things: you apply as an individual, and the software is genuinely open-source and non-commercial. Both have to be true. A company can't hold an Open Source certificate, and a project that earns money — paid downloads, a commercial license tier, bundled paid software — falls outside it even if the source is public. The certificate also can't carry a domain name or IP address, because it identifies a person rather than a server or service.

The restriction people underestimate is the commercial one. Certum states plainly that if it determines the certificate is signing commercially distributed software, the certificate is revoked. Revocation doesn't just stop future signing — it can invalidate the trust on files you already shipped, unless each signature was timestamped to prove it happened while the certificate was valid. Timestamping is worth setting up regardless; our guide to code signing timestamps explains why a signature can outlive the certificate behind it. If there's any chance your project turns commercial, start with Standard and skip the revocation risk entirely.

The "Open Source Developer" label

Here's the detail that surprises first-time buyers: the publisher name isn't yours alone. On an Open Source certificate the organization field is fixed to "Open Source Developer," so what recipients see is "Open Source Developer, Jane Doe" rather than "Jane Doe" on its own. It's a deliberate signal that the credential is the community tier — trusted and verified, but visibly not a company and not a plain personal-name certificate. A Standard certificate, by contrast, shows your verified name or company with no prefix.

For most open-source projects that label is a fair trade, and some maintainers even prefer it — it tells users up front that they're installing community software from a verified person. But if the "Open Source Developer" prefix would read as unprofessional for what you ship, that's a sign you've outgrown the tier. The fixed label is one of the clearest lines between a hobby credential and the name-only identity a Standard certificate gives you.

What you can and can't sign

Technically, an Open Source certificate signs the same file types any code signing certificate does: Windows executables, DLLs, MSI and MSIX installers, and PowerShell scripts through SignTool, and the format works the same way a Standard certificate would. The limit isn't the file type — it's the purpose. Everything you sign has to belong to a non-commercial, open-source project. The certificate is the wrong tool for a paid app, a client's private build, or internal enterprise tooling, even when the file format is identical.

Two practical gaps are worth calling out. Kernel-mode drivers still require an EV certificate and Microsoft's attestation process, so an Open Source certificate won't help there — our driver signing guide covers what that involves. And because the certificate can't contain a domain, it isn't a TLS/SSL certificate and does nothing for HTTPS. Keep the two jobs separate: code signing proves who wrote a program, while an SSL certificate secures a website connection.

Signing without a hardware token

Since June 2023, every publicly trusted code signing key has to live on certified hardware — no more exporting a key file to drop into a build. Certum meets that rule for the Open Source tier with the cloud, not a token: the certificate is issued on SimplySign, where your private key sits on a compliant cloud HSM you reach over an authenticated session. You install the free SimplySign and SimplySign Desktop apps, and sign with Microsoft's free SignTool. There's nothing physical to order, wait for, or misplace.

The mechanics are simple: SignTool hashes your file locally, the hash goes to SimplySign, the cloud signs it with your protected key and sends the signature back, and your machine attaches it along with a timestamp. Your private key never leaves the cloud service. If you're deciding between this cloud model and a physical USB token for other work, the trade-offs — team sharing, CI/CD, what happens when hardware goes missing — are laid out in our cloud signing vs USB token comparison.

Does it stop the warnings?

Partly, and it helps to separate the two warnings people mix up. The "Unknown Publisher" prompt — the one that shows a blank or gray publisher on an unsigned file — goes away as soon as you sign with an Open Source certificate, because Windows can now read a verified publisher name. That part is immediate. Microsoft SmartScreen is a different system: it judges a download by reputation, and a new certificate starts with none.

An Open Source certificate does build SmartScreen reputation over time, the same way a Standard (OV) certificate does — as your signed releases are downloaded and run without problems, the reputation accrues to your certificate and, eventually, to you as a publisher. It just isn't instant. Early downloads of a brand-new release may still meet a SmartScreen prompt until enough clean history exists. Neither Open Source nor Standard buys an automatic pass; the mechanics of how that reputation forms are in our SmartScreen and publisher reputation guide. If instant reputation matters to you, that's an argument for a different tier — see EV vs OV code signing for where EV still earns its price.

One more thing worth clearing up, because it comes up constantly with open-source projects: if you already sign your packages or container images with Sigstore, that signature does nothing for the Windows dialog. Fulcio's root isn't in the Microsoft Trusted Root Program, and the signature sits in a separate bundle file Windows never opens. We compare the two properly in Sigstore vs code signing certificates.

How to get one

Getting an Open Source certificate is mostly an identity exercise, since there's no company to vet. You verify who you are, prove your address, and point to the project the certificate is for. Certum offers a few ways to confirm identity — automatic checks against government ID databases, verification at a registration point, notarized documents, or a photo-with-ID submission — and if you already hold a qualified electronic certificate, you can reuse it to skip most of that step.

Beyond identity, two documents finish the job: a recent utility bill or bank statement confirming your address, and a link to your open-source project on a platform like GitHub, GitLab, or SourceForge. Once verification clears, the certificate is issued into your SimplySign cloud account and you can sign right away. Here's where each situation points on My-SSL:

FAQ