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.

Managed Metadata Navigation, Anonymous Users in SP2013

The new term-driven navigation in SP2013 has some gotchas for anonymous users, resulting in them not seeing a full navigation menu. These are some things to check:

• Make sure there is a defined physical page for each navigation node term
• The terms must be available for tagging
• Make sure that anonymous users have read access to the TaxonomyHiddenList of the site-collection
• Always manage the navigation termset from site settings of the site-collection that hosts the termset; do not use manage term store from Central Admin
• If your custom code can't resolve and show terms in the navigation termset, make sure to use a view that don't depend on the cache being updated

Finally, remember that you have to publish a major version for each page that you link to from the navigation node, otherwise anonymous users won't see the page, and neither the term. This includes all items on the page that also requires approval, such as images. An easy thing to forget, if you've been so stupid as not to use the simple publishing configuration for your site. If you as an admin or logged in user can see terms and view a page, while visitors can not - you forgot to publish. An empty page or no term is a sure sign.

Related to the managed navigation is the friendly URL (FURL) mechanism, which uses the term set structure to build the FURL from the linked-to term. To prevent broken links when moving a term, SP2013 stores links using the FIXUPREDIRECT.ASPX page, with params such as the termID, which will be resolved server-side into a friendly URL when rendered (see navigation term GetResolvedDisplayUrl). Do not render RichHtmlField using the simple "SPWC:FieldValue" web-control, as this will not resolve the fixup-links. In addition, having the same control both in an edit mode panel and in a display mode panel might cause problems.

This all applies to author-in-place (AIP) usage of term-driven navigation and friendly URLs; cross-site publishing (XSP) have different kind of issues.

Note that the managed navigation term set is stored in the default MMS of the hosting web-application. It uses the local term store for the site-collection it belongs to (IsSiteCollectionGroup). This will affect your backup/restore procedure as not only the content database or the site-collection backup will be needed for a restore, the MMS database or tenant backup is also needed. As all host-named site-collections (HNSC) share a web-application, restoring the MMS with it's term stores will affect the navigation term set of all site-collections. Take care.