A PKI system has the following types of logs:

  • Security Audit Log: Used for PKI auditors to audit important security PKI events that the system performs.
  • System Log: Used to monitor daily operations in the system, debug and track down errors etc.
  • Transaction Log: Used for accounting of specific functions, mainly validation (OCSP).

The Security Audit Log specifies in detail what it logs and does not log any other events. The Security Audit log logs important events such as "Certificate issued", "Certificate Profile edited", "Administrator accessed resource". One of the most important aspects to consider is that the Security Audit log does not log things that do not happen. Things that do not happen are for example invalid requests that the system rejects, because the PKI system did not perform any important auditable event.

The System Log logs all events that are interesting to monitor, such as rejecting invalid requests, reading profiles etc.

The main purpose of the Security Audit Log is to provide information to an auditor, and the auditor wants to know what the system has done, what certificates were issued etc, but is not so interested in what the system did not do.

The Security Audit Log is stored in the database and the System Log is stored in log files. By default the System Log also contains the Security Audit Log, but this can be configured.

For more information on the OCSP Transaction Log, see Audit and Account Logging and for information on the WS Transaction Log, see Web Service Interface.

Log Devices implemented in EJBCA

IntegrityProtectedDevice 

ENTERPRISE  This is an EJBCA Enterprise feature.

See main page: Integrity Protected Log Device. 

The integrity protected log device stores audit record in the AuditRecordData table in the database. For more information on Database Integrity Protection, see EJBCA Security.

Log4JLogDevice 

Appends the information from the official event to the console or file. This is the same target where all the other info/debug output is sent to. There is no protection from alteration and events sent to this device cannot be fetched back to EJBCA for display in the Admin GUI.

Security Audit Log

See main page: Audit Log Overview

Besides the system log (see below), EJBCA provides a powerful audit log to specifically log all steps of the enrollment process into the database, for use of an auditor at a later time. 

System Log

The system log is logged using Log4J and has several configurable log levels:

Log Level

Description

FATAL

Catastrophic events logged by the JVM or application server. The system is most likely in a very bad and/or unusable state.

ERROR

Errors that should cause the IT staff to look into the system. It could be fatal so the system stopped working.

WARNING

Warnings about misconfiguration. The system is still working, but functionality could be degraded.

INFO

Informational messages that are interesting for monitoring purposes and statistic purposes. This is normally the default level.

DEBUG

Debug information useful to see details of what is happening in the system.

TRACE

Trace information that can be useful to track down bugs or small misconfigurations. Very rich output showing detailed trace of what happens in the system code.


System log configuration is dependent on the application server used, see Application Servers. It is recommended to configure logging in the application server, i.e. JBoss.

In JBoss EAP7/WildFly10 or later, you can configure the logging section of standalone.xml.

The following displays an example of a configuration specifying a more advanced logger, logging of EJBCA events to a separate ejbca.log log file that rotates by size every 32MB, and keeping maximum 31 rotated log files:

<subsystem xmlns="urn:jboss:domain:logging:3.0">
    <console-handler name="CONSOLE">
        <level name="INFO"/>
        <formatter>
            <named-formatter name="COLOR-PATTERN"/>
        </formatter>
    </console-handler>
    <periodic-rotating-file-handler name="FILE" autoflush="true">
        <formatter>
            <named-formatter name="PATTERN"/>
        </formatter>
        <file relative-to="jboss.server.log.dir" path="server.log"/>
        <suffix value=".yyyy-MM-dd"/>
        <append value="true"/>
    </periodic-rotating-file-handler>
    <size-rotating-file-handler name="EJBCAFILE" 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="ejbca.log"/>
        <rotate-size value="32M"/>
        <max-backup-index value="31"/>
        <append value="true"/>
    </size-rotating-file-handler>
    <logger category="com.arjuna">
        <level name="WARN"/>
    </logger>
    <logger category="org.jboss.as.config">
        <level name="DEBUG"/>
    </logger>
    <logger category="sun.rmi">
        <level name="WARN"/>
    </logger>
    <logger category="org.ejbca">
        <level name="DEBUG"/>
        <handlers>
            <handler name="EJBCAFILE"/>
        </handlers>
    </logger>
    <logger category="org.cesecore">
        <level name="DEBUG"/>
        <handlers>
            <handler name="EJBCAFILE"/>
        </handlers>
    </logger>
    <root-logger>
        <level name="INFO"/>
        <handlers>
            <handler name="CONSOLE"/>
            <handler name="FILE"/>
        </handlers>
    </root-logger>
    <formatter name="PATTERN">
        <pattern-formatter pattern="%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
    </formatter>
    <formatter name="COLOR-PATTERN">
        <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
    </formatter>
</subsystem>
XML

Debug Logging

In JBoss you can easily enable and disable DEBUG logging and switch back to INFO logging at runtime. To configure the DEBUG log level the first time, run the following JBoss/WildFly CLI commands.

At first you need to create the log modules in JBoss/WildFly. Log modules are java packages and EJBCA uses two major java packages. This only need to be done once, when you have run these two commands, you can then set log level back and forth on these log modules.

/subsystem=logging/logger=org.ejbca:add
/subsystem=logging/logger=org.cesecore:add
/subsystem=logging/logger=com.keyfactor:add
CODE

When the modules are there (technically it creates entries in JBoss/WildFly standalone.xml), you can set log level to DEBUG to these two modules.

/subsystem=logging/logger=org.ejbca:write-attribute(name=level, value=DEBUG)
/subsystem=logging/logger=org.cesecore:write-attribute(name=level, value=DEBUG)
/subsystem=logging/logger=com.keyfactor:write-attribute(name=level, value=DEBUG)
CODE

You can later switch between DEBUG and INFO logging at runtime, for example to specify INFO logging (normal production level):

/subsystem=logging/logger=org.ejbca:write-attribute(name=level, value=INFO)
/subsystem=logging/logger=org.cesecore:write-attribute(name=level, value=INFO) 
/subsystem=logging/logger=com.keyfactor:write-attribute(name=level, value=INFO)
CODE

Log level on specific sub modules

If you do not want to enable debug logging for all of EJBCA, you can also do so for specific sub modules of EJBCA. For example, to enable debug logging for Certificate Transparency run the following command to add the sub modules to JBoss/WildFly:

/subsystem=logging/logger=org.cesecore.certificates.certificatetransparency:add
CODE

You can then enable debug logging for CT only with:

/subsystem=logging/logger=org.cesecore.certificates.certificatetransparency:write-attribute(name=level, value=DEBUG)
CODE

Note that after adding that sub module, this exists in addition to the general packages you may have created above, and can be controlled individually. You can therefore remove the sub module form the log system again completely with:

/subsystem=logging/logger=org.cesecore.certificates.certificatetransparency:remove
CODE

Logging to Syslog

You can configure JBoss/WildFly to log to syslog and there are different configurations you can use.

The following shows an example for JBoss EAP7/WildFly 10+ to log to a remote syslog server, using syslog on TCP port 514. You can tweak the settings to suit different syslog servers.

<custom-handler name="SYSLOGTCP" class="org.jboss.logmanager.handlers.SyslogHandler" module="org.jboss.logmanager">
    <level name="INFO"/>
    <encoding value="ISO-8859-1"/>
    <formatter>
        <pattern-formatter pattern="%-5p [%c] (%t) %s%E%n"/>
    </formatter>
    <properties>
      <property name="appName" value="EJBCA"/>
      <property name="facility" value="LOCAL_USE_5"/>
      <property name="serverHostname" value="syslogserver-at.mydomain.com"/>
      <property name="hostname" value="-"/>
      <property name="port" value="514"/>
      <property name="syslogType" value="RFC5424"/>
      <property name="protocol" value="TCP"/>
      <property name="messageDelimiter" value="-"/>
      <property name="useMessageDelimiter" value="true"/>
    </properties>
</custom-handler>
CODE

System Log Signing

System logs can be signed as they are being rotated. For more information, see External Log Signing in EJBCA Security.

Log Monitoring

When monitoring logs from EJBCA, the common trigger to monitor is ERROR events in the System Log.

For example, if there is an error to initialize an HSM during startup:

10:46:53,099 ERROR [org.cesecore.keys.token.p11.Pkcs11Wrapper] (default task-9) Wrong arguments were passed to sun.security.pkcs11.wrapper.PKCS11.CK_C_INITIALIZE_ARGS.getInstance threw an exception
BASH

An error event like this should trigger an operator to inspect the system to investigate the issue.

Integrating with a SIEM

You can integrate EJBCA with a Security Information and Event Management (SIEM) software by sending logs to it.

Graylog

Graylog can consume syslog, and other log formats. For more information, see Integrating EJBCA with Graylog

Related Content: Audit Log Overview

For more information on the EJBCA Audit Log, specifically logging all steps of the enrollment process into the database, for use of an auditor at a later time, see Audit Log Overview.