How to Sign an EXE with SignTool (Step by Step)

What signing an EXE actually does

Signing an EXE embeds a cryptographic signature and your certificate inside the file itself. SignTool hashes the file with SHA-256, signs that hash with your private key, and writes both the signature and the certificate into the executable. Windows then verifies the signature every time the file runs, proving who published it and that nobody has modified it since.

This mechanism is called Authenticode, and it covers more than just .exe files — the same command signs DLLs, MSI and MSIX installers, drivers, and PowerShell scripts, and, once Microsoft's Office SIPs are registered, the VBA macros inside Word, Excel and PowerPoint files. Bundled interpreters are a special case worth knowing about: the command below signs a PyInstaller-built Python EXE exactly the same way, but the signature stops at the file you ship and never reaches the runtime it unpacks at launch. Two things it does not do are worth naming. It doesn't encrypt the file: anyone can still open and read a signed EXE. And it doesn't vouch for quality — a signature says "this came from us, unmodified," nothing more. The deeper background on how the trust model works lives in our code signing certificates explainer; here we stay on the practical task.

What you need before you sign

Three things: signtool.exe (installed with the Windows SDK), a code signing certificate issued by a publicly trusted CA, and — for every certificate issued since June 1, 2023 — the hardware token or HSM that holds its private key, with the CA's card software installed so Windows can talk to it. Testing setups can substitute a self-signed certificate.

• SignTool itself. It ships with the Windows SDK, not with Windows. The next section covers where to get it.
• A code signing certificate. For software you distribute to the public, it must come from a CA whose roots Windows trusts. My-SSL sells Certum standard and EV code signing certificates that work with SignTool out of the box; the paperwork side of getting one is covered in our required documents guide.
• The hardware holding your key. Under the CA/Browser Forum rules in force since June 1, 2023, CAs may only issue code signing certificates whose private keys live on certified hardware — a USB token, smart card, or HSM. The Certum certificates My-SSL sells keep the key on a virtual card in Certum's SimplySign cloud, so there is no token to plug in: you connect SimplySign Desktop with a one-time code from the SimplySign mobile app, and SignTool then picks the certificate by its thumbprint (/sha1), as our SimplySign Desktop setup guide shows step by step. With a CA that ships a USB token instead, you plug it in and install that CA's card software. Loose .pfx files with exportable keys are only a thing for older certificates and self-signed test setups.

Where to get SignTool

SignTool installs as part of the Windows SDK. Download the SDK installer from Microsoft, keep the "Windows SDK Signing Tools for Desktop Apps" component ticked, and signtool.exe lands under C:\Program Files (x86)\Windows Kits\10\bin\<version>\x64\. If you already use Visual Studio, you can install the same SDK from the Visual Studio Installer's Individual Components tab instead.

The full SDK is large, but the installer lets you deselect everything except the signing tools, which keeps the download small. After installation, either call SignTool by its full path or open a "Developer Command Prompt for VS", which puts it on PATH for you. To confirm it works, run:

"C:\Program Files (x86)\Windows Kits\10\bin\10.0.26100.0\x64\signtool.exe" /?

# Or, in a Developer Command Prompt:
signtool /?

One version note that matters later: since SignTool 10.0.20348.0, the /fd flag is required — older tutorials omit it because earlier versions only printed a warning. If you're running a recent SDK (and you should be), treat /fd SHA256 as a fixed part of the command.

SignTool only runs on Windows. If your build machine or CI runner is Linux or macOS, you can sign the exact same EXE, MSI, and DLL files there with a cross-platform Authenticode signer — see how to sign a Windows EXE on Linux or macOS with osslsigncode.

The signing command, flag by flag

With the token plugged in and its middleware installed, one command signs the file: signtool sign /fd SHA256 /tr http://time.certum.pl /td SHA256 /a MyApp.exe. SignTool finds the certificate in the Windows store, prompts for the token PIN, hashes the file, signs the hash on the token, and embeds the result. With a Certum cloud certificate there is no token: connect SimplySign Desktop first, then name the certificate with /sha1 and its thumbprint in place of /a, as Certum's own signing manual does. Here is what each flag does.

signtool sign /fd SHA256 /tr http://time.certum.pl /td SHA256 /a MyApp.exe

# Several certificates installed? Pick one explicitly
# by subject name...
signtool sign /fd SHA256 /tr http://time.certum.pl /td SHA256 ^
  /n "Your Company Name" MyApp.exe

# ...or by the certificate's SHA-1 thumbprint:
signtool sign /fd SHA256 /tr http://time.certum.pl /td SHA256 ^
  /sha1 a1b2c3d4e5f67890a1b2c3d4e5f67890a1b2c3d4 MyApp.exe

A successful run prints Successfully signed: MyApp.exe. When the private key is on a token, expect the PIN dialog from the card software to pop up during the run — that's the hardware confirming the signing operation, and it's the reason a stolen copy of your certificate file alone can't sign anything.

If you're working from an older certificate that still exists as a .pfx file, or from a self-signed test certificate, the /f flag signs directly from the file:

signtool sign /f mycert.pfx /p pfx-password /fd SHA256 ^
  /tr http://time.certum.pl /td SHA256 MyApp.exe

Avoid putting the PFX password in scripts that get committed anywhere — and remember this path doesn't exist for publicly trusted certificates issued after mid-2023, because their keys can't be exported to a file in the first place.

Timestamping: the flag you must not skip

The /tr flag asks a timestamp authority to certify when you signed. Without it, every signature you make becomes invalid the day your certificate expires — including software shipped years earlier. With it, Windows keeps trusting the signature indefinitely, because the timestamp proves it was applied while the certificate was still valid.

Certificates only live one to three years. Your software usually lives longer. Timestamping is what bridges that gap, and it costs nothing — public timestamp servers are free to use. (How the RFC 3161 protocol works under the hood, and the edge cases where a timestamp can't save a signature, get a full treatment in our code signing timestamps explainer.) The servers you'll meet most often:

• http://time.certum.pl — Certum (fits naturally if your certificate is from Certum)
• http://timestamp.digicert.com — DigiCert
• http://timestamp.sectigo.com — Sectigo

Watch out for the near-identical older flag: /t speaks the legacy Authenticode timestamp protocol, while /tr speaks RFC 3161, the current standard, and needs /td SHA256 alongside it. They can't be mixed, and each expects a server that speaks its protocol — pointing /t at an RFC 3161 URL is a classic source of confusing errors. New setups should always use /tr with /td SHA256.

Verify the signature

Run signtool verify /pa /v MyApp.exe to confirm the signature is valid. The /pa flag applies the standard Authenticode policy used for regular software (without it, SignTool checks against the stricter Windows driver policy and often reports good signatures as untrusted), and /v prints the full certificate chain and timestamp details. For the other platforms and artifact types — PowerShell, osslsigncode on Linux, jarsigner, NuGet — and for what each exit code means in a build gate, see how to verify a code signature.

signtool verify /pa /v MyApp.exe

# Look for these lines in the output:
#   Issued to: Your Company Name
#   The signature is timestamped: <date and time>
#   Successfully verified: MyApp.exe

Check the "signature is timestamped" line specifically — a file can verify today and still be missing the timestamp that keeps it valid after your certificate expires. For a second opinion without the command line, right-click the EXE → Properties → Digital Signatures tab, where Windows shows the publisher name, the timestamp, and the full chain.

Common SignTool errors and fixes

Almost every first signing attempt fails on one of four errors: a missing /fd flag, SignTool not finding your certificate, a timestamp server mismatch, or a SmartScreen warning that signing alone was never going to remove. Each has a specific, quick fix — match your error message below. For anything not listed here, our SignTool error reference decodes the HRESULT printed after SignerSign() failed and works through the hardware-token causes that most older advice predates.