signcode man page

signcode — Digitally sign an PE executable using an X.509 certificate.


signcode [options] filename


Digitally sign an PE executable (CLR assembly, Win32 EXE or DLL) using an  X.509 certificate and it's associated private key. The signature is compatible with Authenticode(r) and can be validated with chktrust (either on Windows or on any platform supported by Mono).


-spc spcfile

The Software Publisher File (spc) that contains the X.509 certificate chain used to digitally sign the PE executable.

-v pvkfile

The Private Key File (pvk) that contains the private key used to digitally  sign the PE executable. This private key must match the public key inside the publisher X.509 certificate.

-a sha1 | md5

The hash algorithm used in the digital signature of the PE executable. The  default algorithm is SHA1.

-$ individual | commercial

Add information about the publisher, i.e. if the signature is generated by an individual or a commercial entity.

-n description

Add a textual description of the signed file.

-i url

Add a URL associated to the publisher or the signed file.

-t url

URL to a timestamp service to countersign the PE executable. Countersignature is required if you want the PE executable signature to be valid after the publisher certificate expires. The countersignature proves that the publisher had a valid (non-expired) certificate when the PE executable was signed.

-tr #

Number of retries to get a timestamp for the countersignature.

-tw #

Delay (in seconds) between the retries to get a timestamp for the countersignature.

-k name

CryptoAPI key container name (when not using -v).

-p name

CryptoAPI provider name (when not using -v).

-y #

CryptoAPI provider type (when not using -v or -p).

-ky signature | exchange | #

CryptoAPI key type (when not using -v).

-r localMachine | currentUser

CryptoAPI key location (when not using -v).

-help , -h , -? , /?

Display help about this tool.

Other Code Signing Technologies

Assemblies are PE files that can also be strongnamed using the sn.exe tool. The  order of code signature is important if a file requires both an Authenticode  and a strongname signature. Strongname must be applied before the Authenticode  signature. Applying a strongname after the Authenticode signature, like  re-signing an assembly (e.g. delay-sign), will invalidate the Authenticode  signature.

Known Restrictions

signcode cannot generate Authenticode signatures for CAB files.


Written by Sebastien Pouliot

Mailing Lists

Visit for details.

Web Site

Visit for details

See Also


Referenced By

cert2spc(1), chktrust(1), httpcfg(1), makecert(1), secutil(1).