Where Can I Get a Free Code Signing Certificate?

Free code signing certificate? If YOU find one, let us know…

Since the dawn of man, in even the most primitive of economies, there have always been those that prefer not to pay. The spectrum on that runs from outright thieves to hardcore couponers — but not an industry exists that hasn’t heard the question, “yo, can I get that for free?” This includes anyone looking for a free code signing certificate.

And the answer is no. There are no free code signing certificates. And be dubious of anyone that says they can offer you free code signing certificate for free. The short answer is there are compliance constraints that prevent it, and economic incentives to abide those constraints. So, none of the certificate authorities (CAs) that are trusted to issue certificates are willing to do it for free. If you see someone offering a code signing certificate free trial, run the other way.

So, the short answer is, your best bet is to purchase the most cost-effective code signing certificate from a trusted certificate authority. The good news is, Comodo CA offers you the best bang for your buck. Even better, you can save up to 42% when you purchase your Comodo code signing certificate through us.

The long answer is a mystical tale full of public keys and… baseline requirements the legendary Forum of CA/B. So, if you’re satisfied with “no,” let us bid you adieu, or if you’d like to hang around we’ll try to slap some lipstick on the pig that is the technical reason why there are no free code signing certificates.

Save Up 42% On Comodo Code Signing Certificates

You can often save a significant amount by buying your code signing certificate direct instead of through your a CA. We sell all Comodo code signing certificates at up to 42% off.

Purchase Comodo Code Signing Certificates

He Who Yields the (Private) Key, Yields the Power

Let’s start by addressing another question that you may have. How come there are free SSL certificates but not free code signing certificates if they’re both X.509 certificates? What a good question. While they’re both the X.509 certs, SSL and code signing certificates serve different purposes. An SSL certificate, at its most basic domain validated level, simply binds a public/private key pair to a website. There’s no requirement for the browsers to TRUST that website. It only needs to demonstrate that it’s being served via HTTPS.

If you want to assert identity and gain trust with an SSL certificate, you have to pay for an organization validation (OV) or extended validation (EV) one.

Unfortunately, there’s no DV-parallel with code signing. When you sign code, you ARE asserting identity and asking the browser to make a trust-based decision about whether to warn its user about the safety of the download.

The ability to sign software is very powerful for that very reason. If it’s signed by a trusted certificate, the browser trusts the software. You see this get abused all the time when valid code signing certificates are compromised and used to sign malware.

Because of that power, there needs to be some kind of mechanism to prevent its abuse. Obviously, mismanagement of keys and certificates will always be a threat, but one of the best ways to avoid bad actors from getting valid code signing certificates is to require a certain amount of vetting before one can be issued. This is the same idea behind business authentication SSL certificates.

Now, let’s talk about the trust model that makes this possible.

From Mighty Root (Certificates) Grow Trusted Leaf (Certificates)

PKI, or public key infrastructure, is the backbone of modern encryption because it serves as a mechanism for authenticating entities. But there are a lot of moving parts like the Forum of CA/B and the various requirements put in place by browsers and root programs. Let’s try to keep this as simple as possible.

Only a trusted certificate authority can issue SSL certificates. In order to maintain trusted status, these CAs are required to abide by a set of baseline requirements as legislated by the CA/Browser Forum, as well various bylaws set in place by the root programs.

Let’s think of trust in two different contexts:

• Social Trust
• Technical Trust

You must earn social trust before achieving technical trust — however, separating the two might make it easier to understand. Social trust comes from strictly abiding the standards and guidelines that are in place. That means validating properly, documenting everything, performing regular audits, logging all the certificates you issue, and a number of other procedures that ensure the CA can be TRUSTED to only issue certificates in good faith to the correct party.

Once you’ve demonstrated that, it’s time to get into technical trust. The various root programs are run by the likes Microsoft, Apple, Mozilla and Google. A root program, or root store, is a collection of root CA certificates. Every connected device uses one of these root stores. To be trusted, a CA needs to have its root included in all of these root stores. That’s where the social trust comes in.

But from a technical standpoint, once one of your roots is included in the root store, any certificate that is a descendant from that root will be trusted. Now, issuance is actually fairly complicated with intermediate roots, sub-CAs and cross-signing involved — but for the sake of simplicity, just think of it this way: When a certificate is issued, it’s signed with the private key of the certificate that issued it.

This forms a certificate chain, where the device can authenticate the signature on the certificate, follow it back to the certificate whose key left it, and continue tracking signatures back until it reaches one of the roots saved in the root store. Provided a certificate chains to a root, it’s trusted.

That means that any code signing certificate — and they are issued just like SSL or any other kind of X.509 certificate — issued from a trusted CA is trusted. And any signature left by that trusted code signing certificate is also trusted.

Free Code Signing Certificate — Now Let’s Tie This All Together

So far, we’ve discussed what code signing does and why it’s trusted. We’ve also discussed creating barriers that will keep negative actors from acquiring trusted code signing certificates. The result of all that is that before any trusted CA is willing to issue a code signing certificate — which is basically the CA vouching for you as trustworthy — it wants to vet your organization to ensure that you are indeed a legitimate entity. The CA also wants to have some type of paper trail and information in case you go rogue later.

And here’s the unfortunate truth about that: all of this costs money.

After all, it’s not cheap to fly someone all the way to Eastern Europe and put them up for a week while they investigate, or else otherwise you have to hire some local private investigator (and those guys are like Olympic swindlers). Either way, the logistics are just a nightmare.

Ok, all kidding aside, validation does cost the CAs money. After all, CAs have to:

• hire and train staff to handle these tasks
• document everything
• log everything

The process takes time — it’s not free.

So, the CAs have to charge at least enough to cover their own costs. Plus, it also can act as an economic barrier to some negative actors, too. Since free SSL certificates have been around, we’ve seen a decided increase in the number of phishing websites that now use HTTPS. Even a modest financial barrier can sharply decrease the number of criminals abusing the system.

Long story short, there are no free code signing certificates. None that are trusted, anyway. And, given that trust is kind of the whole point of code signing, that doesn’t seem all that useful.