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:
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.