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

Signed log

ENTERPRISE  This is a SignServer Enterprise 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).

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
XML

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
XML

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
XML

AuditRecordData table

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

Friendly Name
Table Name
Description
TimetimeStamp

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

Example:

1359550503607
XML
OutcomeeventStatus

Status/result of the operation performed. Can be:

  • SUCCESS
  • FAILURE
  • VOID
EventeventType

The event. Some examples:

  • SIGNSERVER_STARTUP
  • SET_GLOBAL_PROPERTY
  • SET_WORKER_CONFIG
  • KEYGEN
  • PROCESS
Modulemodule

The source module of the event. Some examples:

  • SERVICE
  • GLOBAL_CONFIG
  • WORKER_CONFIG
  • KEY_MANAGEMENT
  • WORKER
  • STATUS_REPOSITORY
Serviceservice

The service performing the operation. Some examples:

  • CORE
  • SIGNSERVER
  • EJBCA
Admin SubjectauthToken

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
XML

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

CLI User
XML

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

StartServicesServlet.init
XML

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

Client User
XML
Admin Serial NumbersearchDetail1

Information about which administrator performed the operation.

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

Example:

4a3442e98e3ce428
XML
Admin IssuercustomId

Information about which administrator performed the operation.

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

Example:

C=SE, O=My Organization, CN=AdminCA1
XML
Worker IDsearchDetail2

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

Example:

71
NodenodeId

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

Example:

dsstsa1.example.com
XML
DetailsadditionalDetails

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>
XML
Sequence NumbersequenceNumber

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

Row ProtectionrowProtection

Contains information about key-pair and signature algorithm used, and the actual signature value (if the row is signed).

Example:

1:2:400:079b6c2d89671702077b1802ff221cd7c6d71804ea3771b7d5f7cd1...
XML

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
CODE

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