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

Signed log

enterprise

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).

Also, set the following to enable signing of the AuditRecordData table as well as verification of the log entries queried using for instance the CLII:

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

If enableverify is set to true, all individual log entries that are displayed using CLI 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.

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 signing and/or verification is enabled, one or more crypto tokens need to be configured.

PKCS#11 Example using Default Provider

It is recommended to use the same type of PKCS#11 provider for database protection as the other signers are also using. If the signers are using the PKCS11CryptoToken the below crypto token called org.cesecore.keys.token.PKCS11CryptoToken should be used:

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

PKCS#11 Example using P11NG Provider

It is recommended to use the same type of PKCS#11 provider for database protection as the other signers are also using. If the signers are using the P11NGCryptoToken the below crypto token called org.signserver.p11ng.common.cryptotoken.P11NGDatabaseProtectionCryptoToken should be used:

databaseprotection.keyid = 400
databaseprotection.keyid.0 = 400
databaseprotection.keylabel.0 = testkey0
databaseprotection.classname.0 = org.signserver.p11ng.common.cryptotoken.P11NGDatabaseProtectionCryptoToken
databaseprotection.properties.0 = SHAREDLIBRARYNAME=Utimaco, SLOTLABELTYPE=SLOT_NUMBER, SLOTLABELVALUE=1, pin=userpin1
databaseprotection.data.0 =
databaseprotection.tokenpin.0 = userpin1
databaseprotection.version.0 = 2
databaseprotection.sigalg.2 = SHA256WithRSA

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.

If the operation was performed over web services, subject DN from the administrator's certificate:

C=SE, O=My Organization, CN=Admin 1

If the EJB remote interface was used, subject DN from the CLI User:

CLI User

If it was an internal operation, subject DN from the name of the service.

StartServicesServlet.init

If the request came from a client, subject DN from Client User.

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 key-pair and signature algorithm used, and the actual signature value (if the row is signed).

Example:

1:2:400:079b6c2d89671702077b1802ff221cd7c6d71804ea3771b7d5f7cd1...

Alternative Low-Performance Integrity Protected Log Device

By default, the IntegrityProtectedLogDevice is used for audit logging to the database. However, there are situations where gaps may occur in the sequence number, for example if the database or HSM is unavailable when the logging is being performed. Normally when this happens, the times of the missing sequence numbers can be correlated to error messages in other logs for database or HSM failures. The operations that the missing sequence numbers represent were not executed since the logging that failed always is performed first. Thus, no log rows are actually missing, it is the counter that has incorrect values.

To solve the above issue, an alternative IntegrityProtectedLogDevice can be used that works sequentially and only logs one row at the time and only proceeds with the next one after the first succeeds. The disadvantage is significant less performance.

To configure the alternative device, edit the conf/cesecore.properties file and comment out the default IntegrityProtectedLogDevice and instead set the SequencialIntegrityProtectedLogDevice according to the following example:

#securityeventsaudit.implementation.1=org.cesecore.audit.impl.integrityprotected.IntegrityProtectedDevice
securityeventsaudit.implementation.1=org.signserver.server.integrityprotected.SequencialIntegrityProtectedDevice

Note that SignServer must be redeployed for the changes in conf/cesecore.properties to take effect.