How to Sign an EXE File

Prepare the Final EXE

Build the release version first. Complete the code changes, dependency updates, configuration changes, packaging, and tests before creating the signature. The file you sign should be the file you intend to distribute.

Do not plan to edit the binary after signing. If the release process replaces the EXE, patches its executable contents, or produces a different binary, treat the replacement as a new artifact that must be signed and verified again.

Get a Code Signing Certificate

If this is a production release, obtain a code signing certificate from a certificate authority that issues certificates appropriate for your software distribution requirements. The certificate identifies the publisher; the matching private key is what lets you create the signature.

For testing, you can use a development or self-signed certificate, but do not present that result as equivalent to a publicly trusted production signature. Before continuing, confirm that the certificate is valid for code signing and that you have access to its private key.

Install or Locate SignTool

SignTool is part of the Windows SDK. Microsoft installs it under the SDK's Bin directory, with architecture-specific folders such as x64. Use the version appropriate for your build environment. Microsoft’s SignTool reference lists the supported commands and options, including the parameters used in the examples below.

signtool

If Windows cannot find the command, either run SignTool from its SDK directory or add the directory to the environment used by your build process. Confirm the executable exists before troubleshooting certificate problems.

Confirm the Certificate and Private Key

A certificate identifies the signer, but the signing operation requires access to the corresponding private key. The private key performs the cryptographic signing operation. A public certificate by itself cannot create the signature. A certificate file that contains only the public certificate is not enough.

For a production environment, do not copy a private key into the build workspace unless your security design explicitly permits it. Hardware-backed and remote signing models keep the private-key operation outside the normal build filesystem.

Choose How SignTool Will Access the Key

The command changes depending on where the certificate and private key are held. Choose the method that matches your setup and the access controls around the key.

Sign the EXE with SignTool

For a password-protected PFX, use the sign command. Current SignTool documentation requires the file digest algorithm to be specified, and Microsoft recommends SHA-256 for new signing operations.

signtool sign /fd SHA256 /f "C:\Keys\codesigning.pfx" /p "PFX_PASSWORD" "C:\Release\ExampleApp.exe"

The signing operation hashes the relevant PE image data and uses the private key to create the signature. The certificate and signature are embedded into the executable's certificate table. The application code is not replaced by the certificate.

For a certificate already available in the Windows store, a typical selection command is:

signtool sign /fd SHA256 /n "Example Company" "C:\Release\ExampleApp.exe"

When several certificates could match, select the intended certificate explicitly rather than relying on an ambiguous match.

Add an RFC 3161 Timestamp

A trusted timestamp records evidence associated with when the signature was made. For current Authenticode signing, use an RFC 3161 timestamp service and specify the timestamp digest algorithm. The separate timestamping step should be checked to confirm that the returned token is embedded in the signature.

signtool sign /fd SHA256 /tr "TIMESTAMP_URL" /td SHA256 /f "C:\Keys\codesigning.pfx" /p "PFX_PASSWORD" "C:\Release\ExampleApp.exe"

The /tr option identifies the RFC 3161 timestamp service, while /td SHA256 specifies the digest algorithm used for the timestamp. Microsoft’s Authenticode timestamping documentation describes the timestamping workflow and the role of RFC 3161 timestamps in signed software.

After timestamping, inspect the signature to confirm that the timestamp is actually present. Do not assume a successful signing command means the timestamp was successfully embedded.

Verify the Signed EXE with SignTool

Verification is a separate operation from signing. Run it against the exact file that you intend to distribute. For platform-specific checks, follow the Windows signature verification procedure.

signtool verify /pa /v "C:\Release\ExampleApp.exe"

The /pa option uses the Default Authentication Verification Policy rather than the driver verification policy, while /v provides detailed output. A successful command evaluates the signature, certificate chain, and trust under the selected policy. Microsoft’s SignTool verification documentation explains how to verify a file signature with these options.

Inspect the Signature in Windows

Use Windows Explorer as a second check. This confirms what an end user can inspect through the normal file properties interface.

Review the signer name, signature status, certificate details, certification path, and timestamp information. If Windows reports that the digital signature is not valid, stop the release process and investigate before distribution.

Understand What Changes After Signing

Signing does not make an EXE immutable. It creates a cryptographic relationship between the signed PE image and the signature. If data covered by the Authenticode image hash is changed afterward, verification can fail because the calculated hash no longer matches the signed hash.

Do not patch the executable, replace embedded resources, rebuild it, or otherwise alter the signed artifact after signing unless you intentionally sign and verify the resulting file again. The Microsoft PE format specification explains the Portable Executable structure, including the certificate table that stores Authenticode signature data.

Test the Exact Signed Artifact

Launch and test the signed EXE that will actually ship. This catches release-pipeline mistakes where a developer signs one file but packages another.