Miscellaneous

The Global Configuration Store

The available workers and its crypto tokens and services is configured in something called the global configuration store that is slightly different from a worker configuration.

Is is dynamically configured and activated immediately. I can contain any type of data (in string representation) and can be of two types, either with global scope or node scope. A Global scoped property can be accessed by all nodes in the cluster while a Node scoped property in only used within a node and cannot be accessed by the other nodes.

SignServer specific

Database failure is handled differently. If a node looses connection to the database it put itself in a state called 'unsynchronised' and will continue its operation without storing the data to database by using a cached global configuration. It is possible to later resynchronise one nodes cached global configuration data with the database with a CLI command called 'resync'. But it is only possible to sync one of the nodes global configuration to the database.

Status Repository

The status repository holds non-persistent local (per JVM) status information (properties) with optional expiration times. After the expiration time the property is not returned. The value is also not preserved among server restarts.

This could be used by having workers read the status from the repository while an external (or internal) service periodically updates it. The (optional) expiration time on the values makes it possible to detect if an periodic service has failed to update the value within the specified time.

From the Admin CLI the status repository can be controlled using the getstatusproperties, getstatusproperty and setstatusproperty commands.

Logging

SignServer uses Log4j for debug logging and the security events logger from CESeCore for system/audit logging. In addition the worker logger (transaction log) can be configured to use Log4j and/or the security events logger.

Worker Log

The purpose of the Worker Loggers are to log each transaction handled by the worker. Each worker can choose to have its own configuration for the logger. By default the AllFieldsWorkerLogger is used which used logs all the available fields one after each other separated by semi colons.

Which Worker Logger configuration to use is configured by setting the WORKERLOGGER property to the full class name of the IWorkerLogger implementation in the worker's configuration.

AllFieldsWorkerLogger

The default worker logger for most workers. Can be used during testing to find which fields a worker logs and then changed to the PatternWorkerLogger with only does fields that are of interest chosen.
LOGLEVEL_DEFAULT sets the level at which the logger will do log output. These are specified as standard Log4J levels (FATAL, ERROR, WARNING, INFO, DEBUG, and TRACE), if not set, it defaults to INFO.

WORKERLOGGER=org.signserver.server.log.AllFieldsWorkerLogger
LOGLEVEL_DEFAULT=INFO

SecurityEventsWorkerLogger

Worker logger using the CESeCore security events logger. This logger included all fields in the additionalDetails fields in the audit log, except the worker ID, which is mapped to searchDetail2.

The properties LOGINCLUDEFIELDS and LOGEXCLUDEFIELDS can be used to restrict the fields included in additionalDetails by explicitly setting a comma-separated list of field names. Only one of these options can be set at a time.

WORKERLOGGER=org.signserver.server.log.SecurityEventsWorkerLogger

PatternWorkerLogger

The LOGLEVEL_DEFAULT property has the same behavior as for the AllFieldsWorkerLogger.

WORKERLOGGER=org.signserver.server.log.PatternWorkerLogger
LOGTIMEZONE=GMT
LOGDATEFORMAT=yyyy-MM-dd:HH:mm:ss:z
LOGPATTERN=\$\{(.+?)\}
LOGORDER=AUDIT; LOG_ID: ${LOG_ID}; CLIENT_IP: ${CLIENT_IP}; REQUEST_FULLURL: ${REQUEST_FULLURL}; RequestTime: ${LOG_TIME}; ResponseTime: ${REPLY_TIME}; EXCEPTION: ${EXCEPTION};
LOGLEVEL_DEFAULT=INFO

DefaultTimeStampLogger

Pattern logger with a default log order suitable for logging time-stamp requests. This logger is the default logger used by the TimeStampSigner.

WORKERLOGGER=org.signserver.module.tsa.DefaultTimeStampLogger

NullWorkerLogger

Worker logger that does not log anything.

WORKERLOGGER=org.signserver.server.log.NullWorkerLogger

CustomTimeStampLogger1

WORKERLOGGER=org.signserver.module.tsa.CustomTimeStampLogger1

FileWorkerLogger

Worker logger that writes the log values to a worker-specific log file (the logger logs all fields, similar to AllFieldsWorkerLogger.
This logger is mainly intended for use by unit tests, and is not thread safe.

WORKERLOGGER=org.signserver.server.log.FileWorkerLogger
LOG_FILE_PATH=/path/to/logfile

System Log

The purpose of the system log is to log events concerning the SignServer application but not necessarily related to any signing transaction (that is covered by the Worker Log). The audit log covers key and certificate management events, status properties updates (for instance for the status of the time source) and to some extent also configuration changes. For details see the table of events below.
From version 3.4.0 SignServer uses the CESeCore library to perform audit logging.

Available log events

Services
SIGNSERVER_STARTUP

Logged at startup of the SignServer application.

VERSION: The version of SignServer.

Example:

EVENT: SIGNSERVER_STARTUP; MODULE: SERVICE; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: null; VERSION: SignServer 3.3.0alpha12; REPLY_TIME:1350562045545
SIGNSERVER_SHUTDOWN

Logged at shutdown of the SignServer application.

VERSION: The version of SignServer.

Example:

EVENT: SIGNSERVER_SHUTDOWN; MODULE: SERVICE; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: null; VERSION: SignServer 3.3.0alpha12; REPLY_TIME:1350562045545
Global configuration
SET_GLOBAL_PROPERTY

Logged when a global configuration property was updated.

GLOBALCONFIG_PROPERTY: The property that was updated.
GLOBALCONFIG_VALUE: The new value of the property.

Example:

EVENT: SET_GLOBAL_PROPERTY; MODULE: GLOBAL_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: null; GLOBALCONFIG_VALUE: TESTVALUE47; GLOBALCONFIG_PROPERTY: GLOB.TESTPROPERTY47; REPLY_TIME:1350657202153
REMOVE_GLOBAL_PROPERTY

Logged when a global configuration property was removed.

GLOBALCONFIG_PROPERTY: The property that was removed.

Example:

EVENT: REMOVE_GLOBAL_PROPERTY; MODULE: GLOBAL_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: null; GLOBALCONFIG_PROPERTY: GLOB.TESTPROPERTY47; REPLY_TIME:1350657202444
GLOBAL_CONFIG_RELOAD

Logged when the global configuration was reloaded from the database.

Example:

EVENT: GLOBAL_CONFIG_RELOAD; MODULE: GLOBAL_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: null; REPLY_TIME:1350657202593
GLOBAL_CONFIG_RESYNC

Logged when the resync command was executed.

Example:

EVENT: GLOBAL_CONFIG_RESYNC; MODULE: GLOBAL_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: null; REPLY_TIME:1350894343902
Worker configuration
SET_WORKER_CONFIG

Logged when a worker's configuration was updated by adding and/or removing and/or changing any values.

WORKER_ID: The ID of the worker.

Changes in worker properties are logged with prefixes added/changed/removed followed by a colon and the property name a colon and the property value.
Several property changes can occur in one log line (see examples below).
Authorized clients are shown as a property with the name authorized_client.

Example:

EVENT: SET_WORKER_CONFIG; MODULE: WORKER_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 100; added:FOO: bar; REPLY_TIME:1350657202773
EVENT: SET_WORKER_CONFIG; MODULE: WORKER_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 100; changed:FOO: newvalue; REPLY_TIME:1350657202873
EVENT: SET_WORKER_CONFIG; MODULE: WORKER_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 100; removed:FOO: newvalue; REPLY_TIME:1350657202873
EVENT: SET_WORKER_CONFIG; MODULE: WORKER_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 100; added:FOO: bar; changed:BAR: newvalue; REPLY_TIME:1350657202873
EVENT: SET_WORKER_CONFIG; MODULE: WORKER_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 100; added:authorized_client: SN: 1234567890, issuer DN: CN=Test; REPLY_TIME:1350657202873
CERTINSTALLED

Logged when a certificate was uploaded to the worker configuration.

WORKER_ID: The ID of the worker.
CERTIFICATE: The certificate in PEM format.
SCOPE: If the setting was at GLOBAL or NODE scope.
NODE: The ID of the node if the setting was at NODE scope, otherwise not available.

Example:

EVENT: CERTINSTALLED; MODULE: WORKER_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 100; CERTIFICATE: Subject: CN=Anyone
Issuer: CN=Anyone
-----BEGIN CERTIFICATE-----
MIIBnTCCAQagAwIBAgIIWWNYSOeuN+swDQYJKoZIhvcNAQEFBQAwETEPMA0GA1UE
AwwGQW55b25lMB4XDTEyMTAxOTE0MzMyM1oXDTEzMTAxOTE0MzMyM1owETEPMA0G
A1UEAwwGQW55b25lMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCDE9GElbJd
e74WmIpPSsIF9r5vv0oH6WWo7n31goR1zMIHJPC9V1mpwQZ6C0uCHCV2ZvqQIIAE
ZQM7mgbPfxjCF74RqKzScZlOSaHnvdf7zCWpYraVrIDt9Wg3HMxye0/L3cCImmkY
FkFtabtoa5UuPZObdIt154Yg+GpGB8aPBwIDAQABMA0GCSqGSIb3DQEBBQUAA4GB
AHm3oAUHwM0KwMcEUwWouE0f4+UK6ZvYvxLAgiCVZQnPImcqX1oBl+iFV59FlsXj
rqoQYJROxIeV0ByGeyBYXqvgTw1YtdqoR+wKmiymjn/lynmTh1fQMcFoUouGfubX
EK4rfPBXEl33gKbsO5aeMHd5iF2jtx7RfYMsOuHKoDSe
-----END CERTIFICATE-----
; SCOPE: GLOBAL; REPLY_TIME:1350657204367
CERTCHAININSTALLED

Logged when a certificate chain was uploaded to the worker configuration or imported to a crypto token.

With MODULE: WORKER_CONFIG the certificate chain was installed in the configuration:

WORKER_ID: The ID of the worker.
CERTIFICATECHAIN: The certificates in PEM format.
SCOPE: If the setting was at GLOBAL or NODE scope.
NODE: The ID of the node if the setting was at NODE scope, otherwise not available.

Example:

EVENT: CERTCHAININSTALLED; MODULE: WORKER_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 100; CERTIFICATECHAIN: Subject: CN=Signer,C=SE
Issuer: CN=Issuer,C=SE
-----BEGIN CERTIFICATE-----
MIIBdjCCASCgAwIBAgIIE+fXOs/SAwMwDQYJKoZIhvcNAQEFBQAwHjEPMA0GA1UE
AwwGSXNzdWVyMQswCQYDVQQGEwJTRTAeFw0xMjEwMjIwNzQ1MDZaFw0xMzEwMjIw
NzQ1MDZaMB4xDzANBgNVBAMMBlNpZ25lcjELMAkGA1UEBhMCU0UwgZ8wDQYJKoZI
hvcNAQEBBQADgY0AMIGJAoGBAKpX5psdaL5CHAKSxoOvB12Ie8iUb/mX6ikF8jfu
zrbwVgf6bX0RCUnD+v+t9vY7byz+nN32KnmGluNGdBFdM1Ug9Oc+64ZNBbgZi9mi
cHnKMDLLSECBY2Nux62PZejp5SwtzpjFymt3TMCtRr4UHGu3zkuqLLCHFlGRdvdo
MPQ9AgMBAAEwDQYJKoZIhvcNAQEFBQADQQADlInGm9AujZfL+1kM7ehaKyKKencF
fp6YGElOpGEplxxIwgmVc0iYKv4rCkfUAysYL6l3AC+VLK1asxkpEJc1
-----END CERTIFICATE-----
Subject: CN=Issuer,C=SE
Issuer: CN=Issuer,C=SE
-----BEGIN CERTIFICATE-----
MIIBMTCB3KADAgECAggbfKZHs8ttKDANBgkqhkiG9w0BAQUFADAeMQ8wDQYDVQQD
DAZJc3N1ZXIxCzAJBgNVBAYTAlNFMB4XDTEyMTAyMjA3NDUwNloXDTEzMTAyMjA3
NDUwNlowHjEPMA0GA1UEAwwGSXNzdWVyMQswCQYDVQQGEwJTRTBcMA0GCSqGSIb3
DQEBAQUAA0sAMEgCQQCpgzxJ6r6D1cP8v1AB88pJsCwi0SJdeRSGYydYYBOafJk0
fpqxJCwaiFS3tt9OkWUAXzcixv5+sItkEuEOpmp7AgMBAAEwDQYJKoZIhvcNAQEF
BQADQQCC5NG3eWx/mXXKZmePOvZEIwyqWHOwzsBB174gkzlyhOdiOr3YwVihyebI
VAfkEktRrO04Hi5eLR+AxW7EVz6l
-----END CERTIFICATE-----
; SCOPE: GLOBAL; REPLY_TIME:1350891906417

With MODULE: KEY_MANAGEMENT the certificate chain was imported to the token:

WORKER_ID: The ID of the worker.
CERTIFICATECHAIN: The certificates in PEM format.
KEYALIAS: The alias of the entry in the token.
CRYPTOTOKEN: Name of the configured crypto worker or the name or ID of the current worker if no separate crypto worker is used.

Example:

EVENT: CERTCHAININSTALLED; MODULE: KEY_MANAGEMENT; ADMINISTRATOR: CLI user; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 5801; KEYALIAS: testkeyalias10; CRYPTOTOKEN: HSMCryptoToken1; CERTIFICATECHAIN: Subject: CN=testkeyalias10,C=SE
Issuer: CN=Issuer,C=SE
-----BEGIN CERTIFICATE-----
MIIBMjCB3aADAgECAgEBMA0GCSqGSIb3DQEBCwUAMB4xDzANBgNVBAMMBklzc3Vl
cjELMAkGA1UEBhMCU0UwHhcNMTUwNTI5MTEzMTAyWhcNMTYwNTI4MTEzMTAyWjAm
MRcwFQYDVQQDDA50ZXN0a2V5YWxpYXMxMDELMAkGA1UEBhMCU0UwXDANBgkqhkiG
9w0BAQEFAANLADBIAkEAggmuPO78M3hhwh4MrxYzt0LM6vLmI4IWjLxO8EK8R0FV
cDu5Rruxc/a51LCt8J8dOxm34h0RakqzObbFYZxwZwIDAQABMA0GCSqGSIb3DQEB
CwUAA0EAYR/N98UTyjnkFMnRmd1dQfsD6cih7Dt6NTi+qxFeMbbuzVA9HhRcXwQn
NChSJMtvJ9sKslfhlfqwZGPChSFg3g==
-----END CERTIFICATE-----
Subject: CN=Issuer,C=SE
Issuer: CN=Issuer,C=SE
-----BEGIN CERTIFICATE-----
MIIBMTCB3KADAgECAghQdZlXUcZalTANBgkqhkiG9w0BAQUFADAeMQ8wDQYDVQQD
DAZJc3N1ZXIxCzAJBgNVBAYTAlNFMB4XDTE1MDUyOTExMzEwMloXDTE2MDUyODEx
MzEwMlowHjEPMA0GA1UEAwwGSXNzdWVyMQswCQYDVQQGEwJTRTBcMA0GCSqGSIb3
DQEBAQUAA0sAMEgCQQCa35ZZru5A2DigDNyOdsZL789dVVlUTXch/Fa0e82X+FLc
kuMoRqAuxrEw/5+uG1Xi7EkysdgyRPbdYHmv3hBlAgMBAAEwDQYJKoZIhvcNAQEF
BQADQQAS3us4jsjHRSooeNuaaAdWjrA7b/nVnkhRjEmHUCORJXGwnHykUGB2idj6
d3UejoxEJ78E+EAYWO2JvKbhV0ku
-----END CERTIFICATE-----
; REPLY_TIME:1432899062650

KEYSELECTED

Logged when the key-pair to use was selected by changing the value of the DEFAULTKEY worker property.

WORKER_ID: The ID of the worker.
KEYALIAS: The new key alias.
CRYPTOTOKEN: Name of the configured crypto worker or the name or ID of the current worker if no separate crypto worker is used.
SCOPE: If the setting was at GLOBAL or NODE scope.
NODE: The ID of the node if the setting was at NODE scope, otherwise not available.

Example:

EVENT: KEYSELECTED; MODULE: WORKER_CONFIG; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 100; KEYALIAS: ts_key00002; CRYPTOTOKEN: TestSigner6000; SCOPE: GLOBAL; REPLY_TIME:1350891907048
Key management
KEYGEN

Logged when a new key-pair was generated using the built-in key generation command.

WORKER_ID: The ID of the worker.
KEYALIAS: The new key alias.
CRYPTOTOKEN: Name of the configured crypto worker or the name or ID of the current worker if no separate crypto worker is used.
KEYSPEC: The key specification (i.e. RSA/DSA bit length or EC curve).
KEYALG: The key algorithm.

Example:

EVENT: KEYGEN; MODULE: KEY_MANAGEMENT; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 5676; KEYALIAS: ts_key00004; CRYPTOTOKEN: HSMCryptoToken0; KEYSPEC: 2048; KEYALG: RSA; REPLY_TIME:135089190791
KEYTEST

Logged when the key test command was executed and a test signing with either the specified key or all keys in the slot if that was specified.

WORKER_ID: The ID of the worker.
KEYALIAS: Alias of the the key to test or "all" to test all available keys in the slot.
CRYPTOTOKEN: Name of the configured crypto worker or the name or ID of the current worker if no separate crypto worker is used.
TESTRESULTS: The test report with an entry for each tested key.

Example:

EVENT: KEYTEST; MODULE: KEY_MANAGEMENT; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 47; KEYALIAS: all; CRYPTOTOKEN: HSMCryptoToken1; TESTRESULTS: KeyTestResult{alias=tsu47_key00005, success=true, status=, publicKeyHash=979359e5261112b11fac341962bec1e7e6052d9e}
KeyTestResult{alias=key5, success=true, status=, publicKeyHash=46b264e4892ef2e4fd9616e4927534ca3597fd9c}
KeyTestResult{alias=key3, success=true, status=, publicKeyHash=ae64792f1f50e23eb54bf79d46d819bc07db2d79}
KeyTestResult{alias=key2, success=true, status=, publicKeyHash=b1317f363e6124a8e15bba8c1adb9f20b2f4ef59}
KeyTestResult{alias=TS Signer 1, success=true, status=, publicKeyHash=8f6dfccdcea931d4deee9466f43c0eb0e7f4d8b1}
; REPLY_TIME:1350564289165
GENCSR

Logged when a certificate signing request (CSR) was generated.

WORKER_ID: The ID of the worker.
KEYALIAS: The key alias of the key used to generate the CSR.
FOR_DEFAULTKEY: True if the "default key" was requested.
CRYPTOTOKEN: Name of the configured crypto worker or the name or ID of the current worker if no separate crypto worker is used.
CSR: Base64 encoded CSR (typically in PKCS#10 format).

Example:

EVENT: GENCSR; MODULE: KEY_MANAGEMENT; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 5676; KEYALIAS: ts_key00004; CRYPTOTOKEN: HSMCryptoToken0; CSR: MIIBYDCBygIBADAjMRQwEgYDVQQDDAtUUyBTaWduZXIgMTELMAkGA1UEBhMCU0Uw
gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJt8F51wD+QcX+WLyIxjWu3at3q+
IiJrL5jIenmggUhjOLHGHOStoNOiYEQAaiiTZ623m9y7O3zhqFdAdWZg+JrfsHQJ
pjKV9RgvJznl6yk/K54BWOBgqjvbloAUGtn8y8Hf+5DYJUJNFqrzvRLcmCQ9JU0H
mgSmEIqgOIwBL3oBAgMBAAEwDQYJKoZIhvcNAQEFBQADgYEAer5hr/cUYx4jy0XO
N4U8sP/2gSFppytx9dn5BamVBLjDkcML8B3c9u9omDPebd+LEsCU+HCmYN9xHkSS
Ei8lcAqyVv+SDLEmvE8gnrPFR/J7uADCRayLVQumW6/YpVO/sFEGuM6rgnn8ZJmW
X2lhvJ4V1UhlkEAeyIQ861U3IgE=; REPLY_TIME:1350891907981
KEYREMOVE

Logged when a key was removed or an removal attempt was performed.

WORKER_ID: The ID of the worker.
KEYALIAS: The key alias of the key removed.
CRYPTOTOKEN: Name of the configured crypto worker or the name or ID of the current worker if no separate crypto worker is used.
SUCCESS: True if the key was removed or false if the removal failed or if removal was not supported by the token.

Example:

EVENT: KEYREMOVE; MODULE: KEY_MANAGEMENT; ADMINISTRATOR: CLI user; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: 20003; KEYALIAS: signKey000002; CRYPTOTOKEN: HSMCryptoToken1; SUCCESS: true; REPLY_TIME:1391008847962
Status Repository
SET_STATUS_PROPERTY

Logged when a status property was updated.

STATUSREPO_PROPERTY: The updated property.
STATUSREPO_VALUE: The new property value.
STATUSREPO_EXPIRATION: Expiration time for the status property (timestamp), if any.

Example:

EVENT: SET_STATUS_PROPERTY; MODULE: STATUS_REPOSITORY; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: null; STATUSREPO_EXPIRATION: 1350891909366; STATUSREPO_PROPERTY: TEST_PROPERTY1; STATUSREPO_VALUE: TESTVALUE47; REPLY_TIME:1350891908372
Worker processing
PROCESS

Logged for events regarding worker processing but when a worker logger can not be used because the requested worker does not exist etc.

WORKER_ID: The ID of the worker or empty in case of non existing worker.
Worker logger fields: All fields available to the worker logger.

Example:

EVENT: PROCESS; MODULE: WORKER; ADMINISTRATOR: null; ISSUER: null; SERIAL_NUMBER: null; WORKER_ID: null; LOG_ID: db517726-ff0d-40dd-8f2b-2297925cb4d3; CLIENT_IP: 127.0.0.1; PROCESS_SUCCESS: false; REQUEST_LENGTH: 0; XFORWARDEDFOR: null; FILENAME: noname.dat; 
REQUEST_FULLURL: http://localhost:8080/signserver/process?null; LOG_TIME: 1350628977410; WORKER_ID: 0; EXCEPTION: No such worker: 0; REPLY_TIME:1350628977411

CESeCore Security Events Logger

The default logging implementation, org.signserver.server.log.SignServerLog4jDevice uses Log4J and a similar logging format as the old SystemLogger.

Signed log

Note
This is a SignServer Enterprise Edition (EE) feature.

An example configuration for CESeCore is provided in conf/cesecore.properties.sample.

To enable signed audit logs configure conf/databaseprotection.properties (see conf/databaseprotection.properties.sample). And set the following which enables signing of the AuditRecordData table as well as verification of the log entries queried using for instance the CLI or GUI:

databaseprotection.enablesign.AuditRecordData = true
databaseprotection.enableverify.AuditRecordData = true

Configure a key-pair to use for signing and verification of the log with something similar to this:

databaseprotection.keyid = 400
databaseprotection.keyid.0 = 400
databaseprotection.keylabel.0 = dbProtKey
databaseprotection.classname.0 = org.cesecore.keys.token.PKCS11CryptoToken
databaseprotection.properties.0 = sharedLibrary=/opt/utimaco/Software/PKCS11/lib/Linux-x86-64/libcs2_pkcs11.so, slotLabelType=SLOT_NUMBER, slotLabelValue=1
databaseprotection.data.0 =
databaseprotection.tokenpin.0 = userpin1
databaseprotection.version.0 = 2

Note: each SignServer node writing to the audit log needs to use different node IDs. By default the hostname is used. If multiple instances are running from the same host set the node ID manually in conf/cesecore.properties as cluster.nodeid.

If enableverify is set to true, all individual log entries that are displayed using CLI, GUI or over web services are verified at the server side and in case of inconsistent signatures an error message is displayed. This verification will not discover missing log entries. To verify the complete log for all nodes as well as detect gaps in the sequence numbering, run the Database CLI.

AuditRecordData table

The exact database table structure is described in the SQL scripts available under doc/sql-scripts/.

Friendly Name Table Name Description
Time timeStamp

Time stamp (number of milliseconds since January 1, 1970, 00:00:00 GMT). Example:

1359550503607
Outcome eventStatus

Status/result of the operation performed. Can be:

  • SUCCESS
  • FAILURE
  • VOID
Event eventType

The event. Some examples:

  • SIGNSERVER_STARTUP
  • SET_GLOBAL_PROPERTY
  • SET_WORKER_CONFIG
  • KEYGEN
  • PROCESS
Module module

The source module of the event. Some examples:

  • SERVICE
  • GLOBAL_CONFIG
  • WORKER_CONFIG
  • KEY_MANAGEMENT
  • WORKER
  • STATUS_REPOSITORY
Service service

The service performing the operation. Some examples:

  • CORE
  • SIGNSERVER
  • EJBCA
Admin Subject authToken

Information about which administrator performed the operation.

Subject DN from the administrator's certificate if the operation was performed over web services, "CLI User" if the EJB remote interface was used, the name of the service if it was an internal operation or "Client User" if the request came from a client.

Some examples:

C=SE, O=My Organization, CN=Admin 1
CLI User
StartServicesServlet.init
Client User
Admin Serial Number searchDetail1

Information about which administrator performed the operation.

Certificate serial number for the administrator performing the operation (if available). Example:

4a3442e98e3ce428
Admin Issuer customId

Information about which administrator performed the operation.

Issuer DN from the administrator's certificate (if available). Example:

C=SE, O=My Organization, CN=AdminCA1
Worker ID searchDetail2

ID of worker involved in the operation (if any). Example:

71
Node nodeId

ID of the node (typically the hostname if not explicitly specified). Example:

dsstsa1.example.com
Details additionalDetails

Additional key-value pairs with information about the operation encoded with Java XML serialization. Example:

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.6.0_24" class="java.beans.XMLDecoder">
 <object class="org.cesecore.util.Base64PutHashMap">
  <void method="put">
   <string>GLOBALCONFIG_PROPERTY</string>
   <string>GLOB.WORKER1.CLASSPATH</string>
  </void>
  <void method="put">
   <string>GLOBALCONFIG_VALUE</string>
   <string>org.signserver.module.xmlsigner.XMLSigner</string>
  </void>
 </object>
</java>
                                    
Sequence Number sequenceNumber

Sequence number of the log entry. Should be unique and sequential per node.

Row Protection rowProtection

Contains information about wich key-pair and signature algorithm that has been used and the actual signature value (if the row is signed). Example:

1:2:400:079b6c2d89671702077b1802ff221cd7c6d71804ea3771b7d5f7cd1...

Debug Log

The debug log is just the normal log that can be useful for finding out configuration problems etc.

Configure Log4j for Audit logs

For JBoss you can configure JBOSS_HOME/server/default/conf/jboss-log4j.xml to put the audit logs in a separate file.

<appender name="SIGNSERVER_AUDIT" class="org.jboss.logging.appender.DailyRollingFileAppender">
    <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
    <param name="File" value="${jboss.server.log.dir}/signserver_audit.log" />
    <param name="Append" value="true" />

    <!-- Rollover at midnight each day -->
    <param name="DatePattern" value="'.'yyyy-MM-dd" />
    <layout class="org.apache.log4j.PatternLayout">
        <param name="ConversionPattern" value="%d{ISO8601} %-5p [%c{1}] %m%n" />
    </layout>
</appender>

<category name="org.signserver.server.log.SignServerLog4jDevice">
    <appender-ref ref="SIGNSERVER_AUDIT"/>
</category>
<category name="org.signserver.server.log.IWorkerLogger">
    <appender-ref ref="SIGNSERVER_AUDIT"/>
</category>

For GlassFish a similar setup is already configured in SIGNSERVER_HOME/modules/SignServer-Module-Log4j/src/log4j.properties.

For JBoss 7/EAP6 the following can be edited in JBOSS_HOME/standalone/configuration/standalone.xml:

<subsystem xmlns="urn:jboss:domain:logging:1.2">
    ...
    <periodic-rotating-file-handler name="SignServer" autoflush="true">
        <formatter>
            <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
        </formatter>
        <file relative-to="jboss.server.log.dir" path="signserver.log"/>
        <suffix value=".yyyy-MM-dd"/>
        <append value="true"/>
    </periodic-rotating-file-handler>
    <periodic-rotating-file-handler name="SignServer_audit" autoflush="true">
        <formatter>
            <pattern-formatter pattern="%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"/>
        </formatter>
        <file relative-to="jboss.server.log.dir" path="signserver_audit.log"/>
        <suffix value=".yyyy-MM-dd"/>
        <append value="true"/>
    </periodic-rotating-file-handler>

    <logger category="org.signserver">
        <level name="DEBUG"/>
        <handlers>
            <handler name="SignServer"/>
        </handlers>
    </logger>
    <logger category="org.ejbca">
        <level name="DEBUG"/>
        <handlers>
            <handler name="SignServer"/>
        </handlers>
    </logger>
    <logger category="org.cesecore">
        <level name="DEBUG"/>
        <handlers>
            <handler name="SignServer"/>
        </handlers>
    </logger>
    <logger category="org.signserver.server.log.SignServerLog4jDevice">
        <handlers>
            <handler name="SignServer_audit"/>
        </handlers>
    </logger>
    <logger category="org.signserver.server.log.ISystemLogger">
        <handlers>
            <handler name="SignServer_audit"/>
        </handlers>
    </logger>
    ...
</subsystem>

Status Repository Logging

By default the Status Repository produces a log entry for every update. This can be disabled or changed in the configuration so that only changes are logged. See the property statusrepository.log in signserver_deploy.properties.sample.

Database Command Line Interface

The SignServer DB CLI can be run against a database. Currently it only supports verifying the audit log.

Building

The DB CLI is built if the property databasecli.enabled=true is specified in signserver_deploy.properties. It can also be built using:

$ bin/ant -f modules/SignServer-DatabaseCLI/build.xml dist-module

Configuring

Configure the dbcli.* properties in conf/signserver_cli.properties.

Running

There is start-up script available under bin. You might have specify a classpath containing the JDBC connectors for the specific database type. Example:

$ OPTIONAL_CLASSPATH=/usr/share/java/mysql-connector-java.jar bin/signserver-db audit verifylog

SignServer without Database

Since SignServer 3.2.3 it is sometimes possible to operate SignServer without a database management system and instead rely on SignServer to manage persistence using local files.

Notice that all features of SignServer is not supported without having a database and that the performance and scalability characteristics might be different. Currently archiving to database is not supported.

To increase throughput it is recommended to disable the key usage counter as every request would otherwise have to lock and update that file. See the property DISABLEKEYUSAGECOUNTER in the section Limiting the number of signatures.

Upgrading to a later version should normally be handled automagically during the first startup but please read the UPGRADE.txt document and create a backup of the file-based database files before attempting to run a later version.

Configuration

In signserver_deploy.properties, set database.type to "nodb".

database.type=nodb

Set the location for the local file-based database.

database.nodb.location=/path/to/filedb

Where the path is some location where SignServer can write files. The default value is empty. If an relative path is used it is most likely relative to the application server's working directory.

This directory should either point to an existing SignServer file database or be completely empty. If the directory is empty, SignServer will create the initial database structure at startup.

Structure of data

The file based database uses a number of files in the specified directory. Read/write synchronization is handled internally in the application and it is thus not support to do manual changes to the files while the application server is running. It is normally also not supported to have multiple application servers running with SignServer using the same database directory.

Migrating to/from database

The recommended way of migrating either to or from an other database management system without setting up all worker configuration from scratch is do use admin command "dumpproperties" to dump the current configuration to a file and then on the new system use the "setproperties" followed by the reload command for every worker id.

Notice: The dumpproperties command will not include the list of authorized clients so those will have to be setup again in the new system. Check with the admin command "listauthorizedclients" if you have any of those.

SignServer TimeMonitor

Note
The SignServer TimeMonitor is an Enterprise Edition feature.

This is an external application that can be used together with the StatusReadingLocalComputerTimeSource for monitoring of the local time and informing SignServer about its state.

In SignServer, either a StatusPropertiesWorker or a TimeMonitorManager is configured for accepting the status updates. The later also supports dynamic configuration of the TimeMonitor.

For details see the TimeMonitor manual (only available in Enterprise Edition).

Installation Packages

See res/install/debian/README.building for instructions for creating Debian packages for SignServer.

Contributed Howtos

Contributed howtos and installation guides can be found under doc/howtos.

  • Installation guide for SignServer 3.1 and RHEL5.3 / CentOS 5.3 by Christophe Sahut called signserver31-rhel5.txt. Available in the SignServer 3.x releases.
  • Installation package for SignServer 3.2.4 and Debian 6.0 contributed by Antoine Louiset called signserver32-debian6-by-antoine-louiset.zip. Available in the SignServer 3.x releases.

References