Client-Side Hashing

This describes the various options for having the hashing performed at the client-side instead of doing all the steps in the signing at the server-side. This is also sometimes referred to as "hash signing".

The main benefit is that the original file does not have to be sent to the server.

CMS Detached Signatures

Detached signatures allow the signature to be placed in a separate file next to the original file, and thus the original file does not have to be updated. With CMS signatures, what is covered by the signature is a set of attributes (unless it is a direct signature) where one of the attributes is called messageDigest, which is the hash of the original file. This means that in order to create a CMS detached signature, it is sufficient to get the hash of the original file as input.

The CMS Signer is for instance configured to accept a hash as input by setting CLIENTSIDEHASHING=TRUE, or by allowing the client to specify if the input is the original file or a hash of it, by configuring ALLOW_CLIENTSIDEHASHING_OVERRIDE=TRUE.

When the client sends the request, the following properties need to be provided as request metadata:


where SHA-256 should be replaced with the name of the hash algorithm used to digest the data. The algorithm must be one of those configured in signer with the ACCEPTED_HASH_DIGEST_ALGORITHM property.

The following commands can be used to create a detached CMS signature using this mode with a CMSSigner set up to default to consider requests as client-side computed hash (using the CLIENTSIDEHASHING property) (assuming a GNU/Linux, or Unix-like system is used):

$ echo "data-to-be-signed" | openssl sha256 -binary > pre-computed-hash.bin
$ ./bin/signclient signdocument -workername CMSSigner
-infile pre-computed-hash.bin -outfile signed.p7s

Plain Signatures

For plain signatures (as produced by the Plain Signer), generally the whole file is sent to the signer and returned is the small signature. However, as the plain signature schemes involves a hash operation, it is be possible to perform that on the client side.

For the Plain Signer, this can be achieved by configuring the signer with a signature algorithm with the word NONE instead of the name of the hash. For example: "NONEwithRSA" or "NONEwithECDSA". Note that the input to the signer has to be in a particular format when using the "NONEwithRSA" algorithm for the final signature to be correct. See RFC#3447 for details.

Sample Usage (with NONEwithECDSA algorithm)

openssl x509 -in PlainSigner-certificate.pem -noout -pubkey > plainsigner-pubkey.pem
openssl dgst -sha256 -out pre-computed-hash.bin -binary sample.txt
bin/signclient signdocument -workername PlainSigner -infile pre-computed-hash.bin -outfile sample.sig
openssl dgst -signature sample.sig -verify plainsigner-pubkey.pem -SHA256 sample.txt

Embedded Signature Formats

ENTERPRISE EDITION This is a SignServer Enterprise Edition (EE) feature.

For signature formats where the signature is to be placed within the original document, additional logic has to be implemented on the client-side in order to, typically, first prepare the document for signing, compute the digest and send it to the server, and then finally embed the signature within the file.

On the client-side, support has been implemented for "client-side hashing and construction" for Authenticode signing of Portable Executable (PE) files (i.e. EXE, .DLL,..), Windows Installer files (.MSI), and for Java Archives (.JAR,.APK,..) in the SignClient signdocument command. Support for other file types such as PDF may also be implemented.

On the server-side, typically a CMS Signer is needed but since Authenticode and JAR signing are producing slightly different variants of the CMS signatures, different implementations are available for use. For Authenticode, there is the MS Authenticode CMS Signer, and for JAR signing the JArchive CMS Signer.




Required in order to use client-side hashing otherwise a normal request is sent.


The digest algorithm to use for the hash (or for the hashes within the hash file depending on file type).


Flag to provide extra options for signing supported by a particular file type:

-extraoption KEEPSIGNATURE=

Only for signing JAR files. For more information on the property KEEPSIGNATURE, see JArchive Signer.


Only for signing JAR files. For more information on the property REPLACESIGNATURE, see JArchive Signer.


Only for signing JAR files. For more information on the property SIGNATURE_NAME_VALUE, see JArchive Signer.

-extraoption ZIPALIGN=

Only for signing JAR files. For more information on the property ZIPALIGN, see JArchive Signer.

Sample Usages

$ signclient signdocument -clientside -workername MSAuthCodeCMSSigner -infile unsigned.exe
-outfile signed.exe -digestalgorithm SHA-256
$ signclient signdocument -clientside -workername MSAuthCodeCMSSigner -infile unsigned.msi
-outfile signed.msi -digestalgorithm SHA-512
$ signclient signdocument -clientside -workername JArchiveCMSSigner -infile unsigned.jar
-outfile signed.jar -digestalgorithm SHA-256
$ signclient signdocument -clientside -workername JArchiveCMSSigner -infile unsigned.apk
-outfile signed.apk -digestalgorithm SHA-256 -extraoption ZIPALIGN=TRUE -extraoption SIGNATURE_NAME_VALUE=SIGNER02