Thursday, May 08, 2014

Getting SSL Termination to work for HNSC in SP2013

We have been struggling a bit with getting off-box SSL termination to work properly for SharePoint 2013 host-named site collections (HNSC). We had issues with the ribbon, with admin pages like "manage content and structure", and with the term picker. Sure signs that some JavaScript files did not load. Users could not edit the terms in managed metadata fields, that is, terms could be selected, but clicking "ok" to save would just hang forever. A lot of scripts and links would not load, showing mixed content warnings in IE9 - and nothing at all in Chrome and Firefox, which both just blocks HTTP content on secure HTTPS pages.

To cut to the chase, this setup for SSL offloading is what worked for us:
  • create the web-app on port 80 (not 443), do not use the -SecureSocetsLayer switch
  • do not use the server name as the web-app name, you have a farm - don't you?
  • always extend the web-app to other zones before starting to create HNSC sites; leave one zone unextended, e.g. the "custom" zone
  • create a classic root site-collection with the same HTTP name as the web-app, do not use a HNSC for this
  • a site template is not required for the root site-collection
  • alternate access mapping (AAM) is used for load balancing even for HNSC, but HNSCs can't use AAM for host name aliases
  • create the HNSC using an internal HTTP URL in New-SPSite for the default zone, remember that crawling must always use the default zone
  • create a public URL alias for the default zone by mapping an unextended zone using a HTTPS URL in Set-SPSiteUrl, such as the "custom" zone
  • create public HNSC mappings using HTTPS URL in Set-SPSiteUrl for the other zones
  • ensure that your gateway adds the custom header "front-end-https: on" for all your public URLs secured using SSL
  • note that using just "front-end-https: on" and HTTP in the public URL will not correctly rewrite all links in the returned pages

In short, the salient point is to use HTTPS in the public URLs even if the web-app zone does not use the SecureSocetsLayer switch nor any SSL certificates. The default zone of the web-application must be configured for crawling - either no SSL or full SSL with certificates assigned in IIS. With no SSL you have to simulate AAM by mapping two URLs to the HNSC default zone. Using Set-SPSiteUrl on an unextended zone is like creating an alias for the default zone.

We had to use HTTP on the default zone to crawl the content of the published pages. It seems that if the web-application does not use SSL and your site default zone uses a HTTPS host header, then only the friendly URLs (FURL) will be crawled while the content will generate a lot of "This item comprises multiple parts and/or may have attachments. Not all of these parts were indexed." warnings. The result of the warning is no metadata being indexed, thus no search results - not good for a search-driven solution.

Note that SSL is recommended for all web-applications in SP2013 also inside the firewall, especially if you use apps - as the OAuth tokens otherwise will be exposed in the HTTP traffic, just as classic IIS basic authentication is not recommended without SSL. We wanted to do SSL bridging with BigIP due to this, but could not get SSL server name indication (SNI) configured successfully in BigIP v11 to allow us to have SSL certificates bound to two different IIS web-sites, even if IIS8 supports SNI.

SNI is required when the shared wildcard certificate or SAN certificate approach cannot be used for your SP2013 web-application setup, i.e. when binding to host names in multiple IIS web-sites at the web-application level. SNI is required when you need to use more than one web-application or more than one zone (extended web-app), even if you could bind your one-SAN-to-rule-them-all certificate to multiple IIS web-sites. IIS cannot route the request based on the host header until the request has been decrypted - SNI allows the request to be routed to the correct IIS web-site.

Remember that this is the path the HTTP(S) request travels from the browser:

 browser >
  host header >
   DNS A-record >
    virtual IP-address (VIP) in gateway > SSL off-box termination here
     load balancing >
      IIS server configured with IP-address >
       IIS web-site bound to IP-address (or host header) > normal SSL termination here
        SP web-application >
         site-collection bound to host header (HNSC)

Keeping tabs on this will help you understand the Technet guide to HNSC, which has some room for improvements. See this article by jasonth for a step-by-step guide for HNSC and SSL. Note that binding to host names in IIS rather than to IP-addresses for HNSCs at the SP2013 web-application level is supported, just as it was for SP2010.

17 comments:

Anders Rask said...

Hi,

SAN certificates also supports multiple certificates per web application?

Could you explain why you would use AAM on a HNSC (where SiteURLs would be appropriate).

What patch version was this test done on? As I understand it, the (mostly search related) issues where you need a path name root site collection (without template) was fixed in recent patches. It is still a requirement for HNSC, but that is as I understand it just to stay supported...

Kjell-Sverre Jerijærvi said...

It was tested with SP2013 SP1. Yes, we follow the guidelines to stay supported, and this is documented as a requirement for the search crawler to get access to the HNSC site-collection through crawling simply the web-application.

SAN certificates supports multiple host names in a certificate. Technet is a bit unclear on SAN, it says that multiple web-apps are needed for having unique second-level domain names - but as we ended up using off-box SSL termination, we didn't explore this further.

AAM for HNSC: according to Technet, this seems to be to avoid disclosing internal information (attack surface);
"Alternate access mappings must be configured for load balancing, even though it generally does not apply to host header site collections. The default zone public URL should be set to a domain URL that is appropriate for all users to see. Unless you do this, the names of web servers or their IP addresses might be displayed in parameters that were passed between pages within SharePoint 2013."

Anders Rask said...

SAN certs: you can have multiple certificates in one, and hence support a full SSL setup on 1 web app, 1 zone, 1 app pool pattern with App Mgmt. This works fine :-)

Eg.
DNS Name=*.contoso.com
DNS Name=*.contosoapps.com

The path named site collection you add will end up in the public zone, so no further AAM should be needed there.

The search crawler issue should be fixed in SP1 but we specify it to stay supported too :-)

Out of curiosity, what was the reasoning behind using SSL termination? I never really heard a good argument for it, and it complicates the farm setup while being less secure than a "normal" SSL setup.

Nice article!

Kjell-Sverre Jerijærvi said...

Thanks :)

We wanted to avoid SSL termination, and at the same time need to support an number of sites such as these:
minhelse.no
dinhelse.no
diagnoser.no
helsehjelp.no
etc

And we wanted to be able to add more SAN certificates over time, and also get easy lifetime management, thus the quest to make SNI work with BigIP v11 - as we have IIS8.

Our hosting partner together with their F5 partner could not make this SNI combo work - the fallback due to time constrains was off-box SSL termination.

Raj Pamamull said...

Great post!

I'm trying to implement a similar scenario.
I have a single web application with a host name site collection in two zones (default and internet). The internet zone site collection (abcpublishing.com) is anonymous/http so no SSL required.

However, we need to implement SSL (ssl offload at the gateway) on the default zone site collection (abcauthoring.com). It sounds like to make this work we need to ensure that their is an additional https URL mapping. Why is this the case? I thought the "front-end-https: on" http header would allow links to be translated to https.

I have also read on TechNet that:
•The SSL terminator or reverse proxy must preserve the original HTTP host header from the client.

Did you do this?

Raj Pamamull said...

Also, would you see any issues with using ssl offload with a web application with both path based sites collections and host name site collections?

Kjell-Sverre Jerijærvi said...

It is a requirement that your off-box SSL terminated HNSC URLs uses HTTPS, as documented on technet. If not, the URL rewriting for script links etc won't work properly.

The protocol part of the host name is not part of the host header, so confer with the docs for your gateway on how to propagate the host header "abcauthoring.com" correctly. Our hosting provider did this for us.

Path-based sites need to use AAM for off-box SSL termination. I have, however, not tried to combine both classic sites and HNSC sites in the same web-app.

Raj Pamamull said...

Many thanks!

So with SSL offload the gateway will connect to the SharePoint server through http (i.e. http://abcauthoring.com)? And unless there is an extra https URL added to an "unused/unextended" zone (https://abcauthoring.com) the http to https link "translation" will not occur?

The TechNet documentation doesn't seem to say the https URL needs to be added

Also, have you got apps/app domains running in your environment with SSL offload?

Kjell-Sverre Jerijærvi said...

You're right, the SP2013 version of the article isn't quite clear on this, it is a requirement in the SP2010 version, and we had to use both "front-end-https: on" and a HTTPS URL mapping to get 100% correct URL rewriting.

As for the host header forwarding, the gateway sends the HTTPS/443 traffic to HTTP/80 as required in the Technet article. I have no details on how our hosting provider does this, sorry.

Kjell-Sverre Jerijærvi said...

No, we don't have any setup for SP2013 apps. Still waiting for that model to mature a bit - as for everything v1 from MSFT :)

Raj Pamamull said...

Thanks we'll give it a go :)

Kjell-Sverre Jerijærvi said...

You don't need to extend if you don't need to have different authentication providers or different zone policies such as user policies for anonymous access. Use e.g. the default zone for authoring access and crawling, and the internet zone for anonymous visitors access.

Use Set-SPSiteUrl -url https://hostname with the URL (hostname) that your users will use to access the site.

Mafalda89 said...

Hi! I'm trying to follow this article to setup a scenario similar to yours. I'm using just one the default zone and I'd like to set AAM on my host-named site collections. My problem is that it looks like we can no longer assign multiple urls to a site choosing the same zone, and we I run Set-SPSiteUrl -url https://hostname I get an error saying an url is already assigned to the default zone. Do you know a solution for this? Thank you

Kjell-Sverre Jerijærvi said...

Only one URL per zone is supported. AAM wom't help.

Kjell-Sverre Jerijærvi said...

Use Set-SPSiteUrl with a zone that is unextended for the web-app, such as "custom", as such site URLs will be mapped to the default zone, just like an alias. Simple.

The identity of the site must refer to the hostname of the HNSC, "myhnsc".

Mafalda89 said...

Thank you!! :)

Anonymous said...

I have followed these steps (apart from extending the web application, which runs on Port 80). However, I can't index content on my HNSCs. The current error is:

An unrecognized HTTP response was received when attempting to crawl this item. Verify whether the item can be accessed using your browser. ( SearchID = E49FD74D-8550-41E6-81EF-78575EB97917 )

I have everything setup - also more details here https://social.technet.microsoft.com/Forums/office/en-US/30478852-3083-4de5-a4fd-bf057a394a00/hnsc-ssl-offloading-but-cant-index-the-content?forum=sharepointadmin#cc44b2c4-f80e-43f7-a752-a75e2e5d5909