How to Sign a DLL File

Understand What Signing a DLL Actually Signs

A Windows DLL is a Portable Executable (PE) image. Although it is loaded by another process instead of normally being started as an application, it uses the Windows PE format and can carry an Authenticode signature.

The resulting signature provides evidence about the signed file, the signer identity represented by the certificate, and the certificate chain used for trust evaluation. With a trusted timestamp, the signature also contains time evidence from the timestamp authority.

Check the DLL Before Signing

Make sure the file is the release DLL you intend to distribute. Compilation, debugging, patching, resource changes, instrumentation, optimization, and other post-build operations can change the binary. Perform those operations before signing.

Keep the signing step at the end of the binary build process. If the signed DLL is rebuilt, patched, or otherwise changed, the resulting file must be treated as a new artifact and signed again.

Install or Locate SignTool

Install the Windows SDK if SignTool is not already available on the signing machine. Microsoft provides SignTool with the SDK under its Bin directories, including architecture-specific locations.

signtool

A typical SDK location resembles:

If the command is not on the PATH, run the executable using its full path or configure the build environment to use the intended SDK directory. Microsoft’s SignTool reference documents the supported SignTool commands and options.

Confirm the Certificate and Private Key

signing certificate's role in publisher trust identifies the publisher. The matching private key performs the signing operation. A certificate file that contains only the public certificate cannot create the signature by itself.

Sign the DLL With SignTool

For a password-protected PFX, use SignTool's sign command. Current SignTool builds require the file digest algorithm to be specified. SHA-256 is the normal choice for current signing workflows.

signtool sign /fd SHA256 /f "C:\Keys\codesigning.pfx" /p "PFX_PASSWORD" "C:\Release\ExampleLibrary.dll"

When the certificate is already installed in the Windows certificate store, you can select it by subject:

signtool sign /fd SHA256 /n "Example Company" "C:\Release\ExampleLibrary.dll"

If the store contains multiple matching identities, use a more specific selection method such as the certificate thumbprint. SignTool supports certificate selection options including /n and /sha1.

Add a Trusted Timestamp

Timestamp the DLL as part of the production signing operation. RFC 3161 timestamping adds trusted time evidence without exposing the private key to the timestamp service.

signtool sign /fd SHA256 /tr "TIMESTAMP_URL" /td SHA256 /f "C:\Keys\codesigning.pfx" /p "PFX_PASSWORD" "C:\Release\ExampleLibrary.dll"

The /tr option specifies the RFC 3161 timestamp service and /td SHA256 specifies the timestamp digest algorithm. If the timestamp request fails, follow the release policy rather than silently publishing an incompletely signed artifact.

Verify the DLL Signature

Run verification after signing and timestamping. Verification should be treated as a release gate, not as an optional final check.

signtool verify /pa /v "C:\Release\ExampleLibrary.dll"

Check for the expected signer, valid certificate chain, and timestamp information. A successful verification should be followed by inspection of the actual release DLL, not merely the build output.

Inspect the DLL in Windows

Use Windows Explorer to inspect the signature through the standard file properties interface.

Do Not Modify a Signed DLL

The DLL should be treated as final after signing. Recompiling, patching, modifying resources, instrumentation, post-build processing, or other changes can alter the bytes covered by the signature and cause verification to fail.

The practical sequence is all binary modifications → final DLL → signing → timestamp → signature verification. If a pipeline changes the DLL after signing, identify the changed artifact, rebuild if necessary, and sign the final result again.

Use an HSM or Hardware-Protected Key

An HSM changes where the private key lives, not what gets signed. The DLL is still the artifact being signed, while the private key remains protected by the hardware security boundary.

Production HSM code signing normally involves provider configuration, authentication, authorization, and access controls. The exact SignTool command depends on the cryptographic provider and HSM integration, so do not substitute a PFX workflow for a provider-specific hardware setup.

Use Cloud or Remote Code Signing

remote code signing keeps the private key under controlled infrastructure while the build system submits an authenticated signing request.

Use authentication, authorization, signing policy, audit records, and failure handling appropriate to the service. The release pipeline should stop if the signing request or required verification fails.

Decide Whether a DLL Needs Its Own Signature

There is no useful rule that every DLL in every environment must be signed. The decision depends on distribution model, threat model, platform requirements, enterprise controls, and how the component is consumed.

Understand DLL Signing vs EXE Signing

DLLs and EXEs share the Windows PE format and can use closely related Authenticode signing mechanisms. Their software roles are different: an EXE is normally launched as an application, while a DLL is loaded by another process.

The cryptographic mechanism is closely related, but signing an EXE does not sign its dependent DLLs automatically.

Do Not Assume a Signed EXE Trusts Every DLL

A signed executable and a signed DLL are independent artifacts. Signing the EXE does not transfer its signature or publisher identity to DLLs that it loads.

Applications, Windows components, enterprise security products, and application-specific policies can impose additional rules on loaded modules. Code signing should therefore be kept separate from runtime dependency validation and application security policy.

Sign DLLs Inside an MSI Installer

If the DLL will be distributed inside an MSI, keep the binary and installer signatures as separate release boundaries.

Signing the MSI does not replace signing the DLL. Verify the DLL signature independently and then verify the final MSI after packaging. This preserves the identity and integrity checks at both the component and installer levels.