EJBCA Audit Logging

This covers information on EJBCA Audit Logging in the following sections:


EJBCA produces logging of the types Security Audit Log and System Log.

The Security Audit Log complements the System Log and both tools are used to keep a record of activities performed but with different objectives. The System Log logs events interesting to monitor for System Administrators, while the main audience for a Security Audit Log is auditors.

Security Audit Log

The Security Audit Log specifies in detail what it logs, and does not log any other events. Examples of important events logged by the Security Audit Log are: "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, for example invalid requests that the system rejects or downloading a CRL, because the PKI system did not perform any important auditable event.

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 interested in what the system did not do. The Security Audit Log is designed to fulfill audit logging requirements for Common Criteria certification (Certificate Issuing and Management Components Protection Profile), as well as ETSI/CWA and WebTrust audits.

System Log

The System Log logs all events that are interesting to monitor, such as rejecting invalid requests, reading profiles etc. The System Log can log with different log levels to provide extra information of non security related events.

The System Log uses the Log4J logging framework with multiple, configurable log levels:

Log Level



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


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


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


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


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


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.

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 according to the following:

  • Only store Audit Log in database (and not use log files)

  • Store Audit Log in database and in log files

  • Store Audit Log only in log files (do not use database)

Each of the options have their benefits, and the logging can therefore be configured to meet most organization specific requirements.

Working with Logs

Log Locations

The Security Audit Log can be logged to two different places, controlled by configuration:

  • The EJBCA database

  • Application server log, through Log4j. Can be configured to be sent to a Syslog server.

Info and Debug logs are only sent to the Application Server Log.

Log Files

JBoss Server Log

The application server log in JBoss can be configured flexibly:

  • Log levels, also for different parts of the application

  • Log files, different parts logging to different files

  • Rotation and archival, size and time based log file rotation, limiting archived size

  • Shipping of logs to external system using custom Log4J appenders.

For more information and application server log configuration examples, see Logging.


Detailed information how to work with log files on the Appliance, and how they are interpreted, can be found in a separate document: "MONT-1774 Documentation of log messages for audit-relevant events in PKI Appliance".

Log Monitoring

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

Example where there is a error to initialize an (this is a specific example and not applicable to all HSMs) 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

An error event like this could trigger an operator to take a look at the system to gauge what is the actual issue, for example it may be due to a network issue.

See the following sections for more information on Security Audit Events and Integrity Protected Security Audit Log.