0

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

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. – Muhammad Zeeshan Tahir Aug 10 '16 at 8:29
  • You should open a Microsoft Support case if you're needing an 'official' answer. – Trevor Seward Aug 10 '16 at 15:18
  • Unfortunately i do not have any support contact with Microsoft. Is there any other way? – Muhammad Zeeshan Tahir Aug 11 '16 at 9:37
  • Not for an official answer. – Trevor Seward Aug 11 '16 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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