Overview
In this lab, I performed a vulnerability scan using Tenable Nessus Essentials, which flagged an issue related to SSL certificate trust. The scan identified that the X.509 certificate for a remote service could not be trusted due to a broken certificate chain. Specifically, the certificate was issued by an unknown Certificate Authority (CA) because it was self-signed.
Initial Scan
Nessus flagged an “SSL Certificate Cannot Be Trusted” vulnerability during the scan.
- The certificate chain was broken because the remote host sent a certificate signed by an unknown CA.
- The affected certificate was issued by a self-signed FileZilla Server certificate.
SSL Certificate Issue
The Nessus scan results highlighted an issue with the SSL certificate.
Detailed Investigation
The Nessus scan revealed the following certificate details:
- Subject: CN=filezilla-server self-signed certificate
- Issuer: CN=filezilla-server self-signed certificate
Both the subject and issuer were identical, confirming that the certificate was self-signed and not recognized by the system’s trusted certificate authorities.
This is common in services like FileZilla Server, which generate self-signed certificates instead of obtaining one from a trusted CA.
Implications
While this issue was not critical in a lab environment, it could lead to trust issues with clients connecting to the service in a production setting.
- The absence of a trusted CA makes it easier for attackers to impersonate the server and conduct man-in-the-middle (MITM) attacks.
- This could lead to the compromise of sensitive data.
Resolution
Since this issue stemmed from FileZilla Server’s self-signed certificate, I explored possible resolutions:
- Lab Environment Solution:
- Add the self-signed certificate to the local trust store for internal use.
- Production Environment Best Practice:
- Replace the self-signed certificate with one issued by a trusted CA to avoid trust-related issues and enhance security.
Troubleshooting
Nessus flagged the certificate because it could not verify the certificate chain without a valid CA at the top.
- Once I identified the root cause of the self-signed FileZilla certificate, I understood this was a common finding in a lab setup.
Outcome
- In my lab setup, this vulnerability did not pose a serious security risk.
- In a real-world environment, replacing the self-signed certificate with one from a trusted CA would be the recommended fix to prevent trust issues and potential MITM attacks.
Tools Used
- Tenable Nessus Essentials
- Command-line tools (e.g.,
ipconfigfor networking)