Resolving the Tenable Vulnerability “SSL Self-Signed Certificate” (Nessus Plugin ID 57582) in Pacemaker pcsd
Security scans performed with Tenable Nessus frequently report the vulnerability “SSL Self-Signed Certificate”, identified by Plugin ID 57582, as a medium-severity finding. This issue is commonly detected on Red Hat Enterprise Linux systems running a Pacemaker cluster, specifically on port 2224, which is used by the pcsd service.
While the finding is technically correct from a scanner’s perspective, it is important to understand its root cause and, more importantly, how to remediate it properly in environments where compliance or stricter security baselines are required.
What Nessus Is Reporting
The Nessus plugin 57582 is triggered when a service presents an SSL/TLS certificate that is self-signed rather than issued by a trusted Certificate Authority. In the case of Pacemaker, pcsd generates a self-signed certificate by default during cluster setup. This certificate is then synchronized across all cluster nodes so that they share the same key pair.
From a cybersecurity standpoint, Nessus treats self-signed certificates as a risk because they do not provide third-party validation of the service identity. As a result, the scanner reports that the SSL certificate cannot be trusted, even though the service may be operating securely within an internal or controlled network.
Why This Happens in Pacemaker Clusters
The design of pcsd prioritizes cluster consistency. When the certificate is generated, its Common Name (CN) is set to the Fully Qualified Domain Name of the node that created it. That same certificate is then distributed to all other nodes in the cluster.
This design choice introduces two common scanner complaints. First, the certificate is self-signed. Second, the CN will not match the FQDN of all cluster nodes except the one that originally generated the certificate. Nessus and similar tools interpret this as a trust and hostname mismatch issue, which is enough to raise Plugin ID 57582.
Security Impact Assessment
In most internal cluster deployments, this finding represents a compliance or policy issue rather than an exploitable vulnerability. Communication via pcsd is typically restricted to trusted networks and administrative access. However, in regulated environments or where vulnerability reports must be clean, the finding cannot simply be ignored.
Get Jerome Decinco’s stories in your inbox
Join Medium for free to get updates from this writer.
This is where remediation becomes necessary.
Recommended Resolution
To properly resolve the Nessus 57582 finding, the self-signed certificate used by pcsd should be replaced with a certificate signed by a trusted internal or public Certificate Authority. Once a trusted certificate is in place, Nessus will no longer flag the service as using an untrusted SSL certificate.
After generating a certificate and private key signed by your trusted CA, they can be imported into the Pacemaker cluster using the following commands:
pcs pcsd certkey /path_to_certificate/pcsd.crt /path_to_certificate/pcsd.key --force
pcs pcsd sync-certificatesThese commands replace the default self-signed certificate and synchronize the trusted certificate and key across all cluster nodes, maintaining the expected cluster behavior while eliminating the scanner finding.
Post-Remediation Considerations
Even after replacing the certificate, it is important to be aware that Pacemaker will continue to use the same certificate on all nodes. This is intentional and required for cluster consistency. If your security scanner performs strict hostname validation, ensure that the certificate’s Subject Alternative Names are configured appropriately to avoid secondary warnings related to hostname mismatches.
Once a trusted CA-signed certificate is deployed, Nessus Plugin ID 57582 should no longer be reported for the pcsd service.
Conclusion
The Tenable Nessus vulnerability “SSL Self-Signed Certificate” (Plugin ID 57582) is a common finding in Pacemaker-based clusters and is primarily driven by default design choices rather than misconfiguration. While often low risk in internal environments, it can and should be remediated when compliance or security policy demands it.
Replacing the default self-signed pcsd certificate with one signed by a trusted Certificate Authority provides a clean, supported, and security-aligned resolution that satisfies both operational requirements and vulnerability scanning tools.
