Skip to main content

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

    Sign a Windows EXE with SignTool: install it from the Windows SDK, run signtool sign with /fd SHA256 and an RFC 3161 timestamp, then verify the signature.

    MS
    My-SSL Security Team
    ·
    12 min read
    ·
    Published July 3, 2026
    ·
    Last updated July 3, 2026

    In short

    To sign an EXE, install SignTool from the Windows SDK, connect the hardware token holding your code signing certificate, and run signtool sign /fd SHA256 /tr http://time.certum.pl /td SHA256 /a MyApp.exe. SignTool versions 10.0.20348.0 and later refuse to sign without the /fd flag, and the timestamp keeps your signature valid after the certificate expires. Check the result with signtool verify /pa /v MyApp.exe.

    Signing a Windows executable takes one command — once everything around that command is in place. The hard parts are the setup: finding signtool.exe (it isn't on Windows by default), getting a certificate Windows will trust, dealing with the hardware token every publicly trusted certificate now ships on, and knowing which of SignTool's look-alike flags are required in current versions. This guide walks the whole path: what signing does, what to prepare, the exact command with every flag explained, and the errors most people hit on their first attempt.

    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.

    What happens when you sign an EXE with SignToolFlow diagram in five steps: SignTool hashes MyApp.exe with SHA-256, the private key on the hardware token signs that hash, the signature and certificate are embedded into the EXE itself, and Windows re-checks the embedded signature every time the file runs.What signtool sign actually doesMyApp.exeyour buildSHA-256 hashfile fingerprintPrivate keysigns the hashon your USB tokenSignature + certembedded in EXEtravels with the fileWindowsverifiesat launchThe private key never leaves the token. Any change to the file after signing —even one byte — breaks the hash match and invalidates the signature.
    The signature is baked into the EXE itself, which is why a signed installer stays verifiable on machines that have never seen your certificate before.

    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. 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. In practice that means you plug the token in, install the CA's middleware (for Certum, the proCertum card software), and the certificate appears in the Windows certificate store where SignTool can find it. Loose .pfx files with exportable keys are only a thing for older certificates and self-signed test setups.

    Standard or EV?

    Both certificate levels sign identically with SignTool — the command in this guide doesn't change. The differences are in vetting depth and how quickly Microsoft SmartScreen learns to trust your files. If you haven't picked one yet, the OV vs EV comparison walks through the decision.

    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:

    Check that SignTool is available
    "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.

    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. Here is what each flag does.

    Anatomy of the signtool sign commandLabeled breakdown of the command: signtool sign, then /fd SHA256 as the required file digest algorithm, /tr with the timestamp server URL, /td SHA256 as the timestamp digest, /a to auto-select the certificate, and finally the file to sign.The signing command, piece by piecesigntool sign/fd SHA256/tr http://time.certum.pl/td SHA256/aMyApp.exethe signingsubcommandfile digest algorithm —required since SignTool10.0.20348.0RFC 3161 timestamp server —keeps the signature validafter the cert expiresdigest for thetimestamp itselfauto-select the bestcertificate in your storethe fileto signWorks the same for .exe, .dll, .msi, .msix, .cab, .sys, and PowerShell .ps1 files.
    Two flags trip people up: /fd is now mandatory, and /tr (not the older /t) is the one that speaks RFC 3161.
    Sign an EXE with the certificate from your store or token
    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:

    Sign from a PFX file (legacy and test certificates only)
    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.

    Timestamped vs untimestamped signature over timeTimeline from 2026 to 2030. The certificate itself is valid from 2026 to 2029. A signature made with a timestamp stays trusted through 2030 and beyond, while a signature made without a timestamp stops being trusted the day the certificate expires in 2029.Why the timestamp outlives your certificate20262027202820292030certificate expiresCertificatevalid for 3 yearsSigned + /trstill trusted after expiry — the timestamp proves when it was signedSigned, no /trtrusted only while the certificate is valid✕ breaks in 2029
    Skip the timestamp and every build you ever shipped stops verifying on the same day — usually long after anyone remembers why.

    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.

    Verify the signed file
    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.

    "SignTool Error: No file digest algorithm specified"

    You're on SignTool 10.0.20348.0 or newer, where /fd stopped being optional. Add /fd SHA256 before the filename. Older guides omit the flag because earlier SignTool versions merely warned and fell back to SHA-1 — which you don't want anyway.

    "No certificates were found that met all the given criteria"

    SignTool can't see a usable certificate. Confirm the token is plugged in and its card software is installed (without the middleware, Windows can't reach the key at all), check that the certificate shows up in certmgr.msc under Personal → Certificates for the same user running SignTool, and make sure any /n value matches the certificate's subject name exactly. When in doubt, rerun with signtool sign /debug … — it lists every certificate considered and why each was skipped.

    Timestamp errors: "The specified timestamp server either could not be reached or returned an invalid response"

    First check the flag/server pairing: /tr needs an RFC 3161 server and /td, while legacy /t expects the old Authenticode protocol — crossing them fails. If the pairing is right, the server may be briefly busy: retry, or switch to another public server from the list above. Corporate proxies that block plain HTTP are another regular culprit, since timestamp URLs use http, not https.

    The file is signed, but SmartScreen still warns users

    Expected for a new certificate. SmartScreen trusts reputation, and reputation accumulates as downloads of your signed files spread — the signature's job is to make sure that reputation sticks to your publisher identity instead of resetting with every release. Our SmartScreen publisher reputation guide explains how the verdict is scored, what builds reputation faster, and what to expect in the first weeks after switching certificates.

    Frequently Asked Questions

    Get instant answers to common questions about SSL certificates and our services.

    Still Have Questions?

    Our SSL experts are available 24/7 to help with any questions about certificates, installation, or technical issues.

    The bottom line

    Install the SDK once, memorize one command — signtool sign /fd SHA256 /tr http://time.certum.pl /td SHA256 /a MyApp.exe — and verify with /pa /v. The timestamp flag is the one that saves you from a support fire two years from now, so never ship without it. Still need the certificate itself? My-SSL carries Certum code signing certificates from $99/year, and our document checklist shows what the validation asks for before you order.