As we know SharePoint put all of its services under "SharePoint Web Services" in IIS and binds it with HTTP 32843 and HTTPS 32844 ports. We are using a third party software Nexpose to scan our SharePoint 2013 server to find any vulnerabilities. The software highlighted the certificate related vulnerability on HTTPS port 32844 in SharePoint services web site in IIS. By default there is no certificate attached with this port. Below are the details of the vulnerability.
X.509 Certificate Subject CN Does Not Match the Entity Name (certificate-common-name-mismatch)
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.
Untrusted TLS/SSL server X.509 certificate (tls-untrusted-ca) 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
SHA-1-based Signature in TLS/SSL Server X.509 Certificate (tls-server-cert-sig-alg-sha1)
The SHA-1 hashing algorithm has known weaknesses that expose it to collision attacks, which may allow an attacker to generate additional X.509 digital certificates with the same signature as an original.
How should i proceed with this? This is getting very critical for us.
