How to Sign Software With a Code Signing Certificate

Determine the Artifact and Its Signature Format

Before choosing a command, identify the actual artifact format. A Windows PE executable, a Java JAR, and a macOS application bundle do not use the same signature container or verification mechanism. The signing tool must understand the file format because it needs to place signature metadata where the platform expects it.

Android and iOS use platform-specific application signing systems and should be treated as separate workflows rather than as another PFX-to-file signing command.

Windows EXE/DLL: Sign With SignTool and Understand the Parameters

For Windows PE files, SignTool is the most useful concrete example because its parameters expose the important pieces of the signing operation. The command below uses a password-protected PFX and requests an RFC 3161 timestamp.

signtool sign ^
  /f "C:\signing\publisher.pfx" ^
  /p "PFX_PASSWORD" ^
  /fd SHA256 ^
  /tr "TIMESTAMP_URL" ^
  /td SHA256 ^
  "C:\release\ExampleApp.exe"

Microsoft's current SignTool documentation explicitly distinguishes /fd for the file digest from /td used with /tr for the timestamp digest. The timestamp URL must be supplied separately through /tr.

What SignTool Is Doing to the Windows File

For an Authenticode-signed PE file, the signature is not simply appended as arbitrary text. Windows has a security directory in the PE format that can point to the certificate table containing the signature information. The signing operation therefore changes the file in a format-aware way.

The exact internal structure matters when diagnosing why a file verifies before a build step but fails afterward: if a later operation changes covered bytes, the verifier recomputes a different digest.

Add an RFC 3161 Timestamp as Part of the Signature Operation

A timestamp is a second cryptographic relationship layered onto the signing evidence. SignTool's /tr option requests an RFC 3161 timestamp, and /td specifies the digest algorithm requested for that timestamp operation. The TSA returns a timestamp token that the signing tool incorporates into the signature evidence.

signtool sign ^
  /f "C:\signing\publisher.pfx" ^
  /fd SHA256 ^
  /tr "TIMESTAMP_URL" ^
  /td SHA256 ^
  "C:\release\ExampleApp.exe"

Microsoft documents /tr as the RFC 3161 timestamp option and /td as its associated timestamp digest option.

A File Can Be Cryptographically Signed but Still Fail Trust

Signature validity and trust are separate checks. A verifier can mathematically validate a signature with the public key in a certificate and still reject the certificate because its chain is not trusted, its purpose is wrong, its status is unacceptable, or the target policy does not recognize the issuing hierarchy.

This distinction is especially useful when a file “works on my machine.” A development machine may contain an intermediate or root certificate that is absent from another machine. That does not prove that the signed artifact itself changed.

PowerShell: Inspect the Certificate and Signature, Not Just the Command

PowerShell uses Authenticode for script signatures. The useful technical distinction is that the certificate selection and the script's signature status are inspectable independently.

$cert = Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert
Set-AuthenticodeSignature -FilePath .\deploy.ps1 -Certificate $cert

Get-AuthenticodeSignature .\deploy.ps1 |
  Format-List Status, StatusMessage, SignerCertificate, TimeStamperCertificate

The first command searches the current user's personal certificate store for certificates marked for code signing. The signing cmdlet applies the certificate to the script. The verification cmdlet exposes the signature status, signer certificate, and timestamp certificate information that can be used during troubleshooting.

If the script changes after signing, the signature no longer corresponds to the current script contents. Re-sign the final version instead of treating the previous signature as reusable evidence.

macOS: Sign the Bundle, Then Verify the Bundle

Apple code signing is bundle-aware. The signing identity is associated with the Keychain, and the signing system can validate static code objects such as applications, tools, frameworks, plug-ins, and scripts. A macOS application can contain nested signed code, so signing order and bundle structure matter.

codesign --force --verbose --sign "Developer ID Application: Example Company" "Example.app"

codesign --verify --deep --strict --verbose=2 "Example.app"

The verification stage should be performed against the final application bundle. Apple's documentation describes code signing as a mechanism that allows the system to detect changes to signed code and also exposes signing information and requirements for evaluation.

Do not treat notarization as the signing command itself. Code signing establishes the application's signing evidence; notarization is a separate Apple distribution/security process.

CI/CD: Put the Cryptographic Boundary After Testing

A secure release pipeline should treat the signing step as a controlled boundary around a finalized artifact. The pipeline builds and tests first, freezes the release candidate, invokes the signing mechanism, validates the signature and timestamp, and only then publishes the artifact.

source
  ↓
build
  ↓
test
  ↓
final artifact
  ↓
authenticated signing request
  ↓
protected private-key operation
  ↓
timestamp
  ↓
verification
  ↓
release

A Reproducible Windows Signing Test

When a production pipeline fails, reduce the problem to one known artifact and one known certificate. The objective is to separate key access from timestamping and verification.

If step 3 fails, investigate certificate/private-key/provider access. If step 3 succeeds but step 4 fails, investigate the generated signature and verification policy. If the signature verifies locally but the published copy fails, compare the exact bytes of the local and published artifacts before changing certificate settings.

Release Checklist With Technical Acceptance Criteria