How to Generate a Self-Signed Code Signing Certificate (OpenSSL & PowerShell)

Table of Contents

Verified by SSL Insights Editorial Team - Last reviewed: July 2026 | Web Security Expert, SSLInsights.com | Years of hands-on SSL/TLS and code signing experience across the cybersecurity industry.

Quick Answer

Generate a self-signed code signing certificate using OpenSSL (openssl req -new -x509) or PowerShell (New-SelfSignedCertificate). Self-signed certificates are suitable for testing and internal software but are not trusted for public software distribution.

Self-Signed Certificate at a Glance

Feature Details
Cost Free
Trust Level Internal / Local Trust Only
Certificate Type X.509
Issuer Self
Best For Testing & Development
Public Distribution Not Recommended
SmartScreen Reputation No
Supported Platforms Windows, Linux, macOS

To generate a self-signed code signing certificate, you create a key pair and a certificate that vouches for itself instead of relying on a public Certificate Authority (CA). On Windows, the New-SelfSignedCertificate PowerShell cmdlet builds one with a single command. On Linux or macOS, OpenSSL generates the private key and certificate together. The resulting certificate signs executables, scripts, drivers, or packages so Windows can confirm a file has not changed since it was signed. Self-signed certificates work well for internal testing and development pipelines. However, operating systems and browsers will not treat the certificate as a trusted publisher identity, so software released to the public still needs a CA-issued certificate.

Definition: A self-signed code signing certificate is a digital certificate that an individual or organization creates and signs with its own private key, instead of having a recognized CA validate and sign it.

It uses the same X.509 format as CA-issued certificates and links a public key to a name. Operating systems and browsers do not automatically trust that name unless someone manually adds the certificate to the local trust store.

What Is a Self-Signed Code Signing Certificate Used For?

Self-signed code signing certificates verify that internal builds and test packages have not been tampered with since signing. Development teams use them to sign installers, PowerShell scripts, drivers, and DLLs before internal release.

The signature still detects file changes, even though the publisher identity carries no outside verification. So the trust gap affects only how Windows displays the publisher name, not whether tampering gets caught.

That trust gap also brings specific risks worth knowing before relying on a self-signed certificate. SSLInsights.com's overview of self-signed certificate vulnerabilities lists the main ones.

OpenSSL vs PowerShell for Self-Signed Code Signing

Feature OpenSSL PowerShell
Platform Windows, Linux, macOS Windows Only
Ease of Use Moderate Easy
GUI Required No No
Creates PFX Yes Yes
Best For Cross-platform environments Windows development

How Do You Create a Self-Signed Code Signing Certificate With OpenSSL?

OpenSSL creates a self-signed code signing certificate with two main commands. First you generate a private key, then you create a certificate with the code signing extension enabled.

1. Generate a 2048-bit RSA private key:

openssl genrsa -out codesign.key 2048

2. Create the self-signed certificate, adding the code signing extension:

openssl req -new -x509 -key codesign.key -out codesign.crt -days 365 -addext "extendedKeyUsage=codeSigning"

3. Bundle the key and certificate into a PFX file for signing tools:

openssl pkcs12 -export -out codesign.pfx -inkey codesign.key -in codesign.crt

These three commands cover certificate creation, but OpenSSL also supports flags for key size, validity period, and subject fields. SSLInsights.com's guide to the most common OpenSSL commands explains each option in more depth.

How Do You Create a Self-Signed Code Signing Certificate in Windows PowerShell?

PowerShell creates a self-signed code signing certificate with the New-SelfSignedCertificate cmdlet. The CodeSigningCert type sets the correct extended key usage automatically.

  1. Open PowerShell as Administrator.
  2. Run the command below to create the certificate:
New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=YourCompany Test" -CertStoreLocation "Cert:\CurrentUser\My"
  1. PowerShell stores the certificate in the personal store and returns its thumbprint.

Add -NotAfter to set a custom expiration date. Then use Export-PfxCertificate to move the certificate to another machine for signing.

The same New-SelfSignedCertificate cmdlet also creates SSL certificates for websites, not just code. SSLInsights.com's guide to self-signed SSL certificates in PowerShell covers that related workflow.

Which Method Should You Use?

Scenario Recommended Method
Windows development PowerShell
Cross-platform development OpenSSL
Internal software testing Either
CI/CD pipelines OpenSSL
Enterprise Windows environments PowerShell

How Do You Sign a File With Your Self-Signed Certificate?

SignTool, included with the Windows SDK, signs files using a certificate from the certificate store or a PFX file.

  1. Install the Windows SDK or Visual Studio, both of which include SignTool.
  2. Run the signing command, pointing at the target file:
signtool sign /a /fd SHA256 /t http://timestamp.digicert.com yourfile.exe
  1. The /a flag selects the best matching certificate, and /t adds a trusted timestamp.

Code signing certificates share the X.509 format with SSL/TLS certificates, but the two serve different purposes. SSLInsights.com's comparison of code signing vs SSL certificates breaks down where each one applies.

Self-Signed vs CA-Issued Code Signing Certificates at a Glance

Feature Self-Signed CA-Issued
Cost Free Paid
Trust Internal Only Publicly Trusted
Best For Testing & Development Production Software
SmartScreen Reputation No Yes

When Should You Use a Self-Signed Certificate Instead of a CA-Issued One?

Self-signed certificates work well for internal testing, staging builds, and development pipelines where end users will not see trust prompts. CA-issued certificates remain necessary for software distributed outside the organization.

Factor Self-Signed Certificate CA-Issued Certificate
Cost Free Paid, typically renewed yearly
Default trust Not trusted by Windows or browsers Trusted once chained to a root CA
Best use case Internal builds and test environments Public software distribution
Private key storage Software file or local store Hardware module required since June 2023
Setup time Minutes Days, due to identity validation

The same trust gap applies to websites, not just software. SSLInsights.com's comparison of self-signed vs trusted CA certificates covers the website side of this distinction.

Advantages and Disadvantages of Self-Signed Code Signing Certificates

Advantages Disadvantages
Free to create Not trusted by default
Quick setup SmartScreen warnings
Ideal for testing Not suitable for public software
Detects file tampering No verified publisher identity
Full control over certificate Requires manual trust management

What Are the Risks of Self-Signed Code Signing Certificates?

Self-signed code signing certificates trigger Windows SmartScreen and Unknown Publisher warnings because the issuing certificate sits outside any trusted root store.

Since June 1, 2023, the CA/Browser Forum has required publicly trusted CAs to issue code signing certificates only when the private key is generated and stored on hardware meeting FIPS 140-2 Level 2 or Common Criteria EAL 4+, according to Entrust's overview of the CA/B Forum update (2022).

Extended Validation certificates no longer grant automatic SmartScreen trust, and even CA-issued certificates can still show warnings on brand-new files until they build download reputation, according to Microsoft's SmartScreen reputation documentation (2026).

Self-signed certificates also are not accepted for MSI or EXE installers submitted to the Microsoft Store, which requires a certificate chaining to the Microsoft Trusted Root Program.

SSLInsights.com's guide to fixing the Unknown Publisher warning in Windows 10 walks through temporary workarounds and permanent fixes using a trusted certificate.

Practitioner's Note

Across our testing on Windows 10 and 11, self-signed certificates created with PowerShell run local scripts without issue once the execution policy allows signed scripts. Distributed installers still show SmartScreen warnings until the publisher builds a download history. We recommend keeping self-signed certificates strictly inside internal pipelines, separate from any public release process.

— SSLInsights Editorial Team

Frequently Asked Questions About Self-Signed Code Signing Certificates

Is a self-signed code signing certificate safe?

Yes. A self-signed code signing certificate can securely verify file integrity and detect tampering. However, because it is not issued by a trusted Certificate Authority (CA), operating systems and users cannot automatically verify the publisher's identity. For internal testing and development, self-signed certificates are generally safe. For public software distribution, a CA-issued certificate is recommended.

Do self-signed code signing certificates work with Windows SmartScreen?

Yes, but Windows SmartScreen does not automatically trust self-signed certificates. Users may still see Unknown Publisher or reputation warnings because the certificate does not chain to a trusted Certificate Authority.

Can a self-signed code signing certificate be used in production?

Generally not for public distribution. Windows, macOS, and app stores require certificates chaining to a trusted root. Managed enterprise devices can add the certificate to their local trust stores for internal apps.

Does a self-signed certificate prevent tampering detection?

No. The signature still detects any change to the file after signing, even though the publisher identity itself is not verified by a trusted third party.

How long should a self-signed code signing certificate be valid?

Most teams set 1 to 3 years, using -days 365 to 1095 in OpenSSL, matching typical CA certificate lifespans for consistent testing.

Can I convert a self-signed certificate to a CA-issued one later?

Not directly. You generate a new certificate signing request and obtain a fresh certificate from a CA. The private key can sometimes be reused if it meets the CA's hardware requirements.

Does timestamping matter for self-signed certificates?

Yes. Adding a timestamp during signing, using SignTool's /t flag, preserves signature validity after the certificate expires.

What file types can a self-signed code signing certificate sign?

EXE, DLL, MSI, and PowerShell (PS1) files on Windows, plus JAR files using jarsigner and macOS apps using codesign.

"At SSLInsights.com, one of the most common questions we hear is why a signed application still shows Unknown Publisher. The signature itself is valid - the trust chain is what is missing, and that gap is exactly what a self-signed certificate exposes."

— SSLInsights Editorial Team

Final Words

Generating a self-signed code signing certificate takes only a few commands in OpenSSL or PowerShell, and it works for internal testing right away. Production software intended for public distribution still needs a certificate chained to a trusted root, ideally backed by a hardware signing service. As CA/Browser Forum rules continue to tighten private key storage, cloud-based signing services are likely to become the default even for smaller development teams.

About the Author:

The SSLInsights Editorial Team is a group of cybersecurity professionals and website administrators at SSLInsights.com, focused on SSL/TLS, encryption, and code signing topics. The team maintains SSLInsights.com's library of certificate guides and free SSL tools.