Hello Support,
We are facing Untrusted certificate issue after Rapid7 InsightVM Scan. InsightVM scan has found 2 vulnerabilities linked with the certificate issued by Syncthing although Syncthing is working fine on our both production servers. Can you please help us to remediate these?
Vulnerability Title: Untrusted TLS/SSL server X.509 certificate
Proof: TLS/SSL certificate signed by unknown, untrusted CA: CN=syncthing, OU=Automatically Generated, O=Syncthing – [Path does not chain with any of the trust anchors].
Description: The server’s TLS/SSL certificate is signed by a Certification Authority (CA) that is not well-known or trusted. This could happen if: the chain/intermediate certificate is missing, expired or has been revoked; the server hostname does not match that configured in the certificate; the time/date is incorrect; or a self-signed certificate is being used. The use of a self-signed certificate is not recommended since it could indicate that a TLS/SSL man-in-the-middle attack is taking place
Summary: Obtain a new certificate from your CA and ensure the server configuration is correct
Fix: Ensure the common name (CN) reflects the name of the entity presenting the certificate (e.g., the hostname). If the certificate(s) or any of the chain certificate(s) have expired or been revoked, obtain a new certificate from your Certificate Authority (CA) by following their documentation. If a self-signed certificate is being used, consider obtaining a signed certificate from a CA.
Vulnerability Title: X.509 Certificate Subject CN Does Not Match the Entity Name
Proof: The subject common name found in the X.509 certificate does not seem to match the scan target:
- Subject CN syncthing does not match target name specified in the site.
- Subject CN syncthing does not match DNS name specified in the site.
- Subject Alternative Name syncthing does not match target name specified in the site.
- Subject Alternative Name syncthing does not match DNS name specified in the site.
Description: The subject common name (CN) field in the X.509 certificate does not match the name of the entity presenting the certificate. Before issuing a certificate, a Certification Authority (CA) must check the identity of the entity requesting the certificate, as specified in the CA’s Certification Practice Statement (CPS). Thus, standard certificate validation procedures require the subject CN field of a certificate to match the actual name of the entity presenting the certificate. For example, in a certificate presented by “https://www.example.com/”, the CN should be “www.example.com”. In order to detect and prevent active eavesdropping attacks, the validity of a certificate must be verified, or else an attacker could then launch a man-in-the-middle attack and gain full control of the data stream. Of particular importance is the validity of the subject’s CN, that should match the name of the entity (hostname). A CN mismatch most often occurs due to a configuration error, though it can also indicate that a man-in-the-middle attack is being conducted.
Summary: Fix the subject’s Common Name (CN) field in the certificate
Fix: The subject’s common name (CN) field in the X.509 certificate should be fixed to reflect the name of the entity presenting the certificate (e.g., the hostname). This is done by generating a new certificate usually signed by a Certification Authority (CA) trusted by both the client and server.
Kind Regards,
Soofian Ahmed
Principal Software Engineer
Ibex.