In short
An SSL/TLS certificate authenticates a server during a live connection. A code signing certificate authenticates a file that has already left your building. Both are X.509 certificates from a publicly trusted CA, and neither can do the other's job: the Extended Key Usage field decides which one a verifier will accept. As of August 2026 they also diverge on the things that cost you time. A public TLS certificate maxes out at 200 days and a code signing certificate at 460, and only the code signing private key is required to live in certified hardware.
If you have already worked out which one you need, the code signing certificate options cover validation tiers, key delivery and validity in one place. If you are here because a signing tool rejected a certificate you already own, start with the Extended Key Usage section.
The question usually arrives sideways. A developer runs SignTool against the company wildcard certificate, gets an error, and asks whether the finance team really has to buy a second certificate for the same domain they already paid to secure. The answer is yes, and the reason has less to do with pricing than with the fact that the two certificates are solving problems separated by years.
Most comparisons of these two products were written before 2023 and stop at purpose, storage location, and validation. That framing is not wrong, it is just no longer where the differences bite. Three rule changes since then have pulled the two apart operationally: hardware key storage became mandatory for all code signing in June 2023, TLS validity fell to 200 days in March 2026, and code signing validity fell to 460 days a fortnight earlier. What follows is the comparison as it stands today.
What each certificate actually does
An SSL/TLS certificate binds a public key to a domain name so a browser can confirm it reached the right server and negotiate an encrypted channel. A code signing certificate binds a public key to a verified organization or individual so an operating system can confirm who produced a file and that nobody altered it since. One authenticates an endpoint in a conversation. The other authenticates the origin of an artifact.
That difference in subject matter drives everything else. A TLS certificate is presented fresh at every handshake, so the verifier is always online, always current, and can be told the certificate is no longer good within hours. A code signature is embedded in the file, so the verifier might be an offline laptop in a factory running an installer pulled off a share three years ago. Nothing about that machine's situation lets it consult you.
Encryption is where the naming gets misleading. A TLS certificate is part of a key exchange that produces an encrypted tunnel. Code signing encrypts nothing at all. It hashes the file and signs the hash, which is why a signed installer is still perfectly readable in a hex editor. If you want the underlying mechanics, our guide to what a digital signature is walks through the hash-then-sign step in detail.
What the two have in common
More than most comparisons admit. Both are X.509 certificates. Both start with a key pair and a certificate signing request. Both are issued by a commercial CA that has been audited into a public root program, both chain up through intermediates to a root the verifier already trusts, and both can be revoked through CRL or OCSP. If you understand how an X.509 certificate is structured, you already understand three quarters of a code signing certificate.
The trust stores are where the shared ancestry ends. Which roots a browser accepts for TLS is decided by the browser and OS root programs. Which roots Windows accepts for an Authenticode signature is decided separately, by the Microsoft Trusted Root Program. A CA can be trusted for one and not the other, which is why "is this CA trusted?" is an incomplete question until you say trusted for what.
| As of August 2026 | SSL/TLS certificate | Code signing certificate |
|---|---|---|
| What it authenticates | A domain name, live | An organization or person, after the fact |
| Cheapest validation tier | Domain validation, issued in minutes | Organization validation. There is no DV tier |
| Where the private key may live | A file on the server | Certified hardware only, since June 1, 2023 |
| Maximum validity | 200 days | 460 days |
| Renewal | Fully automatable with ACME | Manual, or a cloud signing service |
| The day it expires | The site stops loading | Nothing, if signatures were timestamped |
| What revocation affects | Future connections | Past signatures, via a backdated effective date |
Can an SSL certificate sign software?
No, and the block is a field rather than a policy anyone can waive. Every publicly trusted certificate carries an Extended Key Usage extension listing the purposes it may be used for. A TLS certificate carries id-kp-serverAuth, OID 1.3.6.1.5.5.7.3.1. A code signing certificate carries id-kp-codeSigning, OID 1.3.6.1.5.5.7.3.3. Verifiers check that field, so each certificate is refused for the other's job.
The same logic runs in reverse, which surprises people less often only because nobody tries it. Point Nginx at a code signing certificate and the handshake fails on the client side with a certificate-purpose error, assuming Nginx loads it at all. Neither refusal is a bug or a licensing restriction; it is the verifier doing what RFC 5280 tells it to do with the extension it found.
There is a second, blunter obstacle that stops the substitution before policy gets a say. Your TLS private key is a file. A code signing private key has to be generated inside certified hardware and cannot be exported from it. Even if the EKU somehow matched, there would be no way to move one key into the other's world.
Where the private key is allowed to live
Since June 1, 2023, every publicly trusted code signing private key must be generated and stored on hardware certified to FIPS 140-2 Level 2, Common Criteria EAL 4+, or equivalent, with RSA keys of 3072 bits or larger. TLS private keys carry no such rule and remain ordinary files on the server. This is the difference that reshapes a build pipeline, and the one most comparison articles predate.
The rule caught many buyers out because it was widely reported as an EV requirement finally arriving for everyone else. Standard OV code signing used to ship as a downloadable PFX you could drop on a build agent. That option is gone. The key now arrives on a USB token, on an HSM you already run, or inside a CA-hosted signing service, and each of those has consequences for how a build server reaches it.
In reseller practice this is the step that derails schedules more than validation does. A team budgets for the certificate, gets validated quickly, and then discovers that the token has to be physically shipped and physically present in the machine that signs. Cloud signing exists precisely to remove that constraint. Our comparison of cloud code signing versus a USB token sets out the trade-offs, and signing inside CI/CD covers the pipeline side.
How long each one lasts in 2026
As of August 2026, a publicly trusted TLS certificate may be valid for a maximum of 200 days, down from 398 on March 15, 2026 under CA/Browser Forum ballot SC-081v3, with further cuts to 100 days in March 2027 and 47 days in March 2029. A code signing certificate issued on or after March 1, 2026 maxes out at 460 days. The certificate you renew more often is the website one, which is the reverse of what most buyers assume.
The reasoning behind the split is worth understanding, because it predicts where each product goes next. TLS lifetimes can fall aggressively because ACME automates renewal end to end; a 47-day certificate is only viable because no human touches it. Code signing cannot follow that curve at the same speed. The key sits in hardware, the validation involves documents and a callback, and there is no equivalent of ACME in general use, so a 460-day floor is roughly where operational reality currently sits.
For planning purposes the two need opposite treatment. TLS renewal should be a job that runs without you, and if you are not there yet, our guide to preparing for shorter SSL lifetimes is the place to start. Code signing renewal should be a calendar entry with a lead time attached, because a new token or a re-validation is not something you complete on the afternoon it expires. The detail on that cut sits in the 460-day validity change.
What happens when each one expires
An expired TLS certificate takes the site down immediately. Browsers show a full interstitial, API clients throw, and there is no grace period to negotiate. An expired code signing certificate, by contrast, changes nothing at all for software that was signed with an RFC 3161 timestamp: the verifier compares the timestamp against the certificate's validity window rather than against today's date, so the signature keeps verifying indefinitely.
Everything in that second sentence depends on the timestamp. Sign without one and the signature is only good while the certificate is. The day it expires, an installer that has been shipping for a year starts presenting as unsigned, and the fix is to re-sign and redistribute every affected binary. Timestamping costs one extra flag on the signing command and one request to a CA timestamp server, which is why timestamping every signature is treated as mandatory rather than optional.
One consequence catches teams during renewal. Because timestamped signatures survive expiry, letting a code signing certificate lapse does not break anything you have already shipped. It only stops you signing anything new. That makes the failure quiet, and quiet failures get discovered at the worst possible moment, usually the evening a hotfix needs to go out.
What revocation reaches
Revoking a TLS certificate affects future connections only, and browsers largely soft-fail revocation checks anyway, which is a large part of why the industry chose shorter lifetimes over better revocation. Revoking a code signing certificate can reach backwards. A CA may set the revocation effective date earlier than the moment of revocation, and signatures timestamped after that date stop being trusted on machines where the software is already installed.
Backdating is a feature rather than an accident. If a key is compromised in June and the CA only learns of it in August, revoking with an August effective date would leave two months of attacker-produced signatures trusted forever, since they carry perfectly valid timestamps. Setting the effective date back to June invalidates those signatures. It also invalidates your own legitimate releases from the same period, which is the part worth planning for.
Under the CA/Browser Forum's code signing requirements a CA must revoke within 24 hours where a private key is compromised or the signed code is suspect, so the window between a credible report and a certificate you can no longer rely on is short. Keep a record of which releases were signed with which certificate and when. If revocation ever happens, that record is what tells you which builds need re-signing, and reconstructing it afterwards from release notes is miserable. The mechanics of CRL and OCSP themselves are covered in our guide to certificate revocation.
Which one do you need?
Answer one question: does the thing you are protecting travel? If users reach it over a network connection to your server, you need a TLS certificate. If they download it, copy it, or run it, you need a code signing certificate. Anyone who both ships software and hosts a download page needs both, because the TLS certificate stops protecting the installer the moment the download completes.
Two buying differences follow from that. TLS has a domain-validated tier that issues in minutes with no paperwork; code signing has no such tier, so every purchase involves organization or individual validation and a hardware key. Budget the calendar time, not just the money. Our note on how long code signing validation takes gives realistic figures, and EV versus OV code signing covers the tier choice once you know you need one.
Where My-SSL fits
| You distribute Windows applications, installers or drivers and want the publisher name to appear instead of Unknown Publisher | OV and EV code signing certificates |
| You need the download page, the API and the update endpoint secured, with renewal that survives 200-day lifetimes | SSL/TLS certificates |
If you are still working out whether signing is worth it for your distribution model at all, our page on whether you need a code signing certificate answers that before the tier question, and code signing certificates explained is the cluster's starting point.
Buying the one you actually need
My-SSL issues code signing certificates through Certum, a publicly trusted certificate authority, with the hardware key delivery the current rules require and cloud signing available for teams that cannot put a token in a build machine. Validation tiers, key options and validity are listed on the code signing certificates page. If it turns out a TLS certificate was what you needed all along, that is a different aisle of the same shop.