Troubleshoot sensors

Information to help you debug issues with DigiCert® sensors.

Sensor statuses

The status indicates the current state of a DigiCert sensor. You can view the status of a sensor in DigiCert® Trust Lifecycle Manager in the following ways:

Go to the Discovery & automation tools > Sensors page, find the sensor in the table, and check the Status column for it. If the Status column does not appear, select the Add Column button on the top-right of the table to add it.
Select a sensor from the Discovery & automation tools > Sensors table to view the details for it. The sensor status is shown in the top section of the details page. For error statuses, look for a top banner with troubleshooting information.

Status	Description
`Allocated`	Installation file downloaded, but sensor not installed.
`Active`	Installed and running.
`Error`	Cannot reach the server.
`Stopped`	Shut down by the user or system and cannot perform actions.
`Suspended`	Temporarily stopped by the user and cannot run automation tasks.

Network diagnostic tool

DigiCert sensors include a command-line diagnostic tool used to check network connectivity to Trust Lifecycle Manager via the URLs in the config/license.properties file of the installed sensor. The diagnostic tool is found in the main sensor installation directory on the sensor host and must be run with administrator privileges.

Sensor operating system	Diagnostic tool command
Windows	`diag.bat`
Linux	`diag.sh`

Sensor debug mode

Use this option to extend the sensor logging level. This enables you to capture additional information in the log file to investigate and solve issues in your environment.

Note: Debug mode is disabled by default for sensors.

To enable debug mode for a sensor:

From the Trust Lifecycle Manager main menu, select Discovery & automation tools > Sensors.
Locate the applicable sensor in the table. In the Debug mode column, toggle the switch to On.

Sensor log files

The location of the sensor log files depends on the host type and installation directory ({$Install_Path$}) where the sensor software was installed.

Host type	Log type	Location of log files
Windows	Sensor logs	{$Install_Path$}\logs
Windows	Trust Lifecycle Manager plugin manager (TPM) logs for the sensor	{$Install_Path$}\logs
Linux	Sensor logs	{$Install_Path$}/logs
Linux	Trust Lifecycle Manager plugin manager (TPM) logs for the sensor	{$Install_Path$}/logs
Docker	Sensor logs	{$Install_Path$}/sensor_home/logs

Timeout errors for sensors

Verify you can reach port 443 on your DigiCert ONE instance from the sensor host. Your instance may be a private host on your LAN or a public host on the Internet. Check with your DigiCert administrator to verify the correct hostname or IP address to use.

Let op

For a list of DigiCert ONE cloud IP addresses and URLs by region, see Platform IP addresses and URLs.

Debug proxy communication errors

This section helps you troubleshoot communication errors when an agent connects to DigiCert ONE through a DigiCert sensor operating in proxy mode.

Make sure you enable debug mode on the sensor to capture detailed low-level networking logs, including tunnel and proxy-level connection activity.

Example logs with sensor debug mode enabled

The following log sample illustrates proxy tunnel connectivity and state transitions when sensor debug mode is enabled.

2026-02-24 15:21:25,747 DEBUG proxy.impl.ProxyToServerConnection - (AWAITING_INITIAL {tunneling}) [id: 0x749d0a53, L:/172.16.0.4:6468 - R:one.digicert.com/45.60.48.211:443]: Using existing connection to: one.digicert.com/45.60.48.211:443
2026-02-24 15:21:25,747 DEBUG proxy.impl.ProxyToServerConnection - (AWAITING_INITIAL {tunneling}) [id: 0x749d0a53, L:/172.16.0.4:6468 - R:one.digicert.com/45.60.48.211:443]: Writing: AdaptivePoolingAllocator$AdaptiveByteBuf(ridx: 0, widx: 491, cap: 1024)
2026-02-24 15:21:25,756 DEBUG proxy.impl.ProxyToServerConnection - (AWAITING_INITIAL {tunneling}) [id: 0x749d0a53, L:/172.16.0.4:6468 - R:one.digicert.com/45.60.48.211:443]: Reading: AdaptivePoolingAllocator$AdaptiveByteBuf(ridx: 0, widx: 542, cap: 16384)

2026-02-24 15:21:25,756 DEBUG proxy.impl.ClientToProxyConnection - (AWAITING_INITIAL {tunneling}) [id: 0x66c3a35c, L:/172.16.0.4:48999 - R:/172.16.0.3:36204]: Writing: AdaptivePoolingAllocator$AdaptiveByteBuf(ridx: 0, widx: 542, cap: 16384)

2026-02-24 15:22:36,261 DEBUG proxy.impl.ProxyToServerConnection - (AWAITING_INITIAL {tunneling}) [id: 0x749d0a53, L:/172.16.0.4:6468 - R:one.digicert.com/45.60.48.211:443]: Got idle
2026-02-24 15:22:36,261 DEBUG proxy.impl.ClientToProxyConnection - (AWAITING_INITIAL {tunneling}) [id: 0x66c3a35c, L:/172.16.0.4:48999 - R:/172.16.0.3:36204]: Got idle
2026-02-24 15:22:36,261 DEBUG proxy.impl.ClientToProxyConnection - (DISCONNECTED {tunneling}) [id: 0x66c3a35c, L:/172.16.0.4:48999 ! R:/172.16.0.3:36204]: Disconnected
2026-02-24 15:22:36,261 DEBUG proxy.impl.ProxyToServerConnection - (DISCONNECTED {tunneling}) [id: 0x749d0a53, L:/172.16.0.4:6468 ! R:one.digicert.com/45.60.48.211:443]: Disconnected
2026-02-24 15:22:36,261 DEBUG proxy.impl.ProxyToServerConnection - (DISCONNECTED {tunneling}) [id: 0x749d0a53, L:/172.16.0.4:6468 ! R:one.digicert.com/45.60.48.211:443]: writeToChannel failed sending message EmptyByteBufBE

When reviewing sensor debug logs, focus on the following entries:

Log entry	Description
`ClientToProxyConnection`	Agent (client) to sensor proxy side
`ProxyToServerConnection`	Sensor proxy to DigiCert ONE endpoint

Use these entries to:

Verify that the agent establishes a connection to the sensor.
Confirm that the sensor establishes and maintains outbound connections to DigiCert ONE (for example, one.digicert.com:443).
Identify the root cause of connection failures, such as firewall or proxy restrictions, network interruptions, timeouts, or normal idle disconnections.

Review the following log patterns to determine the connection state and identify potential communication issues:

Using existing connection together with Writing and Reading activity
Indicates that the proxy tunnel is active and data is flowing normally.
Got idle followed by DISCONNECTED {tunneling} entries
Indicates a normal idle timeout or expected tunnel closure and is not necessarily an error condition.

Example logs with sensor debug mode disabled

The following log sample shows typical high-level communication entries recorded when sensor debug mode is disabled. Detailed proxy and tunnel-level activity is not included in this mode.

2026-02-18 11:00:42,375 INFO  communication.core.HeartBeat - [HEARTBEAT] Reporting status to https://one.digicert.com/mpki/ts/daas/healthCheck/HealthcheckService
2026-02-18 11:00:53,467 WARN  communication.helper.HTTPUtils - [HEARTBEAT] Error while connecting to: https://one.digicert.com/mpki/ts/daas/healthCheck/HealthcheckService -- one.digicert.com

2026-02-18 11:10:55,000 INFO  communication.core.HeartBeat - [HEARTBEAT] Reporting status to https://one.digicert.com/mpki/ts/daas/healthCheck/HealthcheckService
2026-02-18 11:11:16,099 WARN  communication.helper.HTTPUtils - [HEARTBEAT] Error while connecting to: https://one.digicert.com/mpki/ts/daas/healthCheck/HealthcheckService -- Connection timed out: connect

With debug mode disabled, the logs provide basic validation of service status and connectivity. Review the following entries:

Self hosts [172.16.0.4:48999, ...]
Indicates the local IP addresses and ports where the sensor service (web server/proxy) is running. The listed IP:port confirms the service is running, but it does not confirm outbound connectivity.
Requested host one.digicert.com:443
Indicates that the sensor received the agent request and is attempting to connect to DigiCert ONE.
[HEARTBEAT] Reporting status to https://one.digicert.com/...
Indicates that the sensor is attempting to send heartbeat communication to DigiCert ONE. If no corresponding [HEARTBEAT] Error while connecting WARN or ERROR messages appear during the same timeframe, there is no immediate evidence of heartbeat communication failure.

In deze sectie: