none
Host-named site collections with off-box SSL termination

    Question

  • My client's SP2013 farm currently uses path based site collections, however due to new requirements I'm expanding the farm by use of host-named site collections. I've set it all up in my development environment, however unfortunately the dev environment doesn't have off-box SSL termination (an expensive load-balancer wasn't justifiable for dev), so I'd like to just confirm whether my approach will work with off-box SSL termination

    - Create a new web application with the -SecureSocketsLayer switch (the current web applications don't have this, so I can't use them)

    $webApp = New-SPWebApplication -Name $webAppName -port 443 -ApplicationPool $webAppPool -ApplicationPoolAccount (Get-SPManagedAccount $iisAccount) -AuthenticationProvider (New-SPAuthenticationProvider –UseWindowsIntegratedAuthentication) -SecureSocketsLayer

    - Then create a content database for it of course. 

    New-SPContentDatabase -Name $contentDbName -WebApplication $webAppName

    - Create the host-named site collections in the new web application with HTTPS URLs

    $spSite = New-SPSite -Url $httpsUrl -OwnerAlias $owner1 -SecondaryOwnerAlias $owner2 -ContentDatabase $contentDbName -HostHeaderWebApplication $webAppName -Name $name -Template $template

    The main question I have is this: This creates an IIS site which uses SSL. In dev, I slapped a self-signed certificate on it in IIS and moved onward. In production however, the IIS site must be non-SSL as we have off-box termination. How will this function if the HNSCs in the web app are HTTPS? Do I just change the bindings on the IIS site to non-SSL port 80 and job done?

    Thanks!


    sysadmin

    Friday, November 29, 2013 1:44 PM

Answers

  • Create the Web Application with a generic address, e.g. http://sp.domain.com and not a server name.  Next, validate the Site Collection URLs are all http://<site>.domain.com.  Obviously if you have any sites that are https://<site>.domain.com, you'll need the SSL binding.

    Did you make sure to create a root site collection at http://sp.domain.com (http://<servername>)?


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Proposed as answer by Waqas Sarwar(MCSE 2013) Wednesday, December 04, 2013 3:22 AM
    • Marked as answer by xida Wednesday, December 04, 2013 7:26 AM
    Tuesday, December 03, 2013 12:48 AM

All replies

  • Because SharePoint Server 2010 uses the public URL in the Default zone of the Web application to determine whether host-named site collections will be rendered as HTTP or SSL, you can now use host-named site collections with off-box SSL termination. There are 3 requirements to use SSL termination with host-named site collections:

    • The public URL in the Default zone of the Web application must be an HTTPS-based URL.

    • The SSL terminator or reverse proxy must preserve the original HTTP host header from the client.

    • If the client SSL request is sent to the default SSL port (443), then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the default HTTP port (80). If the client SSL request is sent to a non-default SSL port, then the SSL terminator or reverse proxy must forward the decrypted HTTP request to the front-end Web server on the same non-default port.

    To use host-named site collections with off-box SSL termination, configure your Web application as you normally would for SSL termination and ensure that it meets the requirements described above. In this scenario, SharePoint Server 2010 will render links of its host-named site collections in that Web application using HTTPS instead HTTP.

    http://blogs.msdn.com/b/markarend/archive/2012/05/30/host-named-site-collections-hnsc-for-sharepoint-2010-architects.aspx


    Please remember to mark your question as answered &Vote helpful,if this solves/helps your problem. ****************************************************************************************** Thanks -WS MCITP(SharePoint 2010, 2013) Blog: http://wscheema.com/blog

    Sunday, December 01, 2013 6:15 AM
  • Thank you for the copy/paste from MSDN, Waqas - unfortunately (regardless of the fact that this is about 2010), this doesn't work nor does it answer my question. 

    Due to time constraints, I had to move forward with this in production - here's how I implemented HNSC on 2013 to use SSL with off-box SSL

    - Created a new web application and content database as described in my original post. Doing this creates a new site in IIS with a *:443 binding. This isn't ideal as it would require either being changed to use a custom port or would require a unique IP address. Fortunately I could accommodate that.

    - Add a *:80 binding to the new site in IIS. The *:443 binding cannot be removed from IIS, if it is removed then creating site collections with an HTTPS URL throws an error and the site collections are not reachable afterward.

    - Create new site collections in the new web application (I created three root HNSCs and several other HNSCs using HNSC managed paths). The root HNSCs require a second non-SSL URL to be added (I used the Intranet Zone to add the same URL but with HTTP). 

    This appears to work but to me doesn't seem particularly ideal. I can access all the new SSL HNSCs using HTTPS, but I cannot remove the *:443 binding from IIS and I have to add a HTTP URL in the Intranet Zone.

    I also noticed two issues with this set up. Firstly, with one of the new HNSCs, if I go in to site settings and try to change site collection admins via the ribbon, I get a secure content warning in IE. Accepting this allows me to continue, but it makes me wonder if there are any other similar issues lurking somewhere. Secondly, if I restore a non-root site-collection using Restore-SPSite, it wipes out the Intranet Zone URL and does not allow me to re-add it afterward, rending the restored site unavailable.

    Does anyone know of a different approach to the one I've come up with, ie. a solution to the question posed in my original post?


    sysadmin

    Sunday, December 01, 2013 8:43 AM
  • In prod, why do you need to change the IIS binding? Wouldn't you just set it up with TCP/80 only? Not sure where the SSL binding in prod comes into play with your scenario if you have SSL termination in use.

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, December 01, 2013 9:10 AM
  • Hi Trevor - 

    Thank you, you're correct. 

    I just went to double-check: I removed the *:443 binding in IIS. I found that HNSCs already created are still accessible via the off-box SSL termination (indeed logically they should be), and I created a new site-collection (non-root, using HNSC managed path) without any error thrown in powershell, and the new site was also accessible via the NLB.

    I must have fumbled this in testing previously, thanks.

    So, we can lose the *:443 binding from IIS which is very nice :)

    That still leaves me with the secure content warnings though, which appear when trying to add site collection administrators via the ribbon control. Not a big problem in itself, but somewhat worrying as I don't yet know where else it may appear. Personally, I add additional site collection admins via powershell anyway, but the client and first-line support are going to get upset about this warning as it doesn't appear with the legacy path based sites we've been using up until now.



    sysadmin

    Sunday, December 01, 2013 9:28 AM
  • Use Fiddler2 to track down the mixed content issues.

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, December 01, 2013 9:31 AM
  • Thank you, Trevor. 

    When clicking on the "site collection administrators" ribbon control, Fiddler2 shows that for some reason an HTTP tunnel is being opened, but doesn't give any indication as to why.

    The Fiddler trace has several occurrences of:

    200 - HTTP - Tunnel to - <siteUrl>:443

    There are no trailing sub-directories on any of these "Tunnel to" events. 


    sysadmin

    Sunday, December 01, 2013 9:52 AM
  • Does Get-SPSite or the Web App/AAM show any use of TCP/443? Again, with your prod environment, that should not be necessary.

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, December 01, 2013 9:55 AM
  • PS C:\> $site | Get-SPSiteURLUrl                              

    URL Zone

    ---                               ----

    http://<siteUrl>                  Intranet

    https://<siteUrl>                 Default

    However, if https is removed from the default zone, web-parts start having all sorts of problems (something went wrong...). When I tried this out first time with http in the default zone, there were countless errors. 

    Also, the web application has an internal and external URL of "https://<serverName>, which was created by default when the web application was created.


    sysadmin

    Sunday, December 01, 2013 10:06 AM
  • May be start over?  You should be able to do HTTP-only on the default URL without errors.  I would definitely remove any AAM that specifies the server name.

    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Sunday, December 01, 2013 2:34 PM
  • Thanks, Trevor. 

    Tried starting over - scheduled some downtime and removed all the HNSC related stuff, including web app, IIS site and app pool. 

    Recreated using HTTP only (*:80 in IIS, web app with http://<servername>, site with HTTP address in default zone), gave me 404's when trying to access the site.

    Removed and recreated again with HTTPS only (*:443 in IIS, web app with https://<servername>, site with HTTPS address in default zone), again got 404's trying to access the site.

    Removed and recreated again as HTTPS but also added *:80 to IIS, also added HTTP address for the site in Intranet zone. This allows access to the site but gives secure content warnings with some ribbon controls, content & structure tool etc.

    This is frankly driving me nuts. Logically, I would think setting everything up as HTTP on the SharePoint side of the load balancer should work. It seems not.

    There are no host file entries on the server, NSLOOKUP resolves the site to the external load balancer IP, so everything is going through the NLB. 

    Anyone have any ideas about what else to try?


    sysadmin

    Tuesday, December 03, 2013 12:44 AM
  • Create the Web Application with a generic address, e.g. http://sp.domain.com and not a server name.  Next, validate the Site Collection URLs are all http://<site>.domain.com.  Obviously if you have any sites that are https://<site>.domain.com, you'll need the SSL binding.

    Did you make sure to create a root site collection at http://sp.domain.com (http://<servername>)?


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    • Proposed as answer by Waqas Sarwar(MCSE 2013) Wednesday, December 04, 2013 3:22 AM
    • Marked as answer by xida Wednesday, December 04, 2013 7:26 AM
    Tuesday, December 03, 2013 12:48 AM
  • Would a "dummy address" do for the web application, ie. anything but the server name or address which is in use? Sharepoint adds the http(s)://servername by default when creating the web app, but I could specify something else.

    I created a 2 root HNSCs with valid URLs, as well as several teamsites under an HN managed path. Nothing path based was created in this web app.


    sysadmin

    Tuesday, December 03, 2013 12:55 AM
  • You just should not use a server name in a SharePoint URL, especially with multiple servers.

    You can only have one root Site Collection per Web Application.  This needs to be at that "dummy" URL.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Tuesday, December 03, 2013 12:56 AM
  • Ok, I'll try recreating using some http://dummy.url for the web application, then (if I understand correctly) create a / site in the web application also called http://dummy.url. 

    This would need to be a path based site collection would it not? Not that that's a problem, just to be clear.

    IIS can remain with a *:80 binding? There will eventually be numerous HNSCs with different URLs in this web application, at least that's the intention.


    sysadmin

    Tuesday, December 03, 2013 1:01 AM
  • It would be a path-based, yes.

    You can leave IIS with *:80 given you're not going to be adding any SSL-enabled sites.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Tuesday, December 03, 2013 1:03 AM
  • Understood!

    Thank you very much, especially for the very quick responses.

    Hopefully I can persuade the client that she needs more downtime tomorrow evening :) I'll update here with the results.


    sysadmin

    Tuesday, December 03, 2013 1:05 AM
  • Thank you, Trevor -  it works! The key seems to be having a root (path-based) site, after that appears it's all cake. Here's what I did:

    # CREATE NEW WEB APPLICATION FOR HNSC

    $webApp = New-SPWebApplication -Name $webAppName -port 80 -ApplicationPool $webAppPool -ApplicationPoolAccount (Get-SPManagedAccount $iisAccount) -AuthenticationProvider (New-SPAuthenticationProvider –UseWindowsIntegratedAuthentication) -Path $path -URL $rootUrl -HostHeader $hostHeader

    # CREATE CONTENT DATABASE

    $contentDb = New-SPContentDatabase -Name $contentDbName -WebApplication $webAppName

    # REMOVE AUTOMATICALLY CREATED CONTENT DATABASE

    Get-SPContentDatabase -WebApplication $webApp # DELETE DATABASE WITH GUID

    # CREATE ROOT SITE COLLECTION (PATH BASED)

    $spSite = New-SPSite -Url $rootUrl -OwnerAlias $owner1 -SecondaryOwnerAlias $owner2 -ContentDatabase $contentDb -Name $name -Template $template

    # DEPLOY ALL NON-GLOBAL FARM SOLUTIONS TO NEW WEB APPLICATION

    # CREATE HOST-NAMED SITE COLLECTION

    $spSite = New-SPSite -Url $httpUrl -OwnerAlias $owner1 -SecondaryOwnerAlias $owner2 -ContentDatabase $contentDbName -HostHeaderWebApplication $webAppName -Name $name -Template $template


    * I used http://host.local as the web app URL and host.local as the host-header. A root site was also created with this URL.

    * the -HostHeader switch for the new web app can probably be left off, otherwise just remove the host-header from IIS like I did, leaving *:80

    * No HTTPS bindings are needed anywhere, finally some logic to the situation :)

    Unfortunately I'm still getting secure content warnings on some admin pages, but I now believe some other issue is afoot. I created a web-application with a path-based site just to see, this also gives secure content warnings. I need to track this down, but I'm now sure it's not related to HNSC config.

    Case closed, thanks for the help. 



    sysadmin

    Wednesday, December 04, 2013 1:13 AM
  • Great, glad it worked.

    Run your sites through Fiddler to see what components are coming over mixed-content. I've heard of this happening with MySites using SSL offload, with no resolution.


    Trevor Seward, MCC

    Follow or contact me at...
      

    This post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Wednesday, December 04, 2013 1:14 AM
  • Thank you!


    sysadmin

    Wednesday, December 04, 2013 1:17 AM