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

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:

XML

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:

XML

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:

XML

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: XML `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: XML `C=SE, O=My Organization, CN=Admin 1` If the EJB remote interface was used, subject DN from the CLI User: XML `CLI User` If it was an internal operation, subject DN from the name of the service. XML `StartServicesServlet.init` If the request came from a client, subject DN from Client User. XML `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: XML `4a3442e98e3ce428`
Admin Issuer	customId	Information about which administrator performed the operation. Issuer DN from the administrator's certificate (if available). Example: XML `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: XML `dsstsa1.example.com`
Details	additionalDetails	Additional key-value pairs with information about the operation encoded with Java XML serialization. Example: XML `<?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: XML `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:

CODE

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