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.


1 Answer 1


This is by design. You'll have to ignore your scan software. It is not supported to put your own SSL certificate on the SharePoint Web Services IIS site.

  • Dear Trevor, unfortunately we cannot ignore this scan software as this is by policy that each of our server must fulfill the successful scan of this software. If you can share any Microsoft link where its stated the same, that would be really helpful for me. Aug 10, 2016 at 8:29
  • You should open a Microsoft Support case if you're needing an 'official' answer.
    – user6024
    Aug 10, 2016 at 15:18
  • Unfortunately i do not have any support contact with Microsoft. Is there any other way? Aug 11, 2016 at 9:37
  • Not for an official answer.
    – user6024
    Aug 11, 2016 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.