Troubleshooting

Logs

If you run into issues with Security Compliance Management (SCM), you can access the relevant log files. Security Compliance Management uses the journald logging driver for logging.

To view logs in Security Compliance Management, use journalctl. For example, to view all of the logs from the comply-scarpy container you would use:

sudo journalctl CONTAINER_NAME=comply_scarpy

You can use filters to limit the number, format, time period, etc., from your results. For example, to retrieve the logs for comply-scarpy since 18 June 2024, you would use:

sudo journalctl --since "2024-06-18" CONTAINER_NAME=comply-scarpy

Reset your Security Compliance Management password

If you forget your password, you can reset it in the user admin console.

SSH into your Security Compliance Management node and run the following commands to retrieve the admin username and password:
```
/usr/bin/docker exec -it comply_identity env | grep KEYCLOAK_ADMIN=
```
```
/usr/bin/docker exec -it comply_identity env | grep KEYCLOAK_ADMIN_PASSWORD=
```
If you are using Podman instead of Docker, replace docker with podman.
Navigate to https://<SCM-HOSTNAME>/auth/admin using the FQDN of your Security Compliance Management node.
Login using the credentials from step 1.
Select Puppet Realm from the dropdown menu.
Navigate to Users.
Use an asterisk(*) as a search term to show all users and select the user account you want to update.
Click Edit to edit the selected user account.
Select the Credentials tab and then reset the password.

Resolve a failed assessor upgrade

If an upgrade of the assessor has failed on one of your nodes, try the following troubleshooting step.

If the upgrade of an assessor on a node fails, the node is marked in red on the Inventory page. Failures may be due to network issues. If that is the case, Security Compliance Management attempts to upgrade the node once connectivity returns. An hourly background task runs to check if nodes have been upgraded or not. If a node does not upgrade and remains red on the Inventory page, run the Puppet agent. If the upgrade continues to fail, see the Puppet agent logs for more information.

Troubleshooting mTLS issues in Security Compliance Management

Incorrect configuration of mTLS certificates when setting up Security Compliance Management to work with PE can cause agents and/or scan tasks to fail.

There are two main certificate configuration errors that cause problems:

If the CA certificate configured for Security Compliance Management does not match the CA certificate the Puppet Enterprise certificate is signed with, then a trust store issue is returned upon setting up Puppet Enterprise or trying to run a scan.
A hostname issue can arise if a server identity check does not pass. The dnsName in the subjectAltName of the server certificate must match the hostname Security Compliance Management is communicating with. The hostname configured in the Security Compliance Management settings page for Puppet Enterprise must match one of the dnsName entries in the Puppet Enterprise certificate.

Troubleshooting agent issues

Agents can fail if the certificate is configured incorrectly in two ways:

The hostname could be the issue - the Security Compliance Management mTLS certificate must have the dnsName with which the agent is trying to contact the Security Compliance Management server. This is relevant only if you set up the Security Compliance Management module to download the assessor from the Security Compliance Management server. The hostname the Security Compliance Management server is contacted with is the hostname in the configured scanner_source parameter URL.
The trust store may also be the problem if the Security Compliance Management server mTLS certificate and the client certificate are not signed by the same CA.

Troubleshooting scan task issues

Scan tasks can also fail if the certificate is configured incorrectly in two ways:

If the hostname is incorrectly configured. The Security Compliance Management mTLS certificate must have the dnsName with which the agent is trying to contact the Security Compliance Management server. The hostname used is passed through by the task and can be seen in the Puppet Enterprise UI by checking the task parameters. Verify the task parameters to ensure that the hostname is correct.
If the Security Compliance Management server mTLS certificate and the client certificate are not signed by the same CA a trust store issue occurs and this too can cause the scan task to fail.

Troubleshoot mTLS from a node

You can run a simple cURL command to troubleshoot mTLS issues from a node.

To troubleshoot mTLS from a node:

SSH into a node and change to the SSL subdirectory:
```
cd /etc/puppetlabs/puppet/ssl/
```
Issue the following cURL command replacing values in angle brackets with values relevant to your installation:
```
curl -G --key private_keys/<local host key> --cacert certs/ca.pem --cert ../certs/<local host cert> https://<comply-fqdn>:30303/assessor --output /tmp/assessor.zip
```
Note: If you are using your own ingress, issue the following command:
```
curl -G --key private_keys/<local host key> --cacert certs/ca.pem --cert ../certs/<local host cert> https://<PE hostname>/assessor --output /tmp/assessor.zip
```
If this command fails, there is an issue with certificates. The error message can help to identify if there is a CA, client certificate or hostname issue.
- If there is a hostname error, the output resembles the following error message:
```
curl: (60) SSL: no alternative certificate subject name matches target host name '<scm-fqdn>'
```
- If it is a CA issue, the output is likely to be similar to the example below:
```
curl: (60) SSL certificate problem: unable to get local issuer certificate
```
  Important: This may be because the CA of the https://<scm-fqdn>:30303/assessor (or https://<PE TLS hostname>/assessor) does not match the CA passed to the cURL command or because there is a mismatch with the CA of the client certificate.