How to Sign an MSI Installer
Follow a practical MSI-specific signing workflow from the finished Windows Installer package through Authenticode signing, trusted timestamping, verification, and release. The key rule is simple: finalize the installer first, then sign the exact MSI that will be distributed.
Important distinction: signing an MSI does not automatically sign every EXE or DLL stored inside it. Application binaries may need their own signatures before the final MSI is built.
Choose a Code Signing Certificate for Your Windows Installer
Select a certificate suited to your Windows software and release requirements before configuring the MSI signing workflow.
Compare Windows code signing certificatesBefore You Sign the MSI
The Windows SDK includes SignTool. Microsoft documents its signing, timestamping, and verification options in the command-line signing, timestamping, and verification reference.
.msi installerDo not treat SignTool as a certificate issuer. It performs the signing operation using an identity you already control. A self-signed certificate can be useful for development and testing, but it does not provide the same public trust as a production certificate issued by a trusted CA.
Finalize the MSI Before Signing
Complete the installer build before you sign it. That includes application binaries, installer properties, product metadata, package files, custom actions, embedded resources, and any other change that belongs in the release package.
The practical rule is build MSI → make all changes → sign MSI → timestamp → verify → distribute. If the installer is rebuilt or modified after signing, treat the resulting MSI as a new artifact and sign it again.
Understand What the MSI Signature Covers
An MSI is a Windows Installer database/package, not a PE executable. Signing the MSI establishes a signature on the installer package itself. It does not copy that publisher identity into the EXE and DLL files stored inside the package.
MSI signature
Protects the installer package as the distributable artifact and identifies its signer.
Binary signatures
Protect individual EXE, DLL, driver, or other signable files contained in the installer.
Microsoft's Windows Installer digital-signature documentation describes how digital signatures help detect corrupted resources and support signing Windows Installer packages, patches, transforms, merge modules, and external cabinet files.
Sign the EXE and DLL Files Before Building the MSI
If the MSI contains application binaries that users will run or load, sign those binaries as part of the application release process before the final MSI is built. This keeps each artifact's signer and integrity information attached to the artifact itself.
The Microsoft Authenticode signing guidance recommends signing the Windows Installer package as an additional protection layer. An MSI signature does not make an unsigned executable inside the package independently signed or trustworthy.
| Artifact | Typical signing decision | Reason |
|---|---|---|
| MSI | Sign for production distribution | Establishes package-level signer and integrity. |
| EXE | Usually sign | Protects the application binary users execute. |
| DLL | Usually sign | Protects distributed executable code loaded by the application. |
| Driver | Follow driver-specific requirements | Windows driver signing has additional platform rules. |
| Script | Depends on use | Script signing uses a separate signing model. |
Install or Locate SignTool
SignTool is installed with the Windows SDK. Microsoft shows it under the SDK's Bin directory, with architecture-specific folders such as x64. SignTool command options
signtool
If Windows cannot find the command, run it using its full SDK path or add the appropriate SDK directory to the environment used by the release process. A typical installation resembles:
C:\Program Files (x86)\Windows Kits\10\bin\<SDK-version>\x64\signtool.exe
Confirm the Code Signing Certificate and Private Key
The certificate identifies the signer, while the matching private key performs the cryptographic signing operation. Protect that key throughout the release process; the guidance on protecting the code signing private key explains how to sign software without exposing it. Before signing, confirm that the Windows code signing certificate is intended for your release and that the signing environment can use its matching private key.
PFX / P12
- Can contain the certificate and private key.
- May be protected with a password.
- Use SignTool's
/foption to point to the file.
Windows Certificate Store
- Certificate is installed in a Windows store.
- Private key remains associated with the certificate.
- Select the intended certificate by subject or thumbprint.
Multiple certificates matter. If several certificates could match, explicitly identify the production certificate. Accidentally signing an MSI with a test or wrong-company certificate creates a release problem even if the cryptographic signature itself is valid.
Sign the MSI With SignTool
For a PFX-based certificate, use the SignTool sign command. Current SignTool builds require the file digest algorithm to be specified, and Microsoft recommends SHA-256.
signtool sign /fd SHA256 /f "C:\Keys\codesigning.pfx" /p "PFX_PASSWORD" "C:\Release\ExampleApp-Setup.msi"
signStarts the signing operation./fd SHA256Sets the file digest algorithm./fPoints to the certificate/PFX file./pProvides the PFX password when required.ExampleApp-Setup.msiIdentifies the exact MSI being signed.For a certificate already installed in the Windows certificate store, select it by subject, for example:
signtool sign /fd SHA256 /n "Example Company" "C:\Release\ExampleApp-Setup.msi"
When the store contains multiple possible certificates, use a more specific selection method such as the certificate thumbprint. Microsoft documents /n, /sha1, store selection, and other certificate-selection options in the SignTool reference.
Add a Trusted RFC 3161 Timestamp
For a production MSI, configure trusted timestamping as part of the signing operation. The timestamping guidance for signed software provides further implementation detail. Current SignTool supports RFC 3161 timestamping with /tr and requires the timestamp digest option /td for current SDK builds.
signtool sign /fd SHA256 /tr "TIMESTAMP_URL" /td SHA256 /f "C:\Keys\codesigning.pfx" /p "PFX_PASSWORD" "C:\Release\ExampleApp-Setup.msi"
Do not treat the timestamp service as part of the certificate itself. It is a separate service that provides timestamp evidence. If the timestamp request fails, stop the release or follow your documented fallback process. Do not silently publish an installer that failed the required signing policy.
Verify the MSI Signature With SignTool
Verification should happen immediately after signing and again against the exact artifact that will be published. Use the Default Authentication Verification Policy with detailed output.
signtool verify /pa /v "C:\Release\ExampleApp-Setup.msi"
Cryptographic result
Confirm that the embedded signature validates against the MSI as it exists now.
Trust result
Confirm that the signer certificate and chain satisfy the selected Windows verification policy.
The SignTool verification documentation explains that SignTool verification checks whether a signing certificate was issued by a trusted authority and whether it has been revoked, subject to the selected verification options.
Inspect the MSI Signature in Windows
Use Windows Explorer as a second verification path. This is useful because it shows the signature information available through the normal file interface.
| Inspect | What to confirm |
|---|---|
| Signer / Publisher | Expected organization and signing identity. |
| Signature status | Windows reports the signature as valid. |
| Certificate issuer | Expected CA or issuing hierarchy. |
| Certificate validity | Certificate dates and status are appropriate. |
| Digest / signature algorithm | Matches your release signing policy. |
| Certification path | Chain reaches a trusted root in the verification environment. |
| Timestamp | Trusted timestamp evidence is present and validates. |
Do Not Modify the MSI After Signing
An MSI is a structured installer database. Changing its properties, tables, files, streams, packaging, or other covered content after signing can make the signature invalid. Rebuilding the MSI after signing produces a different package and therefore requires another signing operation.
Microsoft notes that administrative installation can modify an installation package in a way that invalidates the original digital signature, after which an administrator can resign the package. Windows Installer digital signature behavior
Verify the Installer and Its Internal Binaries
At release time, verify the MSI itself and verify the application binaries inside it that are expected to carry their own signatures. This gives you two separate checks instead of assuming one signature covers the entire software stack.
Microsoft's external cabinet signature documentation explains the additional signature mechanisms used for external cabinet files. A simple package signature should not be presented as proof that every installation resource is independently signed.
Verify the MSI Downloaded From Your Website
The final release check should happen against the exact file users can download. A build server can successfully sign one MSI while a deployment or publishing step accidentally uploads another.
Confirm the downloaded file has the expected publisher, valid signature, valid certificate chain, and timestamp. If your release process records hashes, compare the published artifact against the intended release artifact as an additional identity check.
MSI Signing in CI/CD
The MSI should be signed at the end of the installer build stage, after application binaries have been signed and the package has passed installer tests. Signing should then become a CI/CD signing workflow rather than an informal manual step.
HSM and Cloud Signing
When the private key should not be exportable to a build machine, use a hardware security module or an approved remote/cloud signing service. The exact integration depends on the provider, but the security boundary is different from storing a PFX directly on the build host.
HSM
The private key remains inside protected hardware. The build process requests a signing operation without receiving an exportable private key.
- Access control
- Key non-exportability
- Auditability
Cloud / remote signing
The signing service controls the private key remotely and applies authentication and authorization before performing the operation.
- Authenticated requests
- Signing policy
- Centralized audit records
Protect the Private Key Used to Sign Your MSI
For build environments that should not hold an exportable private key, review hardware protected and remote signing options before automating releases.
Explore HSM code signing optionsCommon MSI Signing Problems
| Problem | What to check first |
|---|---|
| SignTool cannot find MSI | Check the exact build artifact path and confirm the MSI exists before signing. |
| No certificate found | Check certificate selection, store, subject, thumbprint, and certificate validity. |
| Certificate has no private key | Confirm the selected certificate is associated with its private key or use the correct PFX/provider. |
| Private key access fails | Check account permissions, provider configuration, HSM access, or remote signing authorization. |
| Timestamp fails | Check the RFC 3161 URL, network path, proxy rules, and /td SHA256. |
| Signature invalid after packaging | Compare the signed MSI with the published MSI and identify any post-signing modification. |
| Wrong publisher | Inspect which certificate was actually selected during signing. |
| Certificate not trusted | Inspect the certificate chain and trust environment used for verification. |
| Works on build machine only | Compare certificate trust, private-key access, SDK version, network access, and signing provider configuration. |
Why Does My Signed MSI Show Unknown Publisher?
Do not treat “Unknown Publisher” as a single signing error. Work through the trust chain and identity in order.
A valid cryptographic signature can still produce an unexpected trust or publisher result if the wrong certificate was used, the chain cannot be validated in the target environment, or the certificate does not represent the publisher you expected.
Why Did the MSI Signature Break?
Start with the exact artifact that now fails verification. Compare it with the MSI that passed verification immediately after signing.
Common causes include rebuilding the MSI, modifying MSI database content, applying a transform after signing, replacing the package during deployment, or publishing a different copy from the one that was verified.
Complete MSI Signing Example
Use ExampleApp-Setup.msi as the final release artifact. The sequence below keeps the MSI signing operation at the end of the installer build process.
signtool sign /fd SHA256 /tr "TIMESTAMP_URL" /td SHA256 /f "C:\Keys\codesigning.pfx" /p "PFX_PASSWORD" "C:\Release\ExampleApp-Setup.msi"
signtool verify /pa /v "C:\Release\ExampleApp-Setup.msi"
Release rule: the MSI that reaches customers should be the exact MSI that passed your final signature verification. If the publishing system changes or replaces the package, verify the resulting download again.
MSI Signing Checklist
Related Signing Workflows
MSI signing is one part of a Windows software release. Use the workflow that matches the artifact you are actually distributing.
Frequently Asked Questions
Does signing the MSI sign the EXE files inside it?
No. The MSI package and the EXE or DLL files inside it are separate signing boundaries. Sign the application binaries individually when they require their own publisher and integrity protection.
Should I sign the EXE files before building the MSI?
For application binaries that need their own signatures, yes. A practical release order is to finalize and sign the binaries, build and test the MSI, then sign and timestamp the final MSI.
Can I modify an MSI after signing it?
Treat the signed MSI as final. Changes to the package can invalidate the signature. If the installer changes, rebuild or update it as required and sign the resulting artifact again.
Can I sign an MSI with a PFX file?
Yes. SignTool supports PFX-based signing. The PFX must provide access to the certificate and corresponding private key, and the file and password should be protected.
Can I use a certificate installed in Windows?
Yes. SignTool supports certificate-store selection by subject, thumbprint, and other certificate-selection options. Be careful when multiple certificates are installed on the signing machine.
Why should the MSI be timestamped?
A trusted timestamp adds time evidence to the signing process. Use an RFC 3161 timestamp service and verify that the timestamp is present on the final MSI.
Should I verify the MSI after uploading it to my website?
Yes. The published or downloaded file is the artifact customers receive. Verify that exact copy so a packaging, CDN, or deployment mistake does not turn into an unsigned or different release.
Sign the Installer at the End of the Build
The safest MSI release workflow keeps the signing boundary clear: sign the application binaries where appropriate, finalize and test the MSI, sign the final package, timestamp it, verify the MSI and required internal binaries, and publish the exact artifact that passed those checks.
Technical references: Microsoft SignTool, Digital Signatures and Windows Installer, and Digital Signatures and External Cabinet Files.
Explore cloud code signing