Common Worker Configuration
Workers and components are configured by setting properties in the worker configuration. The common configuration options handled by the framework apply to all workers. The worker-specific properties are handled by the worker implementation.
The following lists the common property categories:
You can comment out properties to temporarily disable them by adding a pre- or postfix underscore. Example: _ACCOUNTER
Commenting out masked sensitive properties will still protect the properties and mask them in the cases described in the Masking Sensitive Properties section.
General Properties
Each worker is identified by a unique ID. A worker can also be configured with a name by setting the worker property NAME. After the configuration is activated (by issuing reload with the worker ID), that name can also be used to address the worker.
Property | Description |
|---|---|
NAME = <worker> | Provide a good descriptive name of the worker. Alternatively, a logical name that is easy to keep track of. |
TYPE = <worker type> | Currently worker type may be one of the following:
|
IMPLEMENTATION_CLASS = <class name> | Provide the fully-qualified class name of the worker. |
DISABLED | Setting this to true disables a worker. A disabled worker cannot perform any operations and any requests to the worker will fail. The status is visible on the Workers Page. Default: false. Disabled workers are not included in the Health Check report. |
Authorization Type Properties
By default (and if the property is not set), client-certificate authentication is required for a signature request to be processed. This can be changed using the AUTHTYPE property.
Property | Description |
|---|---|
AUTHTYPE = NOAUTH | No authentication. Sets the server to not require any authentication. |
AUTHTYPE = CLIENTCERT | Client certificate authentication Default value. 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. |
AUTHTYPE=<Authorizers> | Other authentication. Select the appropriate authorizer from the table on Authorizers. |
Accounter Property
An Accounter is responsible for somehow charging a client for a successful request or to deny the request if the client has insufficient funds.
When a request has been processed, and if the worker marked the request as successfully fulfilled, the configured Accounter (if any) is called. The Accounter implementation could potentially query an external database and make a purchase for the service.
Property | Description |
|---|---|
ACCOUNTER | The Accounter to use is configured using the ACCOUNTER worker property. By default, no Accounter is used. Example:
|
See also the section about all available Accounters.
Archiving Properties
The archiving feature allows saving all requests and/or responses.
For the OldDatabaseArchiver and Base64DatabaseArchiver archivers, the Administration CLI can be used to query the archive, see Administration CLI.
When a request has been processed, each Archiver is called one at the time to archive any results.
Property | Description |
|---|---|
ARCHIVERS | Used instead of the old Example:
|
| Legacy property. Instead use Previously, the archiving was enabled by setting this property to true. This is the same as to set Default: false. |
For more information on available archivers, see Archivers.
Other Properties
Property | Description |
|---|---|
NOCERTIFICATES | Setting this to true tells SignServer not to give an error if no signer certificate is configured for this worker. This can be useful for special types of workers not performing any signing operations or only requiring a public key, for example, Plain Signer. Default: false. When NOCERTIFICATES is set to true, the signer certificate is typically not displayed in the status output as status properties and is not returned as part of a signing response. |
EXPLICITECC | Setting this to true in a signer uses explicit domain parameters instead of Named Curves when generating a certificate request (CSR) using a RenewalWorker or through the Admin Web Worker Page. Default: false. The CSR must be generated from the worker and not using the Crypto Token tab. |
Masking Sensitive Properties
To reduce the risk of accidentally exposing sensitive data, for instance when sharing outputs for troubleshooting or support purposes, certain property values can be masked when exporting worker configurations or displaying the worker status etc.
By default, the following properties are masked:
PIN
KEYSTOREPASSWORD
KEYDATA
You can customize which properties are masked by setting the maskedworkerproperties parameter in the conf/signserver_deploy.properties file at deployment time. Refer to the sample configuration file for examples. See the Configure Deployment section in Install SignServer for details on how to apply these settings.
Masking of properties is applied across all remote interfaces, including Admin Web, Admin Web Services (WS), REST API, as well as the audit log. Additionally, masking is enforced for commands executed in the local Admin CLI when retrieving properties from the server.
The Admin CLI also supports masking when reading in configuration and setting properties. To configure masking for those commands, use the admincli.maskedworkerproperties property in the conf/signserver_cli.properties file. Again, refer to the sample file for specific examples.