How to Sign Software Packages and Installers

Signing software packages and installers helps users verify the publisher's identity and detect unauthorized changes to distributed software. For a single Windows executable, follow the process for signing an EXE file; installers and packaged applications may require additional steps.

However, signing an installer is not always the same as signing the application inside it. Some formats require individual components to be signed before packaging, while others support signing the final package. The correct sequence depends on the platform, file format and distribution requirements.

A reliable release process should identify which files need signatures, sign them in the correct order, apply trusted timestamps where appropriate, and verify the final artifacts before publication.

What Is Software Package Signing?

Software package signing uses a digital signature to associate a software artifact with a publisher and help detect changes to signed content. A code signing operation uses a private key to create a signature. The corresponding certificate helps the recipient identify the signer and evaluate trust. A verifier checks the signature against the file and applicable certificate and platform policies.

Which Software Files Need to Be Signed?

The signing method must match the artifact and its target platform. A generic public Code Signing certificate does not replace platform specific requirements, such as Apple's Developer ID signing and notarization or Microsoft's applicable driver signing process.

How to Sign a Windows EXE Installer

Windows installers commonly use Authenticode signatures. Microsoft SignTool can sign an executable using an appropriate Windows code signing certificate and its associated private key.

Sign the installer

First, ensure that the final installer has been built and tested. Then run a command similar to this:

signtool sign /a /fd SHA256 /tr "https://timestamp.digicert.com" /td SHA256 "MyInstaller.exe"

This example uses SignTool to select a suitable signing certificate automatically and request a timestamp from the specified timestamp service.

• /a selects the best available matching signing certificate.
• /fd SHA256 sets the file digest algorithm.
• /tr specifies an RFC 3161 timestamp server.
• /td SHA256 sets the timestamp digest algorithm.

The example timestamp URL is illustrative of a commonly used service endpoint. Confirm the current endpoint and usage requirements with the timestamp provider. If several certificates are available, automatic selection may choose an unintended certificate. In production, explicitly select the intended certificate or configure your signing service to use the correct identity.

Verify the signed installer

signtool verify /pa /v "MyInstaller.exe"

Review the result and confirm that the signature is valid, the expected publisher is shown, and the timestamp information meets your release requirements.

A successful verification does not guarantee that Windows SmartScreen will display no warnings. Publisher reputation and other security signals are evaluated separately.

How to Sign a Windows MSI Installer

Microsoft Installer packages can also be signed with SignTool. The main difference is the artifact being signed: an MSI package rather than an executable. See the dedicated instructions for signing an MSI installer for the focused package workflow.

Sign the MSI file

signtool sign /a /fd SHA256 /tr "https://timestamp.digicert.com" /td SHA256 "MyInstaller.msi"

Verify the MSI signature

signtool verify /pa /v "MyInstaller.msi"

Sign the final MSI after its contents and package metadata have been finalized. If you modify and rebuild the MSI afterward, sign and verify the new artifact again.

What if the MSI installs a signed executable?

Sign the executable separately if your release policy requires it, and sign the MSI after packaging is complete. This allows users and administrators to inspect the signatures of both the installer and the installed application.

How to Sign a macOS Application and Installer Package

macOS uses Apple's code signing infrastructure. Software distributed outside the Mac App Store may also need to meet Developer ID, notarization and Gatekeeper requirements. The process often involves signing the application bundle, creating a package, signing the package and completing any required notarization workflow.

Sign the application bundle

codesign --force --options runtime --timestamp \
  --sign "Developer ID Application: Example Company" \
  "/path/to/MyApp.app"

Use the actual signing identity installed in your keychain. The required options depend on the application's architecture and distribution requirements. For bundles containing frameworks, helper applications or other nested code, follow Apple's signing order and ensure each required component is correctly signed. Avoid treating --deep as a substitute for signing nested components properly.

Verify the application signature

codesign --verify --deep --strict --verbose=2 "/path/to/MyApp.app"

This is a useful diagnostic command, but it does not independently prove that the application satisfies every notarization or distribution requirement.

Build and sign a package installer

For workflows that distribute a signed .pkg installer, use Apple's productbuild with an appropriate Installer certificate identity:

productbuild \
  --component "/path/to/MyApp.app" /Applications \
  --sign "Developer ID Installer: Example Company" \
  "MyInstaller.pkg"

The Developer ID Installer identity is distinct from the Developer ID Application identity used to sign application code. Confirm that the relevant identities are available and that the package structure matches the chosen productbuild options.

Verify the package signature

pkgutil --check-signature "MyInstaller.pkg"

For applicable distribution workflows, complete notarization and check the result separately. Package signing, application signing and notarization address related but different requirements.

For Apple application bundles, use the appropriate macOS application signing workflow alongside the separate installer package steps described above.

How to Sign a Java JAR Package

Java Archive files can be signed using the JDK's jarsigner utility. The signer uses a private key associated with a signing certificate stored in a supported keystore or signing provider.

Sign the JAR file

jarsigner \
  -keystore signing-keystore.p12 \
  -storetype PKCS12 \
  -tsa https://timestamp.example.com \
  -digestalg SHA-256 \
  -sigalg SHA256withRSA \
  application.jar \
  release-key

Replace the keystore path, timestamp URL, signature alias and algorithms with values supported by your certificate and Java environment. This example assumes an RSA key and a PKCS#12 keystore; it is not appropriate for every signing setup.

For production signing, avoid exposing keystore passwords in shell history, command line arguments or CI/CD logs. A protected key provider or managed signing service may offer a safer integration.

Verify the signed JAR

jarsigner -verify -verbose -certs application.jar

Review the verification output and any warnings. Confirm that the expected entries are signed and that the signing certificate is trusted under the target Java environment's security policy. A JAR signature does not automatically sign a separate installer or every application file distributed alongside the archive.

How to Sign Linux Packages

Linux package signing depends on the distribution, package format and distribution method. RPM and Debian based systems, for example, use different signing and verification workflows.

Application signing may use a separate mechanism where the application format or deployment system supports one. Do not assume that an Authenticode certificate can be used directly to sign an RPM or Debian repository. Follow the relevant distribution's documented signing process and configure clients to trust the appropriate signing keys.

For packages distributed through a repository, verify both the package and repository trust mechanisms where applicable.

What Is the Correct Signing Order?

The signing sequence matters because changes made after signing can invalidate a signature. Use this general release pattern and adapt it to the relevant platform and file format.

This is a general release pattern, not a universal sequence for every platform. macOS bundles and nested components have specific signing requirements. Some packaging systems also have format specific rules for signing and metadata generation.

Common Problems When Signing Installers

When a signature fails, use a structured code signing error troubleshooting process to inspect the certificate, key access, timestamp and final artifact.

Integrate Package Signing Into CI/CD

For frequent releases, package signing should be part of the automated release pipeline rather than an informal step performed after deployment preparation.

The exact order should be adapted to the platform and package format.

• Keep production private keys in an approved protected signing environment.
• Give signing permission only to authorized release jobs and identities.
• Prevent untrusted pull requests and unapproved branches from accessing production signing capabilities.
• Avoid placing exportable private keys in source control, build artifacts or unprotected pipeline variables.
• Keep signing logs, artifact hashes and verification results for audit and troubleshooting.
• Fail the release if a mandatory signing or verification step fails.

For recurring releases, connect package signing with automated code signing in CI/CD and define the checks that must pass before a release is published.

Frequently Asked Questions

Final Checklist Before Publishing

Confirm each item before the signed release is distributed.