Complete Guide to Creating Self-Signed Code Signing Certificates on Windows

In software development and secure deployment processes, code signing serves as a critical mechanism for ensuring software integrity and source authenticity. While commercial code signing certificates provide broader trust chains, self-signed certificates offer cost-effective solutions for internal development, testing environments, and specific application scenarios.

Modern Approach: Creating Self-Signed Certificates with PowerShell

For systems running Windows Server 2012, Windows Server 2012 R2, Windows 8.1 or later versions, Microsoft has officially deprecated the traditional MakeCert tool and recommends using the New-SelfSignedCertificate command in PowerShell. This approach is more modern and easily integrable into automated workflows.

First, generate the code signing certificate using the following PowerShell command:

New-SelfSignedCertificate -DnsName email@yourdomain.com -Type CodeSigning -CertStoreLocation cert:\CurrentUser\My

This command creates a new self-signed code signing certificate in the current user's personal certificate store. The -DnsName parameter specifies the certificate subject name, and while the specific value isn't critical for self-signed certificates, meaningful identifiers are recommended.

Certificate Export and Trust Configuration

After generating the certificate, it needs to be exported and configured for trust. First, export the certificate (without private key):

Export-Certificate -Cert (Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert)[0] -FilePath code_signing.crt

The index [0] here selects the first code signing certificate in the store. If multiple certificates exist in the system, precise filtering can be done using thumbprints or other attributes.

Next, import the certificate into trust stores:

Import-Certificate -FilePath .\code_signing.crt -Cert Cert:\CurrentUser\TrustedPublisher
Import-Certificate -FilePath .\code_signing.crt -Cert Cert:\CurrentUser\Root

These two import operations add the certificate as a trusted publisher and root certificate authority respectively, ensuring the system trusts code signed with this certificate.

Code Signing Practice

After configuration, the certificate can be used to sign PowerShell scripts:

Set-AuthenticodeSignature .\script.ps1 -Certificate (Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert)

This command uses the code signing certificate from the store to digitally sign the specified PowerShell script. Signed scripts will display valid digital signature information during execution.

Traditional MakeCert Method Reference

For development environments still using older Windows versions (such as Windows 7), the MakeCert tool remains a viable option. The complete MakeCert workflow includes creating a certificate authority (CA), importing CA certificates, generating code signing certificates, and format conversion steps.

Creating a self-signed CA certificate:

makecert -r -pe -n "CN=My CA" -ss CA -sr CurrentUser ^
         -a sha256 -cy authority -sky signature -sv MyCA.pvk MyCA.cer

This command creates a self-signed certificate authority using SHA-256 algorithm, with private key stored in MyCA.pvk file and certificate saved in MyCA.cer file.

Importing CA certificate to trust store:

certutil -user -addstore Root MyCA.cer

Generating code signing certificate:

makecert -pe -n "CN=My SPC" -a sha256 -cy end ^
         -sky signature ^
         -ic MyCA.cer -iv MyCA.pvk ^
         -sv MySPC.pvk MySPC.cer

Converting certificate to PFX format:

pvk2pfx -pvk MySPC.pvk -spc MySPC.cer -pfx MySPC.pfx -po password

Code Signing Tool Usage

Using the generated PFX file for code signing:

signtool sign /v /f MySPC.pfx ^
              /t http://timestamp.url MyExecutable.exe

Timestamp services ensure that signatures remain valid even after certificate expiration. Commonly used timestamp services include:

• http://timestamp.verisign.com/scripts/timstamp.dll
• http://timestamp.globalsign.com/scripts/timstamp.dll
• http://timestamp.comodoca.com/authenticode
• http://timestamp.digicert.com

Self-Signed Certificate Applicability Analysis

The main difference between self-signed and commercial certificates lies in trust scope. Commercial certificates are issued by publicly trusted certificate authorities and are widely recognized across the internet. Self-signed certificates are trusted only within environments where corresponding trust relationships have been configured.

Self-signed certificates are appropriate choices in the following scenarios:

• Internal development and testing environments
• Plugin signing for specific applications (such as Revit plugins)
• Cost-sensitive projects
• Temporary solutions requiring rapid deployment

Self-signed certificates typically have longer validity periods (up to 17 years), avoiding the hassle of periodic renewal and revalidation required for commercial certificates. However, for scenarios requiring wide distribution or commercial release, commercial code signing certificates are still recommended.

Tool Availability and Compatibility

The MakeCert tool is typically included in the Windows SDK and can be accessed through Visual Studio command prompt. For modern development environments, the PowerShell approach is recommended as it provides better compatibility and more streamlined workflows.

By appropriately selecting certificate creation methods and correctly configuring trust relationships, development teams can flexibly address different code signing requirements while maintaining security.