4. Logs¶

TrustView and the components around it each write their own logs. This page describes where to find them, how to get more detail in them, and how to send them to our Support.

Tip

Most problems with a single certificate, SSL endpoint, automation task or integration can be seen directly in TrustView, in the Event log on the detail page of the object, without opening any log file.

4.1. Overview¶

Component	Where the logs are (default)	Described in
TrustView	`C:\Program Files\TrustView-Embedded\tomcat\logs`	TrustView log file
Database performance (optional)	Same folder as the TrustView log file	Add database performance logging
Login events for a SIEM (optional)	Same folder as the TrustView log file	Sending login events to a SIEM
Scan agent	The agent’s console or service log	Scan agent logging
ADCS module	`logs` folder under `Issue` and `Retrieve`	ADCS module logs
Microsoft DNS integration	`logs` folder of the Microsoft DNS service	Microsoft DNS integration logs
simple-acme	`C:\ProgramData\simple-acme`	ACME client logs
Certbot	`/var/log/letsencrypt/`	ACME client logs
A single object in TrustView	`Event log` on the detail page of the object	Event log in TrustView

4.2. TrustView log file¶

4.3. Add database performance logging¶

4.4. Additional logging for troubleshooting¶

Click here for detailed steps

Beyond the database performance example above, any part of TrustView can be logged in more detail the same way, by adding extra <logger> entries (or logger(...) lines, for logback.groovy) to the same logback.xml/logback.groovy file - no extra installation is required.

Important

A freshly installed Embedded version only ships with the STDOUT and FILE appenders enabled by default. Everything below is something you add on top of that default, not something already active out of the box.

Add a <logger> entry for the relevant class or package name, at the suggested level, for example:

Example of raising the log level for a specific class in logback.xml¶

<logger name="certificate.management.tool.AgentConnectionController" level="INFO" additivity="false">
    <appender-ref ref="FILE"/>
</logger>

or, for logback.groovy:

logger("certificate.management.tool.AgentConnectionController", INFO, ['FILE'], false)

The following classes and packages are useful starting points for specific troubleshooting scenarios:

Login/authentication issues (AD, SSO or local accounts) - org.springframework.security at TRACE, or more narrowly org.springframework.security.authentication.dao at TRACE for database/LDAP-backed logins specifically, and certificate.management.tool.LoginController at TRACE for the login flow itself.

Database transaction issues (beyond slow queries, which the performance logging above already covers) - org.hibernate.engine.transaction.internal.TransactionImpl at TRACE.

Monitored-object scanning in general (certificates, CRLs, domains and the other monitored object types all share this base class) - certificate.management.tool.AbstractMonitoredObjectService at TRACE.

SSL endpoint scan or handshake failures - certificate.management.ssl.scanner.testscripts.SslHandshakeTestScript at INFO.

AD-based SSL endpoint discovery failing (see also the related troubleshooting entry in Certificate Discovery) - certificate.management.ssl.scanner.ActiveDirectoryHostnameExtractionTestscriptService at INFO.

Automation agent connection or activation problems - certificate.management.tool.AgentConnectionController at INFO, and certificate.management.tool.AgentConnectionActivationTemplateService at TRACE.

ADCS connection or issuance problems - certificate.management.tool.api.AdcsConnectionController at TRACE.

SCEP enrollment issues for automation agents - org.jscep at DEBUG.

Scheduled scan or automation timing issues - org.quartz at TRACE.

Broad, whole-application debugging (noisy - use only as a last resort) - certificate.management.tool at DEBUG.

Note

As with the database performance example above, a change to logback.xml is picked up automatically shortly after the file is saved (by default within about a minute), without restarting the Embedded TrustView service; a change to logback.groovy requires a restart.

Tip

The trustview-scanagent component (an external Scan agent, see Scan Agents) uses a different, simpler mechanism for its own logging - see Scan agent logging below.

4.5. Shipping logs to an external logging system¶

Click here for detailed steps

TrustView’s logs can be delivered to an external logging or monitoring system in a few different ways, depending on what that system is and how it is normally fed.

Tailing the log file (simplest)

The lowest-risk option, requiring no change to TrustView at all, is to point the external system’s own collection agent at the log file described under TrustView log file above and have it tail that file directly. This is how most log-management platforms are normally fed - for example Splunk’s Universal Forwarder, a Graylog Sidecar, or Filebeat for an Elastic/ELK stack - and it requires no restart and no change to logback.xml/logback.groovy.

To send only the login events to a SIEM, see Sending login events to a SIEM below.

Syslog

Logback (which TrustView uses) includes a syslog appender as standard, so no extra installation is required. Add it to logback.xml:

Example syslog appender in logback.xml¶

<appender name="SYSLOG" class="ch.qos.logback.classic.net.SyslogAppender">
    <syslogHost>syslog.example.com</syslogHost>
    <port>514</port>
    <facility>LOCAL0</facility>
    <suffixPattern>TrustView: %logger{36} - %msg</suffixPattern>
</appender>

<root level="INFO">
    <appender-ref ref="STDOUT" />
    <appender-ref ref="FILE" />
    <appender-ref ref="SYSLOG" />
</root>

or, for logback.groovy:

appender("SYSLOG", SyslogAppender) {
    syslogHost = "syslog.example.com"
    port = 514
    facility = "LOCAL0"
    suffixPattern = "TrustView: %logger{36} - %msg"
}
root(INFO, ['FILE', 'SYSLOG'])

Important

This built-in appender sends over plain UDP (RFC 3164) - it is not encrypted, and individual messages can be dropped under heavy load, which is normal for syslog. It is nonetheless the most broadly compatible option, since nearly every SIEM or log-management platform (Splunk, Graylog, a self-hosted ELK/Logstash stack via its syslog input, QRadar, etc.) accepts a syslog source.

E-mail alert on error

A related but different use case - getting notified immediately when something goes wrong, rather than aggregating every log line - can be done with Logback’s built-in SMTP appender, which also needs no extra installation:

Example e-mail alert appender in logback.xml¶

<appender name="EMAIL_ALERT" class="ch.qos.logback.classic.net.SMTPAppender">
    <smtpHost>smtp.company.com</smtpHost>
    <to>oncall@company.com</to>
    <from>trustview@company.com</from>
    <subject>TrustView error: %logger{20} - %msg</subject>
    <layout class="ch.qos.logback.classic.PatternLayout">
        <pattern>%d{yyyy-MM-dd HH:mm:ss} %-5level %logger{36} - %msg%n</pattern>
    </layout>
</appender>

<root level="INFO">
    <appender-ref ref="STDOUT" />
    <appender-ref ref="FILE" />
    <appender-ref ref="EMAIL_ALERT" />
</root>

Note

By default, the SMTP appender only sends a mail when an ERROR-level (or higher) event occurs - lower-level events are buffered as surrounding context inside that same mail, rather than each triggering a mail of their own.

Structured (JSON) shipping - Logstash/Graylog

For structured, field-based ingestion - for example feeding Logstash/ELK directly as JSON, or Graylog’s native GELF format - Logback needs an additional, third-party encoder library, which is not bundled with TrustView and has not been tested by Cryptomathic. Adding one works the same way as adding a JDBC driver: place the library’s .jar file (and any of its own dependencies) in C:\Program Files\TrustView-Embedded\tomcat\lib and it is picked up automatically on the next start.

Important

This option is shown for reference only - contact our Support before adding a third-party logging library to a production installation.

As an example, the commonly used logstash-logback-encoder library adds a Logstash-specific appender:

Example - requires the logstash-logback-encoder library (not bundled)¶

<appender name="LOGSTASH" class="net.logstash.logback.appender.LogstashTcpSocketAppender">
    <destination>logstash.example.com:5000</destination>
    <encoder class="net.logstash.logback.encoder.LogstashEncoder" />
</appender>

A Graylog-specific GELF appender (for example from a third-party GELF logging library) follows the same pattern, sending its own structured format instead of plain text.

Tip

The trustview-scanagent component (an external Scan agent, see Scan Agents) writes its own, separate log output and is not covered by the logback.xml/logback.groovy files described here - see Scan agent logging below.

4.6. Sending login events to a SIEM¶

Security teams often want TrustView’s login events in their SIEM, such as Splunk, Microsoft Sentinel or QRadar. TrustView writes these events to the TrustView log file, at the INFO level:

Successful logins, including logins with two-factor authentication
Failed logins, with the reason, for example a wrong password
Authentication with API keys

All of them come from the logger certificate.management.tool.AuthenticationEventListener, for example:

Examples of login events in the TrustView log file¶

 User jdoe logged in
 Username jdoe got - Bad credentials from ...

The login events can be sent to a SIEM with any of the methods under Shipping logs to an external logging system above. If the SIEM should only receive the login events, and not the rest of the TrustView log, write them to a separate log file as well, and point the SIEM’s collection agent at that file:

Click here for detailed steps

Step 1a (logback.xml)

Add an appender for the separate log file and a logger for the login events to logback.xml, above the <root> element. On the Embedded version of TrustView, the file is typically found here:

C:\Program Files\TrustView-Embedded\tomcat\conf\logback.xml

Example of writing the login events to a separate trustview-audit log file¶

<appender name="AUDIT" class="ch.qos.logback.core.rolling.RollingFileAppender">
    <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
        <fileNamePattern>${LOG_ROOT}/trustview-audit-%d{yyyy-MM-dd}.log</fileNamePattern>
        <maxHistory>90</maxHistory>
    </rollingPolicy>
    <encoder>
        <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger{36} - %msg%n</pattern>
    </encoder>
</appender>

<logger name="certificate.management.tool.AuthenticationEventListener" level="INFO" additivity="false">
    <appender-ref ref="FILE"/>
    <appender-ref ref="AUDIT"/>
</logger>

The login events are then written both to the normal TrustView log file (FILE) and to trustview-audit-yyyy-mm-dd.log in the same folder, which is kept for 90 days. The pattern is kept simple, without colour codes, so it is easy for a SIEM to parse.

Note

The change to logback.xml is picked up automatically shortly after the file is saved, without restarting TrustView.

Step 1b (logback.groovy)

If you are using the groovy-based logback configuration (logback.groovy), add the following instead:

appender("AUDIT", RollingFileAppender) {
    rollingPolicy(TimeBasedRollingPolicy) {
        fileNamePattern = "${targetDir}/trustview-audit-%d{yyyy-MM-dd}.log"
        maxHistory = 90
    }
    encoder(PatternLayoutEncoder) {
        pattern = "%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger{36} - %msg%n"
    }
}

logger("certificate.management.tool.AuthenticationEventListener", INFO, ['FILE', 'AUDIT'], false)

Important

When using logback.groovy, the TrustView service must be restarted after the changes have been saved.

Step 2 (SIEM)

Point the SIEM’s collection agent at the new trustview-audit-*.log files. As an example, with Splunk’s Universal Forwarder installed on the TrustView server, add a monitor to its inputs.conf:

Example of a Splunk Universal Forwarder input for the TrustView login events¶

[monitor://C:\Program Files\TrustView-Embedded\tomcat\logs\trustview-audit-*.log]
sourcetype = trustview:audit
index = security
disabled = false

Change index to the index your security team uses. Other SIEMs work the same way with their own agent, for example the Azure Monitor Agent for Microsoft Sentinel, or Elastic Agent. Alternatively, add a SYSLOG appender (see Shipping logs to an external logging system) to the logger instead of, or as well as, AUDIT.

Tip

Other events, such as orders, issued and revoked certificates and certificate checkouts, are shown in the Event log of each object in TrustView. To get an e-mail every time a user logs in, see Get an e-mail notification on every login.

4.7. Scan agent logging¶

The external Scan agent writes its own, separate log output to its console/service log - it does not use TrustView’s own logback.xml/logback.groovy files described under Additional logging for troubleshooting above, since it runs as its own process.

Its log level can be raised in two ways, without editing the agent’s own packaged configuration file:

Set the root.level (and, for the scheduler specifically, quartz.level) system property when starting the agent, for example DEBUG instead of the default INFO.

Drop a logconfig.xml file next to the agent’s own configuration file - if present, it is automatically included and can define additional loggers/appenders the same way as described for the main TrustView application.

4.8. ADCS module logs¶

The Issue and Retrieve services of the ADCS module each write their own log files, in a logs folder next to the service, for example:

Default location of the ADCS module log files¶

 C:\Program Files\TrustView-ADCS\Issue\logs
 C:\Program Files\TrustView-ADCS\Retrieve\logs

By default, the log files are named after the service, for example TrustView-ADCS-Issue-Service, followed by .out.log (the output of the service), .err.log (errors) or .wrapper.log (starting and stopping the service). A log file is rolled over at 10 MB, and up to 8 files are kept.

The ADCS module logs at the info level by default. To get more detail, for example to see which CAs and templates are found, raise the log level:

Open TrustView-ADCS-Issue-Service.xml (or TrustView-ADCS-Retrieve-Service.xml) in the folder of the service.
In the <arguments> line, change -loglevel info to -loglevel debug, or to -loglevel trace for the most detail.
Save the file and restart the TrustView ADCS Issue Service (or TrustView ADCS Retrieve Service) Windows service.

Example of the arguments line with debug logging enabled¶

 <arguments>-ExecutionPolicy Bypass -NoLogo -NoProfile -NonInteractive -WindowStyle Hidden -File "%BASE%\pkiissue.ps1" -loglevel debug</arguments>

Important

Set the log level back to info when you are done troubleshooting, as debug and especially trace produce a lot of output.

What TrustView itself logs about the communication with the ADCS module can be raised separately, see Additional logging for troubleshooting above. For troubleshooting the connection to the CA itself, see the Troubleshooting section of ADCS.

4.9. Microsoft DNS integration logs¶

The Microsoft DNS service used by the DNS integration writes its log files in a logs folder in the folder the service was installed from, named TrustView-MS-DNS-Service followed by .out.log, .err.log or .wrapper.log.

To get more detail, change -loglevel info to -loglevel debug in the <arguments> line of TrustView-MS-DNS-Service.xml, and restart the TrustView MS DNS Service Windows service.

4.10. ACME client logs (simple-acme and Certbot)¶

For simple-acme, the logs can be located by default here:

C:\ProgramData\simple-acme

It is also possible to set up custom logging for simple-acme, see simple-acme custom logging.

For Certbot, the logs can be located by default here:

/var/log/letsencrypt/

The ACME clients run on the server where the certificate is installed, not on the TrustView server, so their logs are found there. See Automation for how the clients are set up.

4.11. Event log in TrustView¶

Most objects in TrustView have their own Event log at the bottom of their detail page - for example certificates, SSL endpoints, automation tasks, agent connections, DNS providers and CT monitored domains. It lists what has happened to that object, with a Timestamp, the Event, the User who caused it and the Details.

The event log is often the quickest place to look, for example to see why an order, a renewal, a revocation or an automation task failed, before looking in the log files on the server.

4.12. Which log should I check?¶

TrustView does not start, or an update failed - the TrustView log file and the log files of the TrustView Embedded Service in the same folder.
Login problems (AD, SSO or local users) - the TrustView log file, with more detail as described under Additional logging for troubleshooting.
Notifications are not received - the TrustView log file, see also the troubleshooting section of Notifications.
ADCS certificates are not issued, imported or revoked - the ADCS module logs first, then the TrustView log file.
Scans do not find what they should - the Scan agent logs if an external scan agent is used, otherwise the TrustView log file.
Automated renewal or installation of a certificate fails - the Event log of the automation task, then the ACME client logs on the server where the certificate is installed.
Let’s Encrypt DNS validation through Microsoft DNS fails - the Microsoft DNS integration logs.
A single certificate order or object behaves unexpectedly - the Event log on its detail page.

If you contact our Support, include the relevant log files from around the time the problem occurred, or send them directly from TrustView.