How to Sign Software Before Deployment

Code signing should be completed and verified before software is deployed to production or distributed to users. It helps recipients identify the software publisher and determine whether signed content has been modified since signing.

Signing software too early can create problems if the build changes afterward. Signing it too late can leave insufficient time to verify the certificate, resolve errors or confirm that the final artifact is ready for release.

A reliable deployment process treats code signing as a release control. The team builds and tests the software, finalizes the release artifact, signs it using an authorized signing identity, verifies the signature, and deploys the exact artifact that passed verification.

What Does Signing Software Before Deployment Mean?

Signing software before deployment means applying a digital signature to the release artifact before it reaches its intended destination, such as a production environment, customer download page, application distribution channel or internal software repository.

The signature is created using a private key associated with a code signing certificate or another platform supported signing identity. The certificate helps establish the publisher's identity, while signature verification helps detect changes to the signed content.

A typical pre-deployment workflow

The exact sequence depends on the operating system and package format. macOS applications may require nested code signing and notarization, while Windows installers and their embedded executables may need separate signatures.

Why Code Signing Should Happen Before Deployment

Signing before deployment helps establish a consistent release process and prevents unsigned or incorrectly signed artifacts from reaching production.

• Publisher verification. Recipients can inspect the signing identity and determine whether it matches the expected publisher.
• Integrity checks. Signature verification can reveal changes made to signed content after signing.
• Release consistency. Signing becomes a required release step rather than an optional task performed manually after deployment.
• Auditability. Teams can record which release artifact was signed, which identity authorized the signing operation and whether verification succeeded.
• Fewer deployment failures. Verifying the signature before promotion helps catch certificate, timestamp, trust and packaging problems earlier.

Step 1: Prepare the Final Release Artifact

Before signing, confirm that the software is ready for release. Complete compilation, testing, configuration changes and packaging steps that modify the artifact.

Check the following:

• The build passed the required automated and manual tests.
• The release version and package metadata are correct.
• Dependencies and embedded components are finalized.
• The artifact has passed the required security checks.
• The correct certificate or signing identity is available.
• The signing process has access to the protected private key.
• The release pipeline identifies the exact file or package that will be deployed.

Step 2: Sign Software for the Target Platform

The signing command depends on the operating system, file format and signing infrastructure.

Sign a Windows executable

Windows applications commonly use Authenticode signatures created with Microsoft's SignTool.

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

This example selects a suitable available signing certificate and requests an RFC 3161 timestamp. Confirm that the timestamp endpoint is current and appropriate for your workflow.

If the signing environment contains multiple certificates, configure the process to select the intended certificate rather than relying on automatic selection without checking the result.

Sign a Windows installer

For an MSI installer, the process is similar:

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

If the installer contains an executable that also needs a signature, sign that component separately before creating the final installer. Sign the completed MSI after packaging is finished.

Sign a macOS application

macOS applications use Apple's code signing tools and signing identities. A typical Developer ID signing command is:

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

Use the correct installed identity and follow Apple's requirements for nested code, entitlements and Hardened Runtime settings. Applications distributed outside the Mac App Store may also require notarization.

Signing an application bundle is not the same as signing a .pkg installer. If you distribute an installer package, use the appropriate Installer signing identity and verify the package separately.

Sign a Java archive

Java applications distributed as JAR files can be signed with jarsigner:

jarsigner \
  -keystore signing-keystore.p12 \
  -storetype PKCS12 \
  -digestalg SHA-256 \
  application.jar \
  release-key

This example assumes a PKCS#12 keystore and a configured signing alias. Adapt it to your actual key storage and certificate configuration. For production environments, avoid exposing keystore passwords through shell history, logs or unprotected pipeline variables.

Package format matters because installers can contain separately signed components. Signing software packages and installers explains how to sequence component and package signatures without confusing them with application signing.

Step 3: Protect the Private Key During Signing

The deployment pipeline should be able to perform authorized signing operations without unnecessarily exposing private key material.

For production software, consider an HSM, a suitable managed cloud signing service or another approved protected key storage mechanism.

• Restrict signing access to approved users and release identities.
• Separate build permissions from production signing permissions.
• Keep private keys out of source repositories and build artifacts.
• Use supported authentication methods for signing services.
• Prevent untrusted branches and pull requests from invoking production signing.
• Log signing requests and their outcomes.
• Establish a process for responding to suspected key compromise.

Encrypting a private key file or storing its password in a secret manager does not automatically make the key non-exportable. Assess whether the signing environment can retrieve and expose the actual private key.

A protected signing workflow keeps the private key under controlled access while allowing approved releases to be signed. Private key protection for code signing covers ways to reduce exposure during automated and manual signing.

Step 4: Timestamp the Signed Software

A trusted timestamp can help establish when a signature was created. This matters when the signing certificate later expires, because a valid timestamp may allow the signature to remain verifiable under applicable validation rules.

Timestamping does not fix an invalid signature, replace a trusted certificate chain or guarantee acceptance by every platform.

For Windows Authenticode, the SignTool examples above use /tr to specify a timestamp service and /td SHA256 to select the timestamp digest algorithm.

After signing, verify that the timestamp is present and valid. If timestamping is mandatory under your release policy, stop the release when that step fails.

Timestamp validation is a separate release check because a successful signature alone does not confirm that a trusted timestamp was applied. Code signing timestamping describes how timestamping supports long term signature validation.

Step 5: Verify the Signature Before Deployment

Never treat a successful signing command as sufficient proof that the release is ready. Verify the artifact that will actually be deployed.

Verify a Windows executable

signtool verify /pa /v "MyApplication.exe"

Check the output for successful signature verification and inspect the certificate and timestamp information. The /pa option uses the default Authenticode verification policy. Drivers and other specialized artifacts may require different verification policies or additional checks.

Verify a macOS application

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

This is a diagnostic verification command. It does not replace checks for notarization, Gatekeeper acceptance or every distribution requirement. Inspect nested components when verification fails.

Verify a Java archive

jarsigner -verify -verbose -certs application.jar

Review the verification output and warnings. Confirm that the expected entries are signed and that the certificate is trusted under the target runtime's security policy.

Verification commands differ by platform and policy. Windows code signature verification explains the checks used to validate Authenticode signatures before release.

Step 6: Deploy the Exact Artifact That Passed Verification

A release pipeline should promote the verified artifact instead of rebuilding the software independently after verification.

If a new build or packaging operation creates a different file, the previous signature verification does not establish the integrity of that new artifact.

• Record the artifact's version and cryptographic hash.
• Store the verification result with the release record.
• Promote the same artifact between release stages where possible.
• Repeat signing and verification if a later operation changes signed content.
• Ensure the deployment system cannot silently substitute a different artifact.
• Preserve signing and deployment logs for investigation.

This helps connect the signed artifact to the specific release that was approved and deployed.

How to Integrate Code Signing Into a CI/CD Deployment Pipeline

Automated signing is useful when releases are frequent, but the pipeline must prevent unauthorized builds from using production signing credentials.

Configure the pipeline to stop if signing, verification or a mandatory approval fails. Do not let a failed verification become a warning that the release can ignore.

CI/CD signing should be restricted to approved release workflows, while automation handles repeatable signing and verification steps. Signing software in a CI/CD pipeline covers pipeline controls, and automating code signing in CI/CD focuses on reducing manual work without weakening authorization.

Common Problems When Signing Before Deployment

When verification or signing fails, identify whether the cause is the certificate, private key permissions, timestamp service or a changed artifact. Troubleshooting code signing errors provides a structured way to isolate common failures.

Pre-Deployment Code Signing Checklist

Confirm each control before the release is promoted to production or distributed to users.

Frequently Asked Questions