SignServer Manual

*** APPSRV_HOME ***

Set APPSRV_HOME to point to your application server installation.

export APPSRV_HOME=/opt/jboss-4.2.3.GA
                        

*** ANT_HOME ***

Set ANT_HOME to point to your Apache Ant installation.

export ANT_HOME=/usr/share/ant
                        

*** ANT_OPTS ***

Set ANT_OPTS to give Ant more memory for building SignServer.

export ANT_OPTS="-Xmx512m -XX:MaxPermSize=128m"
                        

*** SIGNSERVER_HOME ***

Set SIGNSERVER_HOME to point to your SignServer installation.

export SIGNSERVER_HOME=/opt/signserver
                        

*** SIGNSERVER_NODEID ***

Set SIGNSERVER_NODEID to an unique ID for the server.

export SIGNSERVER_NODEID=node1
                        

*** Fix web service problem in JBoss ***

Edit jboss-beans.xml to force the endpoint URL to be generated based on the WSDL request by commenting out the line:

    <property name="webServiceHost">${jboss.bind.address}</property>

For JBoss 4.2.3.GA the file is available under: server/default/deploy/jbossws.sar/jbossws.beans/META-INF/

For JBoss 5.1.0.GA the file is available under: server/default/deployers/jbossws.deployer/META-INF/

*** Fix JBoss 5 bug with Oracle JDK ***

If you are using Oracle's JDK and JBoss 5.1.x you need to copy SIGNSERVER_HOME/lib/1.6/bc*.jar to JBOSS_HOME/server/default/lib/. Remember this when it's time for upgrades! This is a bug tracked by JBoss as JBAS-7882.

cp signserver_build.properties.sample signserver_build.properties
                    

*** Application server configuration ***

Set appserver.type to the application server (jboss or glassfish).

appserver.type=jboss
                        

*** Web GUI configuration ***

Uncomment j2ee.web-nohttps=true if SignServer should be used to configure the keystore in JBoss.

#j2ee.web-nohttps=true
                        

For GlassFish change httpserver.privhttps to a port configured with HTTPS and client authentication.

httpserver.privhttps=8181
                        

*** Database configuration ***

For GlassFish make sure the datasource.jndi-name and datasource.jndi-name-prefix matches the resource configured in the admin console.

datasource.jndi-name=SignServerDS
datasource.jndi-name-prefix=jdbc/
                        

Select database management system

database.name=mysql
                        

For JBoss set the database connection URL, database driver and username and password.

database.url=jdbc:mysql://127.0.0.1:3306/signserver
database.driver=com.mysql.jdbc.Driver
database.username=signserver
database.password=signserver
                        

*** Web Service Configuration ***

Enable or disable the web services.

signserverws.enabled=true
genericws.enabled=true
validationws.enabled=true
adminws.enabled=true
                        

*** Modules Configuration ***

Enable all modules that should be built and choose if they should be included in the SignServer enterprise application archive (EAR). By setting includemodulesinbuild=true (default) all modules are built in. Otherwise for each module specify that it should be enabled and included:

module.xmlsigner.enabled=true
module.xmlsigner.include=true
...
                        

For GlassFish to enable debug logging include the Log4j module.

module.log4j.enabled=true
module.log4j.include=true
                        

*** Cluster Class Loader Configuration ***

The cluster class loader can be used in development for having the code of the signers loaded on all nodes. If it is not used the modules must be built into signserver.ear either by specifying that for each module (as in previous section) or by specifying includemodulesinbuild=true to include all modules.

Notice that this feature is experimental and should not be used in production. It will be removed in future versions of SignServer.

To enable the cluster class loader specify:

useclusterclassloader=true
                        

*** Command Line Interface ***

bin/signserver.sh getstatus brief all
Assuming JBoss JNDI provider...
===========================================
Executing Command on host : localhost
===========================================


Current version of server is : SignServer 3.2-svn
                    

*** Graphical User Interface ***

bin/admingui.sh	
						

*** Web Interface ***

Point your web browser to http://localhost:8080/signserver for demo web pages and local documentation.

*** module add ***

The "module add" command loads both the code and the configuration from a MAR file and thus requires the clustered class loader to be enabled.

bin/signserver.sh modules add dist-server/MODULE.mar CONFIGURATION
                        

*** setproperties ***

The "setproperties" command loads all the properties from a property file that can define one or many signers. The code for the signers needs to be deployed to the application server together with SignServer either by setting includemodulesinbuild=true to include all modules or by setting individual module.MODULENAME.include=true properties in signserver_build.properties.

bin/signserver.sh setproperties doc/sample-configs/CONFIGURATION.PROPERTIES
                        

bin/signserver.sh reload 4711
                    

*** Production configuration with HSM ***

To install a production signer using an HSM instead of the demo signer you can edit doc/sample-config/qs_mrtdsodsigner_configuration.properties and change from SoftCryptoToken to PKCS11CryptoToken and comment all properties under SoftCryptoToken properties and instead fill in all properties under PKCS11CryptoToken properties and then run:
(note after changing properties in the file it needs to be loaded again with setproperties)

Before starting with an HSM installation you should read the about the PKCS11CryptoToken in the plugins section of the manual.

bin/signserver.sh setproperties doc/sample-config/qs_mrtdsodsigner_configuration.properties
bin/signserver.sh getconfig 9
bin/signserver.sh reload 9
bin/signserver.sh generatecertreq 9 "C=SE,CN=MRTD SOD Signer" SHA256WithRSA mrtdsodsigner.req

Where 9 is the signerId that you got when running the 'setproperties' command.
This will create a certificate request that you can get signed by your CA. When you have received the response you can import it and the CA certficate. If you have the returned signer certificate as cert.pem and the CA certificate as cacert.pem, then:

cat cert.pem cacert.pem > certchain.pem
bin/signserver.sh uploadsignercertificate 9 glob cert.pem
bin/signserver.sh uploadsignercertificatechain 9 glob certchain.pem
bin/signserver.sh reload 9

Hint: you can use EJBCA to create keys on a PKCS#11 HSM using clientToolBox.
ejbcaClientToolBox.sh PKCS11HSMKeyTool generate /opt/ETcpsdk/lib/linux-x86_64/libcryptoki.so 2048 DSSignKey 5

*** General Commands ***

getstatus: Returns the status of the given worker, it says if its crypto token is active or not and the loaded 'active' configuration. It is possible to get a brief summary or a complete listing for one worker or all configured workers. If all workers are displayed will also all the global configuration parameters be displayed.

getconfig: Returns the current worker or global configuration depending on options.

For worker configuration observe that this configuration might not have been activated yet, not until a reload command is issued.

setproperty: Sets a custom property used by the worker or crypto token, see reference for the given Worker and CryptoToken for available properties.

setproperties: Command used to batch a set of properties, both for the global and worker configuration. It can be used to configure a Signer in a test environment, dump all the properties and upload it into production.

It reads all the configuration properties form a property file and depending on the contents of the key it sets the given property. All properties will be set according to the following defined rule set.

Rule	Comment
Properties starting with id<num>.	Will set the property to the value of the given id to the worker with the given id.
Properties starting with name<name>.	Will set the property to a worker with the given name. (If the name doesn't exists a unique id will be generated and assigned).
Property keys containing GENID<NUM>, example WORKERGENID1 or GLOB. WORKERGENID1	The SignServer will find a free unique id and assign substitute all GENID<num> with this id.
Properties starting with glob.	Will set a global property with global scope.
Properties starting with node.	Will set a global property with node scope.
Properties starting with -<other prefix><value>	Will remove the property, either worker or global.

See the directory 'sample-configs' for examples.

removeproperty: Removes a configured property

dumpproperties: This tool will dump all configured properties for one or all workers in the system into a property file. If the configuration for one worker is dumped it can be used to transfer the configuration from one installation to another. If all configurations is dumped, it can be used as a backup tool.

uploadsignercertificate: Used to upload the certificate when the worker only needs the actual signing certificate and not the entire chain.

uploadsignercertificatechain: Used when uploading a complete certificate chain to the worker. Which command that is supposed to be used is depending on the worker and crypto token used.

generatecertreq: Used to generate a certificate request for a worker to be signed by a certificate authority. It takes distinguished name and signature algorithm as parameters and writes the request in PEM format to file.

activatecryptotoken: Used to activate crypto tokens. Authentication code is usually the PIN used to unlock the keys on the HSM. Not used if the token is set to auto-activation.

deactivatecryptotoken: Brings a crypto token off-line. Not used if token is set to auto-activation.

*** SignServer Specific Commands ***

Authorization Related

These commands are used to configure the internal client certificate authorization when it is turned on. It controls which clients that is authorized to request a processable worker.

addauthorizedclient: Adds a client certificate to a processable workers list of acceptable clients using this worker. Specify certificate serial number in hex and the Issuer DN of the client certificate.

removeauthorizedclient: Removes added client certificate entries.

listauthorizedclients: Displays the current list of acceptable clients.

Database Related

resync:

The 'resync' command is used after a SignServer had a complete database failure. When this happens will the Global Configuration become in 'Off-line' mode and it's not possible for the nodes to communicate internally and the Global Configurations will not be in sync any more. After the database is up again can this command be sent to the node that have the most valid Global Configuration and write it to the database. After this will the Global Configuration be in 'On-line' mode again.

Archive Related

This commands can be used for processable workers that have archiving turned on. They are used to find specific archived responses. It's up to the implementation of the worker if it supports archiving or not and it is up to the choosen Archiver if it archives the data in way that it can be queried using this commands. For Archivers other than the default "OldDatabaseArchiver" quering might have to be done directly in the database or by some custom application.

archive findfromarchiveid: Command used to extract archived data from database identified by the archive Id.

The Id depends on the worker, in case of the TSA is the TimeStampInfo serial number used. The data is stored with the same file name as the archive id in the specified path.

archive findfromrequestip: Used to extract all archived data requested from a specified IP address.

All data is stored as separate files with the archive id as file name in the specified path.

archive findfromrequestcert: Used to extract all archived data requested from a client by specified it's certificates serial number and issuer DN.

All data is stored as separate files with the archive id as file name in the specified path.

Group Key Service Related

These commands only applies for group key services.

groupkeyservice pregeneratekeys: Command used to pregenerate a given number of group keys for a given group key service and stores them unassigned encrypted in the database. This commands can be used to let the cluster work on CPU insensitive key generation during low business hours.

groupkeyservice removegroupkeys: Command used to remove group keys not used any more. A time range of when created, first used and last fetched can be used as criteria.

groupkeyservice switchenckey: Command used manually switch the encryption key used to secure the group keys in database. Usually is the encryption key switched automatically but this command can be used to override this default behaviour.

Module Archive Related

There exists three commands for managing module archives in a cluster, they are quite straightforward. Use the command 'signserver.sh/cmd module' command for more details.

module add: The 'add' command uploads a '.mar' file to the cluster. It is possible to define in which environment the module should be used, for instance 'production' or 'test' but this is all depending on which environments the module supports.

If signature verification is required by the server it is also possible to specify a path to a JKS key store along with an alias and password to the key used.

module remove: Command used to remove a specified version of a module.

module list: Command to list all uploaded modules, it is also possible to see all JAR files that is included in the modules.

Administrators Related

wsadmins -list:

Lists administrator certificates (certificate serial number and issuer DN) for administrators authorized to use the Admin Web Service interface to administrate SignServer.

wsadmins -add:

Authorizes an administrator to use the Admin Web Service interface by certificate serialnumber and issuer DN.

wsadmins -remove:

Removes an administrator from the list of authorized administrators.

*** Connect to SignServer dialog ***

Specify URL to SignServer server as well as keystore and truststore for setting up the HTTPS connection and then click the button Connect. By clicking the button Load defaults the settings from the file default_connect.properties is loaded. If the connection is successful the current settings are stored to connect.properties and displayed the next time the dialog is openned.

Web Service URL: Base URL to the SignServer server. Default: https://localhost:8443/signserver

Truststore Type: Type of the truststore. Should match the choosen truststore file (if any). Options are: "Use keystore", JKS, PKCS12 or PEM. If "Use keystore" is choosen the trusted certificates are instead taken from the keystore and no truststore is used.

Truststore file path: Path to the truststore file (if any).

Truststore password: Password of the truststore file (if any).

Keystore Type: Type of the keystore. Should match the choosen keystore file path. Options are: JKS, PKCS12 or PKCS11. If PKCS11 is choosen the keystore file path should be the patch to the PKCS#11 shared library file.

*** Main window ***

The SignServer Administration GUI main window consists of a menu bar, a toolbar, the working area and at the bottom a status bar. The working area constists of a left and right part where the left is a list of all configured workers and the right shows details for the selected workers (if any).

*** Main window: Menu bar ***

File -> Exit: Exits the SignServer Administration GUI

Edit -> Activate: Activates the selected worker(s).

Edit -> deactivate: Deactivates the selected worker(s).

Edit -> Renew key...: Opens the Renew key dialog for the selected worker(s).

Edit -> Test key...: Opens the Test key dialog for the selected worker(s).

Edit -> Generate CSR...: Opens the Generate CSR dialog for the selected worker(s).

Edit -> Install certificates...: Opens the Install certificates dialog for the selected worker(s).

Edit -> Renew signer...: Opens the Renew signer dialog for the selected worker(s).

Edit -> Global configuration...: Opens the Global configuration window.

Edit -> Administrators...: Opens the Administrators window.

View -> Refresh: Refreshes the information about all workers.

View -> Status Summary...: Switches to the Status Summary tab for the selected worker.

View -> Status Properties...: Switches to the Status Properties tab for the selected worker.

View -> Configuration...: Switches to the Configuration tab for the selected worker.

View -> Authorization...: Switches to the Authorization tab for the selected worker.

Help -> About...: Opens the about box doc.

*** Main window: Tool bar ***

Refresh: Refreshes the information about all workers.

Activate: Activates the selected worker(s).

Deactivate: Deactivates the selected worker(s).

Renew key...: Opens the Renew key dialog for the selected worker(s).

Test key...: Opens the Test key dialog for the selected worker(s).

Generate CSR...: Opens the Generate CSR dialog for the selected worker(s).

Install certificates...: Opens the Install certificates dialog for the selected worker(s).

Renew signer...: Opens the Renew signer dialog for the selected worker(s).

*** Main window: Status Summary Tab ***

Displays the status summary for the selected worker in the same format as the CLI command "signserver getstatus complete".

*** Main window: Status Properties Tab ***

Displays the status in properties format with the option of viewing details for some properties such as for the certificates.

Details...: Selecting an property and clicking this button opens a dialog box with more information for the property (if supported). Currently for certificates this openns the Certificate details dialog.

*** Main window: Configuration Tab ***

Lists all the selected worker's configuration properties and gives the ability to add, remove or edit properties.

Add...: Adds a new property to the selected worker.

Edit: Edit the selected property.

Remove: Removes the selected property.

*** Main window: Authorization Tab ***

Lists all the authorized client certificates for the selected worker. Notice that this only applies if the worker has the AUTHTYPE set to CLIENTCERT otherwise information about authorized clients might be taken from other sources.

Add...: Adds a new authorized client. If the option "Apply changes to all selected workers" is checked the client is added to all the currently selected workers.

Edit...: Edits the selected authorized client. If the option "Apply changes to all selected workers" is checked the client is modified in all the currently selected workers.

Remove: Removes the selected client. If the option "Apply changes to all selected workers" is checked the client is modified in all the currently selected workers.

*** Renew key dialog ***

Generates new keys for all the listed workers. For this to work all workers should have the same password. Key algorithm, Key specification and New key alias must be specified if it is not taken from the worker's configuration.

*** Test key dialog ***

Test keys for all the listed workers. It is optional to either test the current key or the next key (if any) or all the keys in the keystore. For this to work all workers should have the same password. The results shows for each key the key alias, SUCCESS and the public key hash if the test signing succeded.

*** Generate CSR dialog ***

Generates certificate signing requests (CSR:s) in PKCS#10 format for all listed signers and either for the current key (Default key) or the next key. Signature algorithm, subject distingueshed name (DN) and Filename must be specified if not already taken from the worker's configuration. The format of the request could either be a Standard CSR file or a CSR wrapped in PKCS#7/CMS signed object created by a RequestSigner. The with the last option is that at the CA the signature of the request can be verified.

*** Install certificates ***

Installs signer certificate and certificate chains for the listed workers and if next key is choosen that key becomes the new default key.

Signer certificate: Browse for the signer certificate file in PEM format.

Certificate chain: Browse for the signer certificate chain file in PEM format. The signer certificate is added to the chain if it is not already included so normally this could just be the CA certificate.

*** Renew signer dialog ***

Requests a Renewal worker to renew all the choosen and selected workers. The Renewal worker will generate a new key if there isn't already a next key available and then contact EJBCA using its web service interface to request a new certificate. After recieving the new certificate it is installed and the next key becomes the current default key. Notice how the "Not valid after" date and possibly also the Signings column changes and the Renewal checkbox gets unchecked after a successfull renewal.

*** Global configuration dialog ***

Lists all the global configuration properties and gives the ability to add, remove or edit properties.

*** Administrators dialog ***

Lists all the authorized WS administrators and gives the ability to add, remove or edit authorized administrators.

*** Configuring using a module ***

To configure the worker using a module the cluster class loader must be activated (see Changing the default configuration of the Cluster Class Loader) and the code for the plugin available as .MAR-file. To setup a worker using a module archive issue the following command:

bin/signserver.sh module add dist-server/MODULE.MAR ENVIRONMENT
                        

Replace "MODULE.MAR" with the name of the module file and "ENVIRONMENT" with the name of the built-in configuration to load. For example to load the TSA module using the demo configuration issue the following command:

bin/signserver.sh module add dist-server/tsa.mar demo
                        

Notice the created workerId and use it when applying the configuration using the reload command:

bin/signserver.sh reload WORKER-ID
                        

*** Configuring using a built-in plugin ***

Configuring using a build-in plugin only works if you have set the option includemodulesinbuild=true in signserver_build.properties.

A worker is configured by setting properties for it. Specifically if the plugin is built-in it is specified by setting the property CLASSPATH to the fully qualified name of the class implementing the plugin.

The properties can be set manually using the setproperty command or by loading them all at once from a configuration file using the setproperties command. Sample configuration files are available in SIGNSERVER_HOME/sample-configs.

To setup a PDFSigner using the quick start configuration file issue the following command:

bin/signserver.sh setproperties sample-configs/qs_pdfsigner_configuration.properties
                        

Notice the created workerId and use it when applying the configuration using the reload command:

bin/signserver.sh reload WORKER-ID
                        

*** Remove Workers ***

You can list which workers you have with the command:

bin/signserver.sh getstatus brief all                    
                    

If will display for example:

===========================================
Executing Command on host : localhost
===========================================


Current version of server is : SignServer 3.2-svn


Status of Signer with Id 1 is :
  SignToken Status : Offline
  Signings: 0
                    

You can remove the worker with Id 1 with the command:

bin/signserver.sh removeworker 1
bin/signserver.sh reload all                    
                    

*** Remove modules ***

If you have made changes to the module, and you are using the cluser classloader (i.e. not built in modules) you have to remove the module before deploying a new one.

bin/signserver.sh modules list

===========================================
  Executing Command on host : localhost
===========================================


Using cluster class loader.

Listing all available modules :
  Module : MRTDSODSIGNER, version 3200
    Parts : 
      server

bin/signserver.sh module remove MRTDSODSIGNER 3200

===========================================
  Executing Command on host : localhost
===========================================


Using cluster class loader.

  Removing module MRTDSODSIGNER version 3200 ...
  Removal of module successful.
                    

*** Add updated modules ***

After rebuilding the modules you can add updated modules.

bin/signserver.sh module add dist-server/pdfsigner.mar soft					
bin/signserver.sh reload all
bin/signserver.sh getstatus complete all
					

*** Signing and validating an XML document ***

try {
    ISigningAndValidation signserver = new SigningAndValidationWS("localhost", 8080);

    // Document to sign
    byte[] unsigned = "<document><name>Some content</name></document>".getBytes();
    byte[] signed;

    // Signing
    GenericSignResponse signResp = signserver.sign("DemoXMLSigner", unsigned);
    signed = signResp.getProcessedData();
    System.out.println("Signed: " + new String(signed));

    // Validating
    GenericValidationResponse validateResp = signserver.validate("DemoXMLValidator", signed);
    System.out.println("Valid: " + validateResp.isValid());

    if(validateResp.getSignerCertificate() != null) {
        if(validateResp.getSignerCertificate() instanceof X509Certificate) {
            X509Certificate signerCert = (X509Certificate) validateResp.getSignerCertificate();
            System.out.println("Signed by: " + signerCert.getSubjectDN().getName());
        }
    }
} catch (Exception ex) {
    ex.printStackTrace();
}                                   

*** MRTD Signing ***

try {
    ISigningAndValidation signserver = new SigningAndValidationWS("localhost", 8080);

    // Bytes to sign
    ArrayList<byte[]> bytesToSign = new ArrayList<byte[]>();
    bytesToSign.add("Sample data 1".getBytes());
    bytesToSign.add("Sample data 2".getBytes());

    // Signing
    MRTDSignResponse signResp = (MRTDSignResponse) signserver.process("MRTDSigner", new MRTDSignRequest(1234, bytesToSign), new RequestContext());

    System.out.println("Certificate: " + signResp.getSignerCertificate());

    if(signResp.getProcessedData() instanceof Collection) {
        Collection<byte[]> signed = (Collection) signResp.getProcessedData();
        for(byte[] data : signed) {
            System.out.println("Signed: " + new String(Base64.encode(data)));
        }
    }
} catch (Exception ex) {
    ex.printStackTrace();
}                               

*** Samples ***

• HTTP GET:
  http://localhost:8080/signserver/process?workerName=DemoXMLSigner&data=%3Croot%3Ehej2%3C/root%3E
  http://localhost:8080/signserver/process?workerName=DemoXMLSigner&encoding=base64&data=PGhlajI%2Bb2s8L2hlajI%2BCg%3D%3D
  
  
• HTTP POST with multipart/form-data or x-www-form-urlencoded:
  For example see /signserver/demo/xmlsign.jsp (multipart/form-data) and /signserver/demo/genericsign.jsp (x-www-form-urlencoded).
  
  
• HTTP POST with other content-type:
  See the TimeStampClient.
  
  

*** Samples ***

• See /signserver/demo/mrtdsodsign.jsp.
  
  

*** No authentication ***

AUTHTYPE = NOAUTH

Sets the server to not require any authentication.

*** Client certificate authentication ***

AUTHTYPE = CLIENTCERT

(default) requires a certificate of all the clients. The certificates must be in the application server's truststore. Authorized clients is configured manually using the CLI interface.

*** Username/password-based authentication ***

AUTHTYPE = org.signserver.server.UsernamePasswordAuthorizer

USER.[NAME] = [PASSWORD]
USER.[NAME] = [HASHED_PASSWORD]:[HASH_ALGORITHM]
USER.[NAME] = [HASHED_PASSWORD]:[HASH_ALGORITHM]:[SALT]

This authorizer requires a valid username and password. User accounts are configured by setting properties of the form shown above, where [NAME] is the username and [PASSWORD] is the clear-text password. In the second form [HASHED_PASSWORD] should be replaced with the output of the digest algorithm specified in [HASH_ALGORITHM]. The third form uses a hash value that is appended to the password before hashing it.

If a valid username and password is not supplied the worker throws an AuthorizationRequiredException which in case of the HTTP interfaces causes a HTTP Basic Authentication (RFC 2617).

*** Username-based authentication ***

AUTHTYPE = org.signserver.server.UsernameAuthorizer

Form 1: ACCEPT_ALL_USERNAMES = false (default) and usernames are specified:
ACCEPT_ALL_USERNAMES = false
ACCEPT_USERNAMES = user1;user2;user3

Form 2, ACCEPT_ALL_USERNAMES = true and no usernames are specified:
ACCEPT_ALL_USERNAMES = true

An Authorizer that can be used for instance if SignServer sits behind an Apache front-end which uses HTTP basic authentication. With this Authorizer the username is logged but the password is not checked as it is assumed to be checked by the front-end.

The Authorizer can be configured to either accept all usernames or only accept those usernames listed in one of its properties.

*** Remote address authentication ***

AUTHTYPE = org.signserver.server.RemoteAddressAuthorizer

ALLOW_FROM = Comma separated list of IP addresses to allow requests from. By default all other addresses are denied access.

If a worker is invoked directly using an EJB call and no REMOTE_IP is specified in the RequestContext the IP-address is set to the String "null". In that case, to allow requests using EJB calls, null can be added to the list of allowed addresses.

Note: When adding "null" to ALLOW_FROM not only locally running clients like the ClientCLI and AdminGUI is allowed access but also from workers that invoke the other worker directly using an EJB call. This is for instance the case for the XMLValidator which delegates the validation of the certificate to a CertValidator. If the CertValidator had a RemoteAddressAuthorizer allowing access from "null" then the XMLValidator would be able to use it. To restrict users from using the CertValidator (indirectly through the XMLValidator) an Autorizer could be configured for the XMLValidator.

*** Custom ***

This authorization functionality doesn't work for all use cases. Then it's possible to create a customized authorizer and specify it's class path as value in the AUTHTYPE property. The Processable will then automatically instantiate and use it. How to develop such a plug-in is explained in the developers section.

*** Overview ***

The time stamp server generates time stamp tokens and have the support for the following options:

• Set of accepted policies
• Set of accepted algorithms
• Set of accepted extensions
• Accuracy microseconds
• Accuracy milliseconds
• Accuracy seconds
• Included certificate chain (currently doesn't include CRLs)
• Ordering
• TSA name

The time stamp signer currently don't support:

• CRL inclusion
• Signed attributes
• Unsigned attributes

Timestamps requests are served through a http service at the URL:

'http://<host name>/signserver/process?workerId=<worker Id>'
                        

If no 'worker Id' parameter is specified then will the id of 1 be used as default.

The time-stamp signer requires a time-stamp certificate with the extended key usage 'time-stamp' only. The extended key usage extension must be critical.

*** Available Properties ***

The following properties can be configured with the signer:

TIMESOURCE = property containing the fully qualified name of the class implementing the ITimeSource that should be used (OPTIONAL). Below are the built-in TimeSourceS available:

org.signserver.server.LocalComputerTimeSource

This is the default TimeSource and uses the time from the local computer and always returns the time.

org.signserver.server.StatusReadingLocalComputerTimeSource

This TimeSource returns the time from the local computer but only if the status property INSYNC is returned as true from the Status Repository.

ACCEPTEDALGORITHMS = A ';' separated string containing accepted algorithms, can be null if it shouldn't be used. (OPTIONAL, Strongly recommended) Supported Algorithms are: GOST3411, MD5, SHA1, SHA224, SHA256, SHA384, SHA512, RIPEMD128, RIPEMD160, RIPEMD256

ACCEPTEDPOLICIES = A ';' separated string containing accepted policies, can be null if it shouldn't be used. (OPTIONAL, Recommended)

ACCEPTEDEXTENSIONS = A ';' separated string containing accepted extensions, can be null if it shouldn't be used. (OPTIONAL)

DEFAULTTSAPOLICYOID = The default policy ID of the time stamp authority (REQUIRED, if no policy OID is specified in the request then will this value be used.)

ACCURACYMICROS = Accuracy in micro seconds, Only decimal number format, only one of the accuracy properties should be set (OPTIONAL)

ACCURACYMILLIS = Accuracy in milliseconds, Only decimal number format, only one of the accuracy properties should be set (OPTIONAL)

ACCURACYSECONDS = Accuracy in seconds. Only decimal number format, only one of the accuracy properties should be set (OPTIONAL)

ORDERING = The ordering (OPTIONAL), default false. Only false is supported.

TSA = General name of the Time Stamp Authority. (OPTIONAL)

 'bin/signserver.sh module add dist-server/mrtdsigner.mar'
                    

*** Overview ***

The MRTD Signer performs a RSA signing operation on incoming data. The data should already be padded. This signer i used to sign 'Machine Readable Travel Documents' i.e. electronic passports.

*** Available Properties ***

No configuration properties exists.

*** Overview ***

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". It 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 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:

REASON	The reason included in the PDF signature and displayed by the PDF reader. Default: "Signed by SignServer".
LOCATION	The location included in the PDF signature and displayed by the PDF reader. Default: "SignServer".
ADD_VISIBLE_SIGNATURE	Setting that control whether signature to be added should be visible or invisible. Possible values: True or False. Default: "False"
VISIBLE_SIGNATURE_PAGE	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 specified page number exceeds page count of the document ,signature is drawn on last page. If page_number specified is not numeric (or negative number) the signature will be drawn on first page Default: "First".
VISIBLE_SIGNATURE_RECTANGLE	Specifies the rectangle signature is going to be drawn in. This property is ignored if ADD_VISIBLE_SIGNATURE is set to False. Format is : (llx,lly,urx,ury). Here : 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".
VISIBLE_SIGNATURE_CUSTOM_IMAGE_BASE64 & VISIBLE_SIGNATURE_CUSTOM_IMAGE_PATH	If we want the visible signature to contain custom image, specify image as base64 encoded byte array. Alternatively custom image can be specified by giving a path to image on file system. Note: if specifying a path to an image "\" should be escaped (thus C:\photo.jpg => "C:\\photo.jpg") Note: if specifying image as base64 encoded byte array "=" should be escaped (this "BBCXMI==" => "BBCXMI\=\=") If both of these properties are set then VISIBLE_SIGNATURE_CUSTOM_IMAGE_BASE64 will take priority. If we do not want this feature then do not set these properties. Default: not set (no custom image). These properties are ignored if ADD_VISIBLE_SIGNATURE is set to False. NOTE: in clustered environment it is more manageable and advised to specify image as base64 string, since image data will be stored in central database. Otherwise each node should contain copy of the image, and each image managed separately (ex: on image updates, or insertion of new image for different worker)
VISIBLE_SIGNATURE_CUSTOM_IMAGE_SCALE_TO_RECTANGLE	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 image might look different that 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 llx and lly coordinates specified by VISIBLE_SIGNATURE_RECTANGLE property will be used for drawing 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_LEVEL	Set 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. Default: "NOT_CERTIFIED".
TSA_URL	If we want to timestamp document signature, specify timestamp authority URL. If we do not want to timestamp document signature, do not set property. Note: if path contains characters "\" or "=" , these characters should be escaped (thus "\" = "\\", "=" =>"\=") 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".
EMBED_OCSP_RESPONSE	If we want to embed the OCSP response for the signer certificate inside the signature package set to True, otherwise set to False. Note: issuer certificate (of signing certificate) should be in certificate chain. 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_BASE	The 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} ${WORKERNAME} ${REMOTEIP} ${REQUESTID} ${TRANSACTIONID} ${USERNAME} Default: "${DATE:yyyy/MM/dd}".
ARCHIVETODISK_FILENAME_PATTERN	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 http://pdfsig-collision.florz.de/.
REJECT_PERMISSIONS	Reject signing of the document if any of the permissions in the comma separated list would be in the document. Available permissions: ALLOW_PRINTING ALLOW_MODIFY_CONTENTS ALLOW_COPY ALLOW_MODIFY_ANNOTATIONS ALLOW_FILL_IN ALLOW_SCREENREADERS ALLOW_ASSEMBLY ALLOW_DEGRADED_PRINTING 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. This property can not be specified if REMOVE_PERMISSIONS is used. Notice 1: 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 even though specified by this property to be allowed might not be allowed when opening the final document (i.e. if that would invalidate the signature and/or certification). Notice 2: 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. Notice: 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 also Notice 1 and Notice 2 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)

*** Overview ***

ODF Signer, which stands for Open Document Format Signer is a plug-in to SignServer that applies server side signature to documents in ODF format. It has been tested with OpenOffice.org 3.1.

ODF Signer supports only "invisible" signatures, that is unlike PDF signer there's no pictorial representation of the digital signature. When you open signed document in OpenOffice.org you can verify signature using toolbars, or the notifier in status bar (red mark), which notifies user that the document is digitally signed.

*** Available Properties ***

Other than standard worker properties, ODF Signer does not have any other custom ODF signer specific properties.

*** Overview ***

The XML Signer creates enveloped XML signatures using XMLDSig.

The signed XML document can be validated using the XML Validator.

*** Available Properties ***

This signer has no extra properties above the standard worker properties.

*** Overview ***

OOXML Signer, which stands for Office Open XML Signer is a plug-in to SignServer that applies server side signature to documents in OOXML format. It has been tested with MS Office 2007.

Currently OOXML Signer supports only "invisible" signatures , that is unlike PDF signer there's no pictorial representation of the digital signature. When you open signed document in MS Office you can verify signature using toolbars, or the notifier in status bar (red mark), which notifies user that the document is digitally signed.

*** Available Properties ***

Other than standard worker properties, OOXML Signer does not have any other custom OOXML signer specific properties.

NOTE : In later versions of OOXML Signer it is planned to add support for visible signatures and custom signature image.

*** Overview ***

The CMS signer can sign arbitrary data and produces a CMS (RFC 3852) SignedData structure in binary format.

Currently the signed content is always embedded as well as the signer certificate.

*** Overview ***

The XML validator validates the signature of XML documents. The certificate is checked by the configured certificate validation service.

*** Available Properties ***

VALIDATIONSERVICEWORKER = Name or id of validation service worker for handling certificate validation

RETURNDOCUMENT = True if the response should contain the validated document

STRIPSIGNATURE = True if the signature should be removed from the document if it is returned

*** Overview ***

Dispatches the request to the first of the configured workers that has an active cryptotoken. This dispatcher can be useful if you want to have one worker to call that forwards the request to any of the configured workers that has a valid certificate etc.

*** Available Properties ***

WORKERS = Comma separated list of workerNameS to try to forward requests to.

*** Overview ***

The default validation service have a set of Validators. A validator is responsible to checking the validity against one or more issuers using for example CRL check or OCSP/XKMS lookup or just by checking some database. Currently there are no ready to use validators, these remain to be developed in future versions of the SignServer.

The Default Validation Service supports validations to be cached for some or all issuers for a specified amount of time.

If not configured otherwise will the validation service use the DefaultX509CertTypeChecker that determines the certificate type from the key usage in the certificate. Key Encipherment and Digital Signature indicates a IDENTIFICATION type and Non-reputation indicates ELECTRONIC SIGNATURE.

There exists a validation specific WebService that can be used for platform independent client calls. The WebService must be enabled during the build and isn't by default. The WebService WSDL file is located at the URL http://<hostname>:8080/signserver/validationws/validationws?wsdl and it contains two calls one is 'isValid' that performs the validation check and the other is a getStatus call that checks the health of the node and its underlying systems. The last calls can be used by clients for monitoring or implementing redundancy.

Important, Due to class path conflict in JBoss 4.2.x own JBoss WebService stack and the JAX-WS stack used by the SignServer must the JBoss WebService stack be removed before the WebService is used. This is done by going to JBOSS_HOME/server/default/deploy and remove the directory jbossws.sar.

*** Available Properties ***

The following properties can be configured with the default validation service:

The validation service have three types of properties, general properties (that applies for the service and all configured validators), validator properties (that only applies for a specific validator) and issuer properties (that only applies for an issuer configured in a specific validator).

General Properties:

CACHEDISSUERS = A ';' separated list of issuer names (usually issuer DNs) (Optional, no validation is cached if unset.)

CERTTYPECHECKER = Certificate type checker that should be used to determine the type of certificate (Optional, default is org.signserver.validationservice.server.DefaultX509CertTypeChecker)

TIMEINCACHE = Time in seconds a certificates validation should be cached (Optional, default is 10 seconds)

Validator properties:
Validator properties is specified with the prefix of 'validator<validatorId>.' or 'val<validatorId>.' were validator Id should be an integer between 1 and 255. For instance, to specify the type of a validator with an id of 1 then specify 'val1.classpath=some.classpath.SomeClass'. This validator will be initialized with all its validator specific properties (with 'val<id>.' prefix removed) as well as the general ones.

CLASSPATH = Class path to the validator that should be used. (Required for each configured validator)

Issuer properties: Issuer properties are specified as 'val<val id>.issuer<issuer id>.<property>' were issuer id is a positive integer between 1 and 255. All generic and validator specific properties (with the given validator id) will also be propagated to the specific issuer configuration.

CERTCHAIN = The certificate path of the CA certificates used to verify the certificate. Should be a appended BASE64 string. (Required for each configured issuer).

Here is an example configuration of a validation service to clarify things even further

# Set up the worker -> validation service wrapper
GLOB.WORKER1.CLASSPATH= org.signserver.validationservice .server.ValidationServiceWorker
#Uncomment and set class path to custom validation service, othervise is default #used.
#WORKER1.TYPE=

# Name of Service (Optional)
WORKER1.NAME=ValidationService1

# Define TestCA2 and TestCA3 as a cached for 15 seconds, TestCA1 is Not cached.
WORKER1.CACHEDISSUERS=CN=TestCA2;CN=TestCA3
WORKER1.TIMEINCACHE=15

# Define a validator in charge of issuer TestCA1 and TestCA2
WORKER1.VAL1.CLASSPATH=<Class path to some validator>
WORKER1.VAL1.ISSUER1.CERTCHAIN=EFWAASDFADFASDFKASDKFW1231.....
WORKER1.VAL1.ISSUER2.CERTCHAIN=EFWAASDFADFASDFKASDKFW1231.....

# Define a validator in charge of issuer TestCA3
WORKER1.VAL2.CLASSPATH=<Class path to some validator>
WORKER1.VAL2.ISSUER1.CERTCHAIN=EFWAASDFADFASDFKASDKFW1231.....
                        

*** Overview ***

The group key service framework is used to manage and distribute group keys to clients in an organisation. The keys can be generated on demand or pre-generated at times when the system is not utilized a lot. The group keys can be both symmetric and asymmetric but one service can only distribute one type of key. If several kinds of keys are required should multiple services be set up within the same server.

The group keys are stored encrypted in database. The encryption key can be configured to be switched automatically after a defined number of encryptions to avoid overexposure of the cryptographic data. It is also possible to switch the encryption key manually.

The Framework requires an ExtendedCryptoToken, the difference are that the extended token have additional support for key export and symmetric key operations.

The Group Key Service have CLI commands for administration of the service such as pre-generate keys, manual switch of encryption key and removal of group keys.

The communication to the group key service is mainly done through the main Web Service interface. But other ways of communicating with the server might come in the future.

Authorization to group keys is very important and therefore should a special plug-in be developed that looks up which clients that should have access to a specific group key which fit into the organisation needs. See the authorization chapter of how to develop a customized authorization plug-in.

The basic configuration of a group key service is very similar to that of a validation service. Two entries is required in the global configuration. The first is the class path for the Worker to GroupKeyService wrapper, then a class path reference to the extended crypto token used with the service. If not the default group key service should be used it is possible to define a custom one by specifying its class path in the TYPE worker property.

*** Available Properties ***

USEPREGENERATION = Setting defining of keys should be pre-generated or generated on the fly when needed. If the pool of pre-generated keys gets empty will new keys always be generated automatically. (Optional, default is true)

ENCKEYALG = Encryption algorithm used to encrypt the group keys stored in database. (Optional, default is "AES")

ENCKEYSPEC = Specification of the encryption key. (Optional, default is "256")

GROUPKEYALG = Defines the type of group keys that this service should generate (Optional, default is "AES")

GROUPKEYSPEC = Specification of the generated group keys. (Optional, default is "256")

KEYSWITCHTHRESHOLD = Setting defining the number of group keys that should be encrypted by the same encryption key before it's switched. (Optional, default is 100000)

*** Overview ***

The RenewalWorker can be used to generate new keys and then contact EJBCA using web services to get a new certificate. The worker accepts GenericPropertiesRequestS and returns GenericPropertiesResponseS.

*** Worker Properties ***

EJBCAWSURL = URL to the EJBCA. Example: https://ca-server:8443/ejbca

TRUSTSTOREPATH = Path to the keystore containing the CA's SSL server certificate as a trusted entry.

TRUSTSTORETYPE = Type of keystore. JKS is supported.

TRUSTSTOREPASSWORD = Password protecting the truststore keystore.

*** Properties of renewee ***

KEYALG = Algorithm for the key generation. Examples: RSA, DSA or ECDSA

KEYSPEC = Key length (for RSA or DSA) or curve name (for ECDSA). Examples: 2048, 4096, secp256r1

EXPLICITECC = True if explicit domain parameters should be used instead of NamedCurves. Default: false

DEFAULTKEY = Key alias for the current key.

NEXTCERTSIGNKEY = Key alias for the next key.

*** Request Properties ***

WORKER = Name of the worker that should be renewed.

FORDEFAULTKEY = If the current key should be used instead of the next key or a new key. (Optional, default: false)

*** Response Properties ***

RESULT = "OK" if the renewal succeded otherwise "FAILURE".

MESSAGE = Error message if any.

*** Renewal modes ***

Renewee		Request	Result
DEFAULTKEY	NEXTCERTSIGNKEY	FORDEFAULTKEY	DEFAULTKEY	NEXTCERTSIGNKEY
-	-	-	New key and alias	Removed
present	-	-	New key and alias	Removed
-	present	-	Alias from nextcertsignkey	Removed
present	present	-	Alias from nextcertsignkey	Removed
present	-	TRUE	Same alias	Same alias
present	present	TRUE	Same alias	Same alias

*** Overview ***

A CryptoToken using a PKCS#12 (.p12/.pfx) key-store in the local file-system.

In a clustered environment the key store must placed at the same location at all nodes.

The P12CryptoToken, doesn't support the destroyKey() method

*** SIGNERTOKEN.CLASSPATH ***

The fully qualified class name is: org.signserver.server.cryptotokens.JKSCryptoToken

*** Available Properties ***

KEYSTOREPATH: The full path to the key-store file to load. (required)

KEYSTOREPASSWORD: The password that locks the key-store. Used for automatic activation.

DEFAULTKEY: The key to use. If not specified the first found key is used. (optional)

*** Overview ***

A CryptoToken using a Java Key Store (.jks) in the file-system.

In a clustered environment must the key store be at the same location at all nodes.

The JKSCryptoToken, doesn't support the destroyKey() method

*** SIGNERTOKEN.CLASSPATH ***

The fully qualified class name is: org.signserver.server.cryptotokens.P12CryptoToken

*** Available Properties ***

KEYSTOREPATH: The full path to the key-store to load. (required)

KEYSTOREPASSWORD: The password that locks the key-store. Used for automatic activation.

DEFAULTKEY: The key to use. If not specified the first found key is used. (optional)

NEXTCERTSIGNKEY: The next key to use. See PKCS11CryptoToken. (optional)

*** Overview ***

Using PrimeCardHSM it's possible to use a SmartCard to generate 2048-bit RSA signatures. The SmartCard can perform about one signature a second. PrimeCardHSM is proprietary software by PrimeKey Solutions AB.

PrimeCardHSM requires PCSCD software and SmartCard drivers. See separate documentation about installing PrimeCardHSM.

The PrimeCardHSMCryptoToken, doesn't support the destroyKey() method.

*** SIGNERTOKEN.CLASSPATH ***

The fully qualified class name is: org.signserver.server.cryptotokens.PrimeCardHSMCryptoToken

*** Available Properties ***

DEFAULTKEY = Hash value of the signing key on the card. See PrimeCardHSM documentation for more information.(Required)

NEXTCERTSIGNKEY: The next key to use. See PKCS11CryptoToken. (optional)

AUTHCODE = Authentication code for automatic activation (Optional).

*** Overview ***

Using PKCS11 it's possible to use a HSM that has a PKCS11 module, such as Utimaco, nCipher, SafeNet or AEP KeyPer. SignServer uses the same underlying implementation of PKCS11 crypto tokens as EJBCA. To find out more about supported devices and get information how to configure them you can visit the HSM documentation at EJBCA.org. The only thing that differs are the token labels strings, which you should use from below for SignServer. A very useful tool from EJBCA is the ClientToolBox. If you can generate anbd test PKCS11 keys using the clientToolBox, you can use them with SignServer.

*** SIGNERTOKEN.CLASSPATH ***

The fully qualified class name is: org.signserver.server.cryptotokens.PKCS11CryptoToken

*** Available Properties ***

DEFAULTKEY = The key alias. (Required)

NEXTCERTSIGNKEY = The next key to use. This property can be used to hold the name of the next key to use. Certificate signing requests (CSR) can be made for this key can while to the current key (DEFAULTKEY) is still in production. After uploading the new certificate the value of NEXTCERTSIGNKEY can be moved to DEFAULTKEY. (optional)

PIN = Authentication code for activation. (Required)

SHAREDLIBRARY = Full path to the library containing the PKCS11 interface. (Required)

SLOT or SLOTLISTINDEX = Slot number or the index of the slot to use. (Required and only one of them can be used.)

ATTRIBUTESFILE = Path to file with PKCS#11 attributes used for key generation.

Sample p11attributes.cfg working with SafeNet Luna:

attributes(generate,*,*) = {
  CKA_TOKEN = true
}
attributes(generate,CKO_PUBLIC_KEY,*) = {
  CKA_ENCRYPT = true
  CKA_VERIFY = true
  CKA_WRAP = true
}
attributes(generate, CKO_PRIVATE_KEY,*) = {
  CKA_EXTRACTABLE = false
  CKA_DECRYPT = true
  CKA_SIGN = true
  CKA_UNWRAP = true
}
                        

*** Example usage ***

Edit qs_pdfsigner_configuration.properties and choose the sign token setting for the PKCS11 sign token. Run the following command to set up a PDF signer using the PKCS11 properties configured: bin/signserver.sh setproperties qs_pdfsigner_configuration.properties

Generate a keypair for the signer: bin/signserver.sh generatekey 8 -alias defaultKey -keyalg RSA -keyspec 2048

Test the keypair: bin/signserver.sh testkey 8

You also need a certificate for the signer. Generate a certificate request with the command: bin/signserver.sh generatecertreq 8 "CN=PKCS11 Signer token" SHA1WithRSA /tmp/certreq.pem

Add a user in EJBCA with a certificate profile suitable for signing, and enrol for a "Server Certificate" using the public web pages.

Create the certificate chain file with the command: cat /tmp/cert.pem /tmp/AdminCA1.pem > /tmp/certchain.pem

The signer certificate must be first, and the root CA certificate last.

Upload the signing certificate chain to the signer using the command: bin/signserver.sh uploadsignercertificatechain 8 GLOB /tmp/certchain.pem

After the certificate chain has been uploaded to the server, the configuration must be reloaded and the server must be restarted. It is not sufficient to only reload the configuration.

*** Overview ***

The SoftCryptoToken is a simple token managing it's own soft keys instead of using a PKCS12 file. It can be used for test and demonstration purposes. The keys are stored in the worker's properties and is generated when genCertificateRequest is called. One key is used for all purposes and a new key is generated for every certificate request.

The method destroyKey is not supported.

There is also a tool available for constructing the properties from a PKCS12 file in CryptoTokenUtils.java. To run the tool outside the IDE first build SignServer by running "ant". After that the tool can be executed with something similar to:

java -cp dist-server/signserver-ejb.jar:lib/1.6/bcprov-jdk.jar:dist-server/lib/SignServer-Common.jar:lib/ejbca-util.jar org.signserver.server.cryptotokens.CryptoTokenUtils createsoft src/test/dss10/dss10_signer1.p12 "signer 1" foo123
                        

*** SIGNERTOKEN.CLASSPATH ***

The fully qualified class name is: org.signserver.server.cryptotokens.SoftCryptoToken

*** Available Properties ***

KEYDATA = The serialized KeyPair generated by genCertificateRequest, usually is this setting configured by the SoftCryptoToken itself.

KEYALG = The algorithm used when generating new keys. (Optional, default is "RSA")

KEYSPEC = The key specification used when generating new keys. (Optional, default is "2048")

*** Example usage ***

First change the global property of WORKER<ID>.CRYPTOTOKEN.CLASSPATH of the worker you want to use the SoftCryptoToken with. After reload will an empty and inactive SoftCryptoToken be created.

Then generate a certificate request with the command, in this step will new keys be generated

bin/signserver.sh generatecertreq <id> "CN=Soft Signer token" SHA1WithRSA /tmp/certreq.pem
                        

Then upload the signing certificate to the worker using the command:

bin/signserver.sh uploadsignercertificatechain <id> GLOB /tmp/cert.pem
                        

After the certificate chain has been uploaded to the server, the configuration must be reloaded and the SoftCryptoToken will be active and ready to use.

*** The ISigner Interface ***

A Signer is a component used to perform some form of cryptographic processing of requested data and to create a custom signer class it should implement the org.signserver.server.signers.ISigner interface. There exists a BaseSigner that can be inherited taking care of some of the functionality. If the BaseSigner is inherited the only method that needs to be implemented is 'processData() '.

There exists a DummySigner implementation that is used for demonstration purposes.

*** The ITimedService Interface ***

There are two kinds of timed services, singleton or non-singleton. A singleton service is only run at one of the nodes at the time while non-singleton services are run at all nodes simultaneously. If a singleton service fails to run on one of the nodes will one of the other nodes take over the service automatically.

If a service should be singleton or not is determined by a standard property SINGLETON defined in the ServiceConfig class.

Other basic properties used to configure all services are: ACTIVE when set to "TRUE" means that the service is active and should be run. INTERVAL defining the interval in seconds of how often the service should be run. INTERVALMS defining the interval in milliseconds of how often the service should be run. CRON used instead of INTERVAL or INTERVALMS to specify on a calendar basis.

To create a custom timed service class it should implement the org.signserver.server.timedservices.ITimedService interface. There exists a BaseTimedService that can be inherited taking care of most of the basic functionality. If the BaseTimedService is inherited the the only method that needs to be implemented is the 'work()' method.

The work method that needs to be implemented is described here:

/**
 * Method that should do the actual work and should
 * be implemented by all services. The method is run
 * at a periodical interval defined in getNextInterval.
 *
 * @throws ServiceExecutionFailedException if execution of a service failed
 */
public void work() throws ServiceExecutionFailedException;
                        

There exists a DummyTimedService implementation that is used for demonstration purposes.

*** IValidationService Interface ***

Just as the other worker plug-ins have the validator service a base class taking care of most of the common methods and the only method that needs to be implemented is the 'validate' method below. But for most applications should the DefaultValidationService work. What is probably more interesting is to develop a custom IValidator used to integrate the default validation service against different certificate status repositories. See section called 'Other Customizations' for details of how to implement a Validator.

/**
 * Method used to check the validation of a certificate
 *
 * @param validationRequest
 * @return a ValidateResponse
 * @throws IllegalRequestException if data in the request didn't conform with the specification.
 * @throws CryptoTokenOfflineException if the crypto token isn't online.
 * @throws SignServerException for general failure exception during validation
 * @see org.signserver.validationservice.common.ValidateRequest
 * @see org.signserver.validationservice.common.ValidateResponse
 */
ValidateResponse validate(ValidateRequest validationRequest) throws IllegalRequestException, CryptoTokenOfflineException, SignServerException;
                        

*** IGroupKeyService Interface ***

To customize a group key service is slightly more work. Then need five methods be implemented: 'fetchGroupKey', 'pregenerateGroupKeys', 'swithEncryptionKey', 'removeGroupKeys' and 'getStatus'. The default implementation stores the group keys in database with a reference to the encryption key used, the encryption key is stored in the extended key store. See the JavaDoc and the code for the default group key service for more details of implementing a customized one.

/**
 * Main method of a Group Key Service responsible for fetching keys from
 * the database.
 *
 * @param fetchKeyRequest
 * @return a FetchKeyReponse
 * @throws IllegalRequestException if data in the request didn't conform with the specification.
 * @throws CryptoTokenOfflineException if the crypto token isn't online.
 * @throws SignServerException for general failure exception during key generation.
 * @see org.signserver.groupkeyservice.common.FetchKeyRequest
 * @see org.signserver.groupkeyservice.common.FetchKeyResponse
 */
FetchKeyResponse fetchGroupKey(FetchKeyRequest fetchKeyRequest) throws IllegalRequestException, CryptoTokenOfflineException, SignServerException;

/**
 * Method that instructs the group key service to pregenerate keys.
 * This method is called at periods when the server is having
 * a low load. This option is optional to implement, if the
 * service doesn't support this method it should return null.
 *
 *
 * @param pregenerateKeysRequest request data
 * @return a response containing number of keys generated, etc
 * @throws IllegalRequestException if requests contain unsupported data.
 * @throws CryptoTokenOfflineException if the crypto token isn't online.
 * @throws SignServerException for general failure exception during key generation.
 * @see org.signserver.groupkeyservice.common.PregenerateKeysRequest
 * @see org.signserver.groupkeyservice.common.PregenerateKeysResponse
 */
PregenerateKeysResponse pregenerateGroupKeys(PregenerateKeysRequest pregenerateKeysRequest) throws IllegalRequestException, CryptoTokenOfflineException, SignServerException;


/**
 * Method instructing the key service to switch the encryption key for
 * storing the group keys in the database. This to ensure that one encryption
 * key isn't exposed through to much data.
 *
 * This method is optional for the implementing service to implement, if
 * it's not implemented it should return null.
 *
 * @param switchEncKeyRequest request data.
 * @return a response containing the result of the operation such as new key index.
 * @throws IllegalRequestException if requests contain unsupported data.
 * @throws CryptoTokenOfflineException if the crypto token isn't online.
 * @throws SignServerException  for general failure exception during key generation.
 * @see org.signserver.groupkeyservice.common.SwitchEncKeyRequest
 * @see org.signserver.groupkeyservice.common.SwitchEncKeyResponse
 */
SwitchEncKeyResponse switchEncryptionKey(SwitchEncKeyRequest switchEncKeyRequest) throws IllegalRequestException, CryptoTokenOfflineException, SignServerException;

/**
 * Method instructing the key service to remove old group keys not used anymore
 * it up to the caller to check that the implementing service supports the type
 * of IRemoveGroupKeyRequest used. The request should contain data specifying which
 * keys that should be removed.
 *
 * This method is optional for the implementing service to implement, if
 * it's not implemented it should return null.
 *
 * @param removeGroupKeyRequests request data.
 * @return a response containing the result of the operation such as number of keys actually removed.
 * @throws IllegalRequestException if requests contain unsupported data.
 * @throws CryptoTokenOfflineException if the crypto token isn't online.
 * @throws SignServerException  for general failure exception during key generation.
 * @see org.signserver.groupkeyservice.common.RemoveGroupKeyResponse
 * @see org.signserver.groupkeyservice.common.IRemoveGroupKeyRequest
 */
RemoveGroupKeyResponse removeGroupKeys(IRemoveGroupKeyRequest removeGroupKeyRequests) throws IllegalRequestException, CryptoTokenOfflineException, SignServerException;


/**
 * Should return the actual status of the worker, status could be if
 * the signer is activated or not, or equivalent for a service.
 * @return a WorkerStatus object.
 */
public WorkerStatus getStatus();
                        

*** The ICryptoToken Interface ***

• A custom crypto token needs to implement the interface org.signserver.server.cryptotokens.ICryptoToken. See P12CryptoToken for an example implementation.
• You can define own properties for a crypto token in the same way as for workers. The properties are sent to the crypto token upon initialization.
• Make sure the custom class is available to the application server
• Redeploy the SignServer.
• Register the crypto token to a worker in the application by setting a property WORKER<id>.CRYPTOTOKEN.CLASSPATH with a global scope in the global configuration. (Also make sure to set it's crypto tokens class-path, see next section).
• Reload the service with the CLI reload command.

The ICryptoToken interface have the following methods that needs to be implemented:

public interface ICryptoToken {
	public static final int PURPOSE_SIGN = 1;
	public static final int PURPOSE_DECRYPT = 2;

	public static final int PROVIDERUSAGE_SIGN    = 1;
	public static final int PROVIDERUSAGE_DECRYPT = 2;

   /**
    * Method called after creation of instance.
    *
    */
	public abstract void init(Properties props) throws CryptoTokenInitializationFailureException;

	/**
	 *  Method that returns the current status of the crypto token.
	 *
	 *  Should return one of the SignerStatus.STATUS_.. values
	 */
	public abstract int getCryptoTokenStatus();

    /**
     * Method used to activate SignTokens when connected after being off-line.
     *
     * @param authenticationcode used to unlock crypto token, i.e PIN for smartcard HSMs
     * @throws CryptoTokenOfflineException if SignToken is not available or connected.
     * @throws CryptoTokenAuthenticationFailureException with error message if authentication to crypto token fail.
     */
    public abstract void activate(String authenticationcode) throws CryptoTokenAuthenticationFailureException, CryptoTokenOfflineException;

    /**
     * Method used to deactivate crypto tokens.
     * Used to set a crypto token too off-line status and to reset the HSMs authorization code.
     *
     * @return true if deactivation was successful.
     */
    public abstract boolean deactivate();

    /** Returns the private key (if possible) of token.
    *
    * @param purpose should one of the PURPOSE_... constants
    * @throws CryptoTokenOfflineException if CryptoToken is not available or connected.
    * @return PrivateKey object
    */
    public abstract PrivateKey getPrivateKey(int purpose) throws CryptoTokenOfflineException;

    /** Returns the public key (if possible) of token.
    *
    * @param purpose should one of the PURPOSE_... constants
    * @throws CryptoTokenOfflineException if CryptoToken is not available or connected.
    * @return PublicKey object
    */
    public abstract PublicKey getPublicKey(int purpose) throws CryptoTokenOfflineException;


    /** Returns the signature Provider that should be used to sign things with
     *  the PrivateKey object returned by this crypto device implementation.
     *  @param providerUsage should be one if the ICryptoToken.PROVIDERUSAGE_ constants
     *  specifying the usage of the private key.
     * @return String the name of the Provider
     */
    public abstract String getProvider(int providerUsage);

    /**
     * Method returning the crypto tokens certificate if it's included in the token.
     * This method should only be implemented by soft crypto tokens which have the certificate
     * included in the key store.
     *
     * All other crypto tokens should return 'null' and let the signer fetch the certificate from database.
     *
     */

    public abstract Certificate getCertificate(int purpose) throws CryptoTokenOfflineException;


    /**
     * Method returning the crypto tokens certificate chain if it's included in the token.
     * This method should only be implemented by soft crypto tokens which have the certificates
     * included in the key store.
     *
     * All other crypto tokens should return 'null' and let the signer fetch the certificate from database.
     *
     */

    public abstract Collection<Certificate> getCertificateChain(int purpose) throws CryptoTokenOfflineException;

	/**
	 * Method used to tell the crypto token to create a certificate request using its crypto token.
	 */
	public ICertReqData genCertificateRequest(ISignerCertReqInfo info) throws CryptoTokenOfflineException;

	/**
	 * Method used to remove a key in the signer that shouldn't be used any more
	 * @param purpose on of ICryptoToken.PURPOSE_ constants
	 * @return true if removal was successful.
	 */
	public boolean destroyKey(int purpose);
}
                        

*** The Extended Crypto Token Interface ***

The default group key service need support for symmetric keys in addition the the functionality provided in the basic crypto token which mainly focuses on asymmetric key functionality.

The extended crypto token adds four more methods that need implementation used to generate exportable keys (symmetric or asymmetric) and to encrypt/decrypt data using symmetric keys.

public interface IExtendedCryptoToken extends ICryptoToken {

	/**
	 * Method instructing the crypto token to generate a key that is returned
	 *
	 * @param keyAlg the key algorithm to generate, it's up to the caller to check that the crypto token
	 * used supports the given value.
	 * @param keySpec specification of the key, it's up to the caller to check that the crypto token
	 * used supports the given value.
	 * @return either a java.security.Key or a java.security.KeyPair depending on type of keyAlg sent to the the crypto token.
	 * @throws IllegalRequestException if the token doesn't support the given key alg or key spec.
	 * @throws CryptoTokenOfflineException if the token isn't online.
	 */
	Serializable genExportableKey(String keyAlg, String keySpec) throws IllegalRequestException, CryptoTokenOfflineException;

	/**
	 * Instructs the crypto token to generate a key stored in the device returning only
	 * a alias reference to the key.
	 *
	 * @param keyAlg the key algorithm to generate, it's up to the caller to check that the crypto token
	 * @param keySpec keySpec specification of the key, it's up to the caller to check that the crypto token
	 * used supports the given value.
	 * @return a reference to the key in that can be used later for encryption/decryption.
	 *
	 * @throws IllegalRequestException if the token doesn't support the given key alg or key spec.
	 * @throws CryptoTokenOfflineException if the token isn't online.
	 */
	String genNonExportableKey(String keyAlg, String keySpec) throws IllegalRequestException,  CryptoTokenOfflineException;

	/**
	 * Method used to encrypt data using a key stored in the crypto token. This
	 * method should mainly be used for symmetric encryption.
	 * @param keyRef a alias reference to the key that should be used.
	 * @param data the data to encrypt.
	 * @return the encrypted data.
	 * @throws CryptoTokenOfflineException if the token isn't online.
	 */
	byte[] encryptData(String keyRef, byte[] data) throws CryptoTokenOfflineException;

	/**
	 * Method used to decrypt data using a key stored in the crypto token. This
	 * method should mainly be used for symmetric encryption.
	 * @param keyRef a alias reference to the key that should be used.
	 * @param data the data to decrypt.
	 * @return the encrypted data.
	 * @throws CryptoTokenOfflineException if the token isn't online.
	 */
	byte[] decryptData(String keyRef, byte[] data) throws CryptoTokenOfflineException;


}
                        

*** The TSA Test Client ***

There exists a Time Stamp Authority test client that is built with the main distribution. For other workers it's recommended to test it with the WS CLI client described in the 'Main WebService' section.

It only works without client authentication requirements and through HTTP.

To run the client do

ant
cd dist-client
java -jar timeStampClient.jar "http://<hostname>:8080/signserver/tsa?signerId=1"
                        

It will continuously make one request per second. Run the test client without arguments to get a list of possible arguments, you can use it as a full time stamp client to get real document time stamps.

java -jar timeStampClient.jar
 -instr <string>      String to be time stamped, if neither instr or
                      infile is given, the client works in test-mode generating it's own
                      message.
 -base64              Give this option if the stored request/reply should
                      be base64 encoded, default is not.
 -help                Print this message.
 -infile <file>       File containing message to time stamp.

...snip...
                        

*** Manual Tests ***

The time stamp signer have been tested with the OpenTSA client with both HTTP and HTTPS.

*** Overview ***

The SignerStatusReportTimedService is a timed service that outputs status for a set of workers to a file. The information includes each workers crypto token status ACTIVE/OFFLINE and if available also the numbers of signatures that has been performed with the key currently associated with the worker. If the worker has a configured limit of number of signatures, this value is also included.

Format:

workerName=WORKERNAME1, status=STATUS1, KEY3=VALUE3, KEY4=VALUE4, ...
workerName=WORKERNAME2, status=STATUS2, KEY3=VALUE3, KEY4=VALUE4, ...
workerName=WORKERNAME3, status=STATUS3, KEY3=VALUE3, KEY4=VALUE4, ...
...
                        

Rules:

• Each line contains a set of properties for one worker.
• Lines are separated by a system dependent newline character (CR, LF or CRLF).
• Properties are of form KEY=VALUE and are separated by a comma and a space (", ").
• The properties "workerName" and "status" are the only ones that must be present.
• The property "workerName" is always the first property.

Properties:

• workerName: name of the worker. Example: "sod71" or "sod72"
• status: status of the worker's crypto token and key. Either "ACTIVE" or "OFFLINE".
• validityNotBefore: the first date the signer is allowed to sign. Format is java.text.SimpleDateFormat("yyyy-MM-dd HH:mm:ss z").
• validityNotAfter: the last date the signer is allowed to sign.
• signings: the number of signatures that has been performed with the key used by this worker.
• signLimit: the maximum number of signatures this worker is allowed to perfom or -1 if there is no limit.

Examples:

workerName=Sod71, status=ACTIVE, validityNotBefore=2010-07-05 17:32:36 CEST, validityNotAfter=2010-09-08 17:32:36 EEST, signings=132, signLimit=100000,
workerName=Sod72, status=OFFLINE, validityNotBefore=2010-07-05 17:32:33 CEST, validityNotAfter=2010-09-08 17:32:33 EEST, signings=100000, signLimit=100000,
workerName=Sod73, status=OFFLINE, validityNotBefore=2010-07-05 17:32:33 CEST, validityNotAfter=2010-09-08 17:32:33 EEST, signings=0, signLimit=100000,
workerName=Sod74, status=OFFLINE,
                        

Examples explained:

Sod71 has done 132 signings and is ACTIVE and validityNotAfter indicates that it can continue to sign until 8th September if not the sign limit is reached before

Sod72 has performed all of its 100000 signings and can not sign until it gets a new key and certificate.

Sod73 has not reached its limit and is still in validity time but is OFFLINE for some other reason.

Sod74 is OFFLINE and has no certificate configured.

*** Available Properties ***

WORKERS = Comma separated list of worker names (signers) that should be monitored.

OUTPUTFILE = File that the information will be written to. If the file exists the content will be overwritten. The application server needs to have write access to this file when the service is executed.

Unix SignServer Installation            : /etc/signserver/signserver.conf
Windows SignServer Installation         : %SYSTEMROOT%\signserver.conf
                                         (i.e C:\WINDOWS\signserver.conf)
                    

*** SignServer Node ***

The server part of the SignServer package contains everything (except Java) that is needed to set-up a node in a cluster. It contains a preconfigured version of JBoss that is ready to use.

The steps performed during the installation process are:

Unix:

• By default is everything unpacked in /opt/signserver-<version> .
• If a /etc/signserver/signserver.conf file exists, it's read and used during installation.
• The user and group 'signserver' is created
• JBoss init.d script is configured to run at runlevel 3,4,5
• Directory /etc/signserver/ is created to contain all configuration files
• Database configuration file /etc/signserver/database-conf.xml is populated.
• Log configuration file /etc/signserver/log-conf.xml is populated and configured to log to the directory /var/log/signserver
• If no HTTP SSL certificate is specified in the configuration file will dummy key stores be generated to /etc/signserver.
• Tomcat is configured for HTTPS and it's configuration file is placed in /etc/signserver/webserver-conf.xml
• Finally is Jboss started and ready to be used.

Windows:

• By default is everything unpacked in C:\Program\SignServer\SignServer-<version> .
• If a c:\WINDOWS\signserver.conf file exists it's read and used during installation.
• JBoss is configured to be run as a service that is started automatically.
• Database configuration file <INSTALLDIR>\database-conf.xml is populated.
• Log configuration file <INSTALLDIR>\log-conf.xml is populated and configured to log to the default directory <INSTALLDIR>\jboss\server\default\log
• If no HTTP SSL certificate is specified will dummy key stores be generated to <INSTALLDIR>
• Tomcat is configured for HTTPS and it's configuration file is placed in <INSTALLDIR>\webserver-conf.xml
• Finally is Jboss started and ready to be used.

The supported properties in the configuration file /etc/signserver/signserver.conf (or %SYSTEMROOT%\signerserver.conf for windows) are:

Property Name	Description	Example value	Where to manually reconfigure
SIGNSERVER_NODEID	A unique string value (containing alphanumeric characters only) identifying the node in a cluster.	node1	Unix: /etc/signserver/signserver.conf Windows: %Systemroot%\signserver.conf
database.type	Type of database, currently are Hypersonic, Mysql, Mysql Cluster, Postgres and MS SQL 2000 supported	hsqldb, mysql, mysqlndb, postgres, mssql2000	Unix: /etc/signserver/database-conf.xml Windows: %Installdir%\database-conf.xml
database.hosts	The hostnames of the databases used. (not used for hsqldb).	localhost	Unix: /etc/signserver/database-conf.xml Windows: %Installdir%\database-conf.xml
database.port	The port of the database (not used for hsqldb).	1433	Unix: /etc/signserver/database-conf.xml Windows: %Installdir%\database-conf.xml
database.name	The name of the database (not used for hsqldb).	signserver	Unix: /etc/signserver/database-conf.xml Windows: %Installdir%\database-conf.xml
database.username	The username used for authentication against the database (not used for hsqldb).	signserver	Unix: /etc/signserver/database-conf.xml Windows: %Installdir%\database-conf.xml
database.password	The password used for authentication against the database (not used for hsqldb).	foo123	Unix: /etc/signserver/database-conf.xml Windows: %Installdir%\database-conf.xml
httpserver.hostname	Hostname used as CN in generated SSL Server certificate.	host1.someorg	Only used during the of SSL Server certificate generation phase of installation.
httpserver.storepath	Path to the key store (JKS file) containing the SSL server certificate.	/etc/signserver/tomcat.jks	Unix: /etc/signserver/webserver-conf.xml Windows: %Installdir%\webserver-conf.xml
httpserver.password	Password to unlock the SSL server certificate key store.	foo123	Unix: /etc/signserver/webserver-conf.xml Windows: %Installdir%\webserver-conf.xml
httptrust.storepath	Path to the key store (JKS file) containing the CA trust store.	/etc/signserver/truststore.jks	Unix: /etc/signserver/webserver-conf.xml Windows: %Installdir%\webserver-conf.xml
httptrust.password	Password unlocking the CA truststore.	foo123	Unix: /etc/signserver/webserver-conf.xml Windows: %Installdir%\webserver-conf.xml
syslog.hostname	Host name of the Syslog server. This setting also indicates that Syslog should be used.	loghost.someorg.org	Unix: /etc/signserver/log-conf.xml Windows: %Installdir%\log-conf.xml

*** SignServer Management ***

This package installs the CLI interface on the management station (which can be the same as a node). The following steps are performed during installation:

Unix:

• By default is everything unpacked in /opt/signserver-<version> .
• If a /etc/signserver/signserver.conf file exists it's read and used during installation.
• The user and group 'signserver' is created
• A link from /opt/signserver-<version>/bin/signserver.sh is done to /usr/local/bin.

Windows:

• Everything is unpacked in C:\Program\SignServer\SignServer-<version> by default.
• If a c:\WINDOWS\signserver.conf file exists it's read and used during installation.

The signserver.conf supports the following settings:

Property Name	Description	Example value	Where to manually reconfigure
hostname.masternode	Hostname of master node in the cluster.	node1.someorg.org	Unix: /etc/signserver/signserver.conf Windows: %Installdir%\signserver.conf
hostname.allnodes	Hostname of all hosts in cluster, separated by ';'.	node1.someorg.org;node2.someorg.org	Unix: /etc/signserver/signserver.conf Windows: %Installdir%\signserver.conf