The PDF signer has the class name: org.signserver.module.pdfsigner.PDFSigner.


The main purpose of the PDF signer is to add digital signatures to PDF documents.

The signer supports the addition of visible or invisible signatures. Both visible and invisible signatures serve the same purpose of signing document, and technically are equivalent in that sense. The difference is that when visible signature is applied to a document, signature image (in shape of rectangle) is placed at the specified place in the document, clicking on which will allow seeing properties of the signature (Adobe Acrobat Reader).

On the other hand when invisible signature is applied, signature properties are accessed through menu items. For visible signatures properties such as : custom signature image, signature rectangle, page at which signature rectangle to be drawn and others can be specified (see Available Properties below)

PDF Signer can also apply timestamp to a signature. If the signature is timestamped, it can be viewable through signature properties in Adobe Acrobat Reader. Timestamping is used to prove that document was signed before the time specified by timestamp token. If the signature is not timestamped then the signature time specified in the signature properties is not considered to be trusted. It is strongly advised to apply timestamp to a signature, and the TSA module can be used for this purpose.

Also CRL or OCSP Response of the signer's certificate can be embedded inside the signature package. Embedding CRL or OCSP response with the package will help validate signature even after the signer's certificate is expired. (Though it will not totally guarantee the long term signature preservation. Topic of long term signature preservation for archival purposes is a large one and is discussed to be implemented in future versions of SignServer).

The PDF Signer can also be configured to enforce that certain PDF permissions are not available in the signed document and/or that certain permissions should be removed.

PDF passwords

PDF documents can optionally be protected by a password. There are two different types of passwords:

  • User password: Also sometimes referred to as "open password" or "document password". Can be used for reading an encrypted document.
  • Owner password: Also sometimes referred to as "permission password" or "security restriction password". It can be used for reading an encrypted document and making changes to a document that has permissions.

If a document is protected by an Owner password, it has to be supplied with the request for SignServer to sign the document. If the document is protected by a User password, either the User password or the Owner password has to be supplied with the request for SignServer to sign the document.

PDFSigner Requests

PDF signing requests can be served using either web services or the web server interface (HTTP). See Integration for general information about the different interfaces.
For the web server interface the GenericProcessServlet can be used. The PDFSigner supports the extra request field "pdfPassword" letting the client supply a PDF password to be used for opening the PDF for signing (not required unless the PDF is already password protected).
For the old web services interface the request should contain an encoded GenericProcessesRequest and the response will be an GenericProcessResponse. It is possible to supply a PDF password by including it in the requestMetaData with the key "pdfPassword".

Worker Properties

The following properties can be configured with the signer:

REASONThe reason included in the PDF signature and displayed by the PDF reader.
Default: "Signed by SignServer".
LOCATIONThe location included in the PDF signature and displayed by the PDF reader.
Default: "SignServer".
ADD_VISIBLE_SIGNATURESetting that control whether signature to be added should be visible or invisible.
Possible values: True or False.
Default: False.

Specifies the page on which the visible signature will be drawn. This property is ignored if ADD_VISIBLE_SIGNATURE is set to False. Possible values:

  • First: Signature drawn on first page of the document.
  • Last: Signature drawn on last page of the document,
  • page_number: Signature is drawn on a page specified by numeric argument. If the specified page number exceeds the page count of the document, the signature is drawn on the last page. If the page_number specified is not numeric (or negative number), the signature will be drawn on the first page.

Default: First.


Specifies the rectangle signature is going to be drawn in.
This property is ignored if ADD_VISIBLE_SIGNATURE is set to False. Syntax is: (llx,lly,urx,ury).
llx =left lower x coordinate,
lly=left lower y coordinate,
urx =upper right x coordinate,
ury = upper right y coordinate

Default: "400,700,500,800".


If we want the visible signature to contain custom image, specify image as base64 encoded byte array. Alternatively, the custom image can be specified by giving a path to image on file system.

(warning) If specifying a path to an image, "\" should be escaped (thus C:\photo.jpg => "C:\\photo.jpg").

(warning) If specifying image as base64 encoded byte array, "=" should be escaped (thus "BBCXMI==" => "BBCXMI\=\=").

If both of properties are set, VISIBLE_SIGNATURE_CUSTOM_IMAGE_BASE64 will take priority. To disable the feature, do not set the properties.
Default: not set (no custom image).
These properties are ignored if ADD_VISIBLE_SIGNATURE is set to False.

(warning) Note that in a clustered environment, it is advised to specify image as base64 string, since image data will be stored in a central database. Otherwise, each node should contain copy of the image, and each image managed separately (e.g. on image updates, or insertion of new image for different worker).


If we want our custom image to be resized to specified rectangle (set by VISIBLE_SIGNATURE_RECTANGLE), then set to True. If set to True, the image might look different than the original (as an effect of resizing). If set to False, the rectangle drawn will be resized to specified image's sizes.
If set to False, the llx and lly coordinates specified by the VISIBLE_SIGNATURE_RECTANGLE property will be used for drawing the rectangle (urx and ury will be calculated from specified image's size).
This property is ignored if ADD_VISIBLE_SIGNATURE is set to False, or if custom image to use is not specified. Possible values: True, False.
Default: True.

CERTIFICATION_LEVELSet this property to have the document certified with a certifying signature.
Possible values:
NOT_CERTIFIED: The document is not certified.
FORM_FILLING: The document is certified but the form can be filled in without invalidating the signature.
FORM_FILLING_AND_ANNOTATIONS: The document is certified but the form can be filled in and annotations added without invalidating the signature.
NO_CHANGES_ALLOWED: The document is certified and no changes can be made.


If we want to timestamp document signature, specify timestamp authority URL.
This will cause time stamp requests to be issued via HTTP requests. Under high load, this can lead to thread deadlocks in the application server if using a localhost URL (using a time stamp signer running in the same server). In this case, use the internal mechanism described below). To not timestamp document signature, do not set the property.

(warning) iI path contains characters "\" or "=" , these characters should be escaped (thus "\" = "\\", "=" =>"\=").

(warning) Cannot be set at the same time as TSA_WORKER.

Default: not set (no timestamping).


Specify a worker ID or worker name for a time stamp signer
This will use internal calls and can only be used for a time stamp authority running in the same SignServer instance.

(warning) Use instead of TSA_URL when using a time stamp signer running in the same SignServer instance to avoid thread deadlocks under high load.

(warning) Cannot be set at the same time as TSA_URL.

Default: Not set (no timestamping).

TSA_USERNAME & TSA_PASSWORD If the TSA requires authentication for timestamping, specify username and password. If the TSA does not require authentication, do not set these properties. These properties are ignored if TSA_URL is not set (no timestamping).
Default: not set (tsa does not require authentication).
EMBED_CRL If we want to embed the CRL for signer certificate inside the signature package set to True, otherwise set to False.
Default: "False".
TSA_DIGESTALGORITHMAlgorithm for timestamp digests. Optional, default: SHA-256.

To embed the OCSP response for the signer certificate inside the signature package, set to True, otherwise set to False.

(warning) Issuer certificate (of signing certificate) should be in certificate chain.
(warning) OCSP responses must contain a nextUpdate field in order for off-line validation to work with Adobe Reader. For EJBCA OCSP Responder, see configuration of ocsp.untilNextUpdate in

Default: False.

ARCHIVETODISK If we want the produced signed document to be stored in the local file system set this property to true and add the ARCHIVETODISK_PATH_BASE property explained below.
Default: False.
ARCHIVETODISK_PATH_BASEThe file path to the folder to store the signed documents in.
Required if ARCHIVETODISK is True.
ARCHIVETODISK_PATH_PATTERN Pattern used for creating sub-folders under the ARCHIVETODISK_PATH_BASE folder.
Current date can be put in by adding ${DATE:yyyy} where yyyy can be replaced be the same syntax as defined in the class java.text.SimpleDateFormat. Other fields are:
  • ${WORKERID}: ID of the worker processing the request.
  • ${WORKERNAME}: Name of the worker processing the request.
  • ${REMOTEIP}: IP address of requestor.
  • ${REQUESTID}: ID of the request (number).
  • ${TRANSACTIONID}: Transaction ID of the request (number and dashes).
  • ${USERNAME}: User name if username/password authentication has been used.
  • ${CUSTOMHEADER1}: Value of the custom HTTP request header X-SignServer-Custom-1.

Default: "${DATE:yyyy/MM/dd}".


Pattern used for creating the filename. The same fields and syntax as for the ARCHIVETODISK_PATH_PATTERN property can be used.
Default: "${WORKERID}-${REQUESTID}-${DATE:HHmmssSSS}.pdf".

REFUSE_DOUBLE_INDIRECT_OBJECTS True if PDF documents containing multiple indirect objects with the same name should be refused. Used to mitigate a collision signature vulnerability described in Default: False.

Reject signing of the document if any of the permissions in the comma separated list would be in the document.
Available permissions (from the PDF reference, version 1.6, page 99, TABLE 3.20):

    Print the document to a representation from which a faithful digital copy of the PDF content could be generated. When this is not set (and ALLOW_DEGRADED_PRINTING is set), printing is limited to a low-level representation of the appearance, possibly of degraded quality.
    Modify the contents of the document by operations other than those controlled by ALLOW_MODIFY_ANNOTATIONS, ALLOW_FILL_IN, and ALLOW_SCREENREADERS.
    Copy or otherwise extract text and graphics from the document, including extracting text and graphics (in support of accessibility to users with disabilities or for other purposes).
    Add or modify text annotations, fill in interactive form fields, and, if ALLOW_MODIFY_CONTENTS is also set, create or modify interactive form fields (including signature fields).
    Fill in existing interactive form fields (including signature fields), even if ALLOW_MODIFY_ANNOTATIONS is not set.
    Extract text and graphics (in support of accessibility to users with disabilities or for other purposes).
    Assemble the document (insert, rotate, or delete pages and create bookmarks or thumbnail images), even if ALLOW_MODIFY_CONTENTS is not set.
    Print the document (possibly not at the high-est quality level, depending on whether ALLOW_PRINTING is also set).

Default: Unset/empty (no permissions are rejected)

SET_PERMISSIONS Replace the current permissions (if any) with the permissions specified in this comma separated list of permissions. Available permissions: The same permission names as for the property REJECT_PERMISSIONS.
(warning) This property cannot be specified if REMOVE_PERMISSIONS is used.
(warning) This property and the REMOVE_PERMISSIONS property only sets the permissions setting in the document. All permissions might not be enforced by the PDF reader, and some permissions specified to be allowed by this property, might not be allowed when opening the final document (i.e. if that would invalidate the signature and/or certification).
(warning) If the document is not already protected by an owner password and the SET_OWNERPASSWORD is not specified, a random password will be used as owner password.
Default: Unset (permissions are not set by this property)
REMOVE_PERMISSIONS Remove all permissions specified in this comma separated list from the document. Available permissions: The same permission names as for the property REJECT_PERMISSIONS.
This property can not be specified if SET_PERMISSIONS is used.
(warning) This property only removes the permissions listed even if some permissions (i.e. ALLOW_PRINTING) by the standard gives more permissions (i.e. also ALLOW_DEGRADED_PRINTING). To remove all permissions to print remove both ALLOW_PRINTING and ALLOW_DEGRADED_PRINTING. To still have ALLOW_DEGRADED_PRINTING it is possible to specify to only remove ALLOW_PRINTING.
See (warning) notes for REMOVE_PERMISSIONS which also applies to this setting.
Removing only ALLOW_DEGRADED_PRINTING has no effect, as degraded printing is implicitly allowed if printing is allowed.
Default: Unset/empty (no permissions are removed)
SET_OWNERPASSWORD Sets the specified password as owner password in the document.
The same permissions as before will be used (unless other properties will change them). The same encryption algorithm as the original document will be used. If the original document did not use any encryption then the default encryption algorithm will be used.
Default: unset (if the permissions are changed, the existing owner password will be used or if no such password is used in the document a semi-random password will be created)

Sets the hash algorithm used for the message digest and signature hash.
Setting this property will also imply a minimum PDF version depending on the hash used. The resulting PDF will be upgraded to this version if it is higher than the version used in the original PDF. Since upgrading the version requires re-creating the file (i.e. not appending the new signature), it is not supported on an already signed document (i.e. using a hash algorithm requiring a higher version than the original document). Attempting to sign such a document will result in a failure.

Supported hash algorithmsAlgorithm PDF version
SHA1 1.3
SHA256 1.6
SHA384 1.7
SHA512 1.7
RIPEMD160 1.7

Default setting is SHA256.