One Single IP:port for Multiple SSL Enabled Sites, each with a Different SSL Certificate

In a real-world production environments, there can be multiple web applications in the same farm that use different host headers but the same port, which is often 80/443. This is not an issue when SSL is not implemented. When the request reach the web server, IIS will direct the request to specific sites based on the host header. However, if SSL is to be implemented and all the sites will be using the same port, there will be a problem with the certificate as network end-point can only be identified with IP:Port binding. In the old days, two possible solutions are:

  • Use two IPs on the same server, so that each IIS site can use a different certificate. This is should not be too difficult when the WFEs are virtualized.
  • Use a wildcard certificate so all the web applications can use the same certificate as long as they share the same domain.  If not, you may want to choose a Unified Communications Certificate if that really is a preferred solutions in your situation.

With Windows Server 2012 or above, you have the third option that comes with the Server Name Indication feature of IIS 8. This feature makes it possible that the host name in the IIS binding be used to identify the network endpoint. In this case, different IIS sites can use the same IP address and port while using different certificates. However, it requires the client browsers to support SNI. If not, you need to create a default SSL site. Check this blog post for more information: http://blogs.msdn.com/b/kaushal/archive/2012/09/04/server-name-indication-sni-in-iis-8-windows-server-2012.aspx

Configuring SharePoint and Office Web Apps to Support SSL Offload

When Load Balancing SharePoint Web Servers and Office Web Apps Servers, some organization would like to adopt SSL offload to improve overall network performance. In these organizations, either the communication between the load balancer and SharePoint Servers are closed so no one could possibly listen in, or just that internal regulations allow non-encrypted traffic between the load balancer and the server behind it. They could bind the SSL certificate only at the load balancer, while on the servers behind, port 80 or other ports are used but without SSL.

In the context of a SharePoint Farm, to support this setup, there are certain configurations to be done on SharePoint as well as the Office Web Apps Server farm (provided that there are more than one OWA servers.

Office Web Apps Server Farm

Configure the Office Web Apps farm with the –AllowHTTP and –SSLOffloaded options set to true.

For example, when creating a new Office Web Apps farm with the cmdlet New-OfficeWebAppsFarm, use the parameter –SSLOffloaded. In this case, the value of –AllowHTTP will be set to true automatically. If the server farm has been created without supporting SSL offload, you could simply, use the Set-OfficeWebAppsFarm cmdlet to change the values.

SharePoint Farm

First of all, there is a difference between path-based site collections and host-named site collections.

For path-based site collections:

Configure Alternative Access Mapping to support the SSL Offload.

When SSL is offloaded to the load balancer, the web applications would not be configured to use SSL. However, there is a difference between the URL that users use to access the web application and the URL set at IIS. For example, the URL used by uses is https://sharepoint.contoso.com as SSL is configured at the load balancer, while in SharePoint, the web applications are created as http://sharepoint.contoso.com.  Without AAM accommodating the difference between the internal and external URL, the SharePoint sites may not work properly. One possible behavior is that the browser will warn you that the content is not secure.

To configure AAM to support SSL offload, you should first make sure the public url is set to https:// and then add an internal URL as http://. Simply adding a URL for HTTPS will not work. Here is one way to configure it:

  1. From SharePoint Central Administration navigation pane, click Application Management.
  2. In the main pane, under Web Applications, click Configure alternate access mappings.
  3. From the Internal URL list, click the Internal URL corresponding to the Public URL you want to be accessible through the load balancer.
  4. The Edit Internal URLs page opens.
  5. In the URL protocol, host and port box, change the protocol from http:// to https://.

2014-08-24_1534

  1. Click the OK button. You return to the Alternate Access Mappings page.
  2. On the Menu bar, click Add Internal URLs.
  3. In the URL protocol, host and port box, type the same internal URL used in step 4, but use the http:// protocol. This allows access to the non-SSL site from behind the load balancer.

2014-08-24_1536

  1. Click Save. The result should look like this:

2014-08-24_1536_001

For host-named site collections:

AAM does not work. You need to configure the load balancer (or the reverse proxy) to add http header. More specific information can be found in this TechNet article: https://technet.microsoft.com/en-us/library/cc424952.aspx#section2g

If you are using F5 load balancer, you can also find a specific user guide for this scenarios for SharePoint: https://www.f5.com/pdf/deployment-guides/microsoft-sharepoint-2016-dg.pdf