Am a keen follower of Microsoft's SharePoint Blog and proud to provide this direct from the Microsoft Tech Community:
Contents
- What is SSL Offloading
- Configuring SSL Offloading with SharePoint
- Web Applications
- Host Names Site Collections
- SharePoint Apps (App Domain
- Common Issues
- URLs returned to users are incorrect
- List or library Dropdown menu not loading
- After configuring SSL offloading for a web application users receive a 404 or 503
- Additional Information
- Creating IIS bindings for SharePoint Web Applications through PowerShell
What is SSL Offloading?
The idea behind SSL offloading is to reduce the load on web servers as well as the administrative overhead of managing SSL certificates across multiple servers. This is accomplished by using a dedicated network device (often times a network load balancer or a proxy server) to terminate SSL as it routes the requests. This removes the burden of decrypting and encrypting https traffic from the web server as well as providing a single location to host the SSL certificate reducing administrative efforts of maintaining and replacing certificates.
What it looks like:
- The user makes an https request for a webpage that is routed to the load balancer
- The load balancer terminates SSL and sends the unencrypted http request to the web server
- The Web server handles the request and returns an unencrypted http response to the load balancer
- The load balancer encrypts the request and forwards it to the client that made the original request as https
Configuring SSL Offloading with SharePoint
Web Applications
To configure a SharePoint web application to take advantage of SSL offloading the Alternate Access Mappings must be configured in a specific way that allows the request to be accepted as http but have links rendered as https. By using internal URLs we can tell SharePoint to recognize an incoming request to http://sharepoint and handle it as though it were https:/sharepoint. Below illustrates how Alternate Access Mappings should be configured to allow for SSL offloading to occur. Note that the internal URL should match the traffic between the load balancer and SharePoint while the public url should reflect what URL users think they are using.
If you are creating a new web application to be used with SSL offloading use the below settings as a guide to create it.
Host Header |
|
Port |
80 |
User Secure Sockets Layer (SSL) |
No |
Public Url |
If you are configuring an existing HTTPS Web Application for SSL offloading add an internal URL using the same hostname over http to the zone they wish to use SSL offloading with. The end result should look like the example below. To add these you will want to go to Central Administration > Application Management > Configure Alternate Access Mappings > Add Internal URLs.
Zone |
Internal Url |
Public Url |
Default |
https://sharepoint |
https://sharepoint |
http://sharepoint |
https://sharepoint |
Host Names Site Collections
In path based sites we can utilize a combination of internal and public URLs in the web app’s AAMs to achieve the redirection that we need. While we do have multiple zones for HNSCs we do not have the same functionality that internal and public URLs provide. As such the configuration for HNSCs is different as described below.
Web Application Configuration
- The web application should be configured the same way as seen above except the host header should remain empty
- HNSC should be created using an https URL
Example:
New-SPSite 'https://portal.fabrikam.com' -HostHeaderWebApplication 'https://sharepoint.contoso.com' -Name 'Portal' -OwnerAlias 'contosoadministrator' -Language 1033 -Template 'STS#0'
- Bindings for the backing IIS site should include an http binding with a blank host-header if not already present
Proxy or Load Balancer Configuration
Since we cannot use internal URLs like we would for a path based site collections we must configure the proxy server or load balancer that is serving as the point of SSL/TLS termination to add an additional header to the web requests. The header Front-End-Https tells SharePoint whether the links that it renders for this web request should be rendered as http or https.
Front-End-Https |
|
Value |
Description |
On |
The request made by the end user was made over https Example: Front-End-Https: On |
Off |
The request made by the end user was made over http |
Public Content: Use host-named site collections with off-box SSL termination
SharePoint Apps (App Domain)
When attempting to configure SSL offloading for app domains you may see the below error:
03/05/2015 09:13:34.20 w3wp.exe (0x0XXX) 0x0XXX SharePoint Foundation General aiz2a High Request for app scheme does not match the webapp’s scheme for this zone. Request Uri: http://app-XXXXXXXXX.apps.contoso.com…. Zone Response Uri: https://sharepoint.contoso.com Site collection path: /
To allow requests between web applications and app domains to be handled under different protocol schemes (http and https) as you would see when configuring SSL offloading for both web apps and app domains run the below PowerShell to enable support for multiple app domains.
$contentService.SupportMultipleAppDomains = $true
$contentService.Update()
Public Content: Configure an environment for apps for SharePoint (SharePoint 2013)
Common Issues
URLs returned to users are incorrect
When an environment with SSL offloading is not configured correctly it is not uncommon to see the URL in link rendered by SharePoint such as navigation to be incorrect. I.e. all links are rendered in http instead of https or in some scenarios even a different host name. This is most commonly caused by the configuration of alternate access mappings.
Document the following:
- The address and protocol that the users utilize to access the site.
- The address and protocol that the load balancer (or point of SSL termination) forwards the request as. It is possible that the hostname could differ as well as the protocol.
With the answers to the above ensure that the alternate access mappings for the web application are configured as seen below where the numbers coordinate to the responses from the above:
- Public url matches url that users utilize.
- Internal url matches url of incoming requests from the load balancer, if it is not present click Add Internal URLs on the Configure Alternate Access Mappings page in Central Administration.
List or library Dropdown menu not loading
This can be a problem when the site is accessed via Azure Application Proxy. See https://internal.support.services.microsoft.com/en-us/help/4459184
After configuring SSL offloading for a web application users receive a 404 or 503
This most often is due to the bindings in IIS. Locate the IIS site behind this zone of the web application.
To modify the bindings of an IIS website:
- Open Internet Information Services (IIS) Manager from Start > Administrative Tools
- Expand the server name in the Connections pane
- Expand Sites
- Right click on the site that should be serving the requests for the SharePoint Web Application in question
- Ensure that there is both an https as well as an http binding for the hostname that will be accessed as seen in the image below
Additional Information
Creating IIS bindings for SharePoint Web Applications through PowerShell
While you can add bindings to the SPWebApplication.IisSettings.ServerBindings array through PowerShell do note that this does not propagate to the existing IIS sites. This will however create the bindings when the SharePoint Foundation Web Application service is started on a server. As such any new server added to the farm, or any server where the web application service is started/restarted the bindings added through the below method will be reflected.
$wa = Get-SPWebApplication ‘http://sharepoint.contoso.com’
$binding = New-Object Microsoft.SharePoint.Administration.SPServerBinding
$binding.Port = 80
$binding.HostHeader = “”
#Note the “Default” below references the zone of the web application, if you wish to add a binding to a different zone replace that with the appropriate zone (Default/Intranet/Internet/Extranet/Custom).
$iis = $wa.IisSettings[“Default”]
$iis.ServerBindings.Add($binding)
$wa.Update()
#Call the provision method to push this out to all servers, note that this will overwrite any manual modifications to the web.config or other manual changes within IIS for this web app.
$wa.ProvisionGlobally()
Special thanks to the original author: Ian Ragusa (Microsoft PFE)
Related Posts
The above is kindly provided by the Microsoft Tech Community!