locked
Mixed Content Warnings RRS feed

  • Question

  • Hi All -

    This issue is driving me nuts, I'm getting mixed content warnings only when accessing certain tools in the site settings menus, otherwise everything else is working - here's the scenario :

    - SharePoint 2013 3-tier farm behind an NLB providing SSL termination. Client requests via HTTPS, SSL is decrypted and forwarded by the NLB to IIS as HTTP. Original header intact.

    - IIS website is configured as HTTP, catch-all with no host-header, listens on :80

    - Web application contains host named site collections. Created via Powershell as follows :

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

    - A root site collection as created (path-based of course) as follows :

    $spSite = New-SPSite -Url $url -OwnerAlias $owner1 -SecondaryOwnerAlias $owner2 -ContentDatabase $dbName -Name $name -Template $template -Language $lcid

    - Host names site collections are then created similarly, except using the -HostHeaderWebApplication parameter. HNSCs seem to be working just fine, they're accessible through the NLB and appear to work just fine...

    ...except certain tools in the site settings menu, where I get a mixed content warning - for example :

    - Content & Structure gives me a mixed content warning. The browser console tells me it's trying to open 

    http://<host>/_layouts/15/1033/styles/corev15.css

    and

    http://<host>/_layouts/15/1033/styles/SiteManagerCustomStyles.css

    I get similiar errors for some ribbon controls, for example the Site Collection Administrators tool which wants to open this via HTTP:

    http://<host>/_layouts/15/mngsiteadmin.aspx?IsDlg=1

    Many other tools in Site Settings work just fine.

    Now, I've tried the following :

    - I tried doing everything the opposite way around. Created the web application with SSL enabled. Created the root site as HTTPS, created the HNSCs as HTTPS. Added a secondary URL to the HNSCs via PowerShell as HTTP (Intranet Zone). Configured IIS to listen to :80. This actually works, but has exactly the same errors with Content & Structure etc. In other words no change.

    I'm not sure what else I can try.

    Has anyone got any experience with this issue?

    Friday, August 1, 2014 8:48 AM

Answers

  • Hi Izvor,

    It is the stingray not interpreting/amending the return html.  With out the StingRay, the html is correctly returning all urls with the http prefix.  The device should rewrite all internal(current website urls to https). 

    It is re-writing the urls for other internal links in the site correctly.  Speak to StingRay, this is a SSL-Term issue not a SharePoint issue.  SharePoint is returning the correct data and the device is not re-writing correctly.  I have had this on another hardware device manufacturer and they talked the customer thru amending the settings until it started working.

    • Proposed as answer by paulb32 Thursday, August 28, 2014 8:18 AM
    • Marked as answer by Izvor Thursday, September 18, 2014 6:41 PM
    Thursday, August 28, 2014 8:17 AM

All replies

  • Have you used Fiddler to identify what resources are arriving over HTTP when browsing via SSL?

    Trevor Seward

    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, August 6, 2014 4:57 PM
  • Hi Trevor -

    Yes, I did use Fiddler - it gives me the same two files which the IE "F12" browser console indicates as being requested via HTTP

    http://<host>/_layouts/15/1033/styles/corev15.css

    and

    http://<host>/_layouts/15/1033/styles/SiteManagerCustomStyles.css

    I would really like to be able to resolve this as the number of web applications in my farm is getting too high, and I would very much like to switch to using host-named site collections.

    Any ideas?

    Thursday, August 7, 2014 5:49 AM
  • Hi All -

    Does anyone have any thoughts on this issue?

    I now have 20 web applications in my farm which is somewhat worrying, with HNSCs I could reduce this to around three or four web apps, but I cannot use HNSCs because of this mixed content issue.

    I'm hesitant to allow HTTP connections in the Intranet Zone (which would stop the mixed content warnings) as this would likely be a huge security risk.

    Thanks.

    Tuesday, August 26, 2014 8:28 AM
  • Is there a customized master page making calls to these CSS files?

    I believe there was a similar issue on SharePoint 2010 with MySites -- it was returning the HTTP path rather than SSL. I'm not sure if anyone resolved that besides just forcing SharePoint to SSL-only.


    Trevor Seward

    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, August 26, 2014 1:24 PM
  • Thanks for the response, Trevor.

    I considered whether it was due to customization, so created a web application and added a root site collection and a host-named site collection using vanilla components only - there was no change, tools such as Content & Structure still throw mixed content warnings.

    This leads me to believe it's the environment at fault, but I don't see how.. everything else works just fine. I don't get this issue with path-based site collections and I don't really see what the difference could be when using host-named.

    You mentioned forcing SSL - how does this work? Do you mean on-box SSL termination or is there some trick we can use?

    Tuesday, August 26, 2014 2:11 PM
  • Yes, SSL back to the SharePoint server(s).

    With modern processors, SSL isn't much of an impact (often measured in 1 - 2% CPU usage, at the most).

    The alternative is to raise a case with Microsoft PSS and see what they can help with. If it is only these two files and all other files under _layouts are coming across with SSL properly, it certainly sounds like a product issue.


    Trevor Seward

    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, August 26, 2014 2:13 PM
  • We had a similar issue with setups in SharePoint 2007 and 2010 when mixing HTTP and HTTPS on the same SP site.  Over time, it became clear that HTTPS was fine to use all the time.  When we create web apps now, we use only HTTPS(443) with host headers and make sure that any alternative access mappings use HTTPS.  Then in IIS, we create a separate website that listens on port 80 for the same host header and have it redirect to the HTTPS site.  We don't publish the HTTP site, but it's there just in case someone types it in manually.  Haven't had issues for years now!

    For your issue, you might want to look at the default and intranet alternate access mapping URLS.  Some of the native SharePoint functionality pulls from these addresses.

    TEMPORARY WORKAROUND FOR USERS

    When we had this issue initially, we simply set the I.E. settings for the Intranet Zone to allow mixed content.  I believe there are similar settings for Firefox and Safari.  Since our sites are tied to this zone, this allowed our users to navigate the various SharePoint sites without receiving this warning.  Just a thought!

    Tuesday, August 26, 2014 2:45 PM
  • Hi Izvor,

    What device are you using for SSL termination?  I'm kind of lost if you are using SSL termination on a device or on the SharePoint front ends.  I have seen hardware load balancers incorrectly re-write urls and https for SharePoint 2013 and 2010.

    As Trevor suggested use fiddler but use it once directly between the browser on port 80 (i.e. on the FE with a host file matched to the HNSC) and then check using Fiddler using SSL i.e. after SSL is readded to the request.

    paul

     

    Tuesday, August 26, 2014 3:12 PM
  • Thanks Trevor

    Moving SSL termination on to the WFEs isn't a decision I can take lightly unfortuantely, I have 77k users which are using this farm to consider and would have to go through some fairly rigorous performance testing before doing this - plus it might be hard to convince the powers that be that a seemingly perfectly good NLB isn't doing the job for SharePoint.

    Wednesday, August 27, 2014 8:06 AM
  • Thanks IT Happens

    This is how I have it set up at the moment (kind of backwards to how the textbook setup goes with regard to HTTPS/HTTP config).

    Previously I've been creating path-based site collections as HTTPS only in web-applications with SSL enabled. IIS has host-headers and only listens on :80. This all works just fine, but if I do the same thing with host-named site collections (create in an SSL enabled web app using HTTPS only, listening :80 in IIS etc.) I get the mixed-content warnings in some admin tools.

    Wednesday, August 27, 2014 8:11 AM
  • Thanks Paul

    Off-box SSL termination using a Stingray. I'll try what you suggested with Fiddler.

    Wednesday, August 27, 2014 8:12 AM
  • Also, changed IE settings to anything other than default (not to mention Chrome, Mozilla, Safari etc.) isn't really an option. I have a user base of 300k users, 77k of which are using this platform. That's a big job, politically and technically.

    I'm still hesitant to add HTTP into the intranet zone for security reasons, the platform is accessible via the Internet.

    Wednesday, August 27, 2014 8:15 AM
  • Here's the exact source of the error.. the rendered HTML from sitemanager.aspx (Content & Structure Tool):

    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
    <HTML dir="ltr">
    <HEAD><meta name="GENERATOR" content="Microsoft SharePoint" /><meta name="progid" content="SharePoint.WebPartPage.Document" /><meta HTTP-EQUIV="Content-Type" content="text/html; charset=utf-8" /><meta HTTP-EQUIV="Expires" content="0" /><meta http-equiv="X-UA-Compatible" content="IE=9" /><title>
    	
    	Site Content and Structure
    
    </title><link rel="stylesheet" type="text/css" href="http://<host>/_layouts/15/1033/styles/corev15.css" /><link rel="stylesheet" type="text/css" href="http://<host>/_layouts/15/1033/styles/SiteManagerCustomStyles.css" /><script type="text/javascript" src="/_layouts/15/init.js?rev=o3x4BawuFCjTeVJ32Sy7bw%3D%3D"></script>
    <script type="text/javascript" src="/_layouts/15/1033/initstrings.js?rev=uNmvBiHdrBzcPQzXRpm%2FnQ%3D%3D"></script>
    <script type="text/javascript" src="/_layouts/15/1033/strings.js?rev=DY9A0USYODVw86N0trJTSw%3D%3D"></script>
    
    

    When I examine the same rendered HTML from a path-based site collection, I still get absolute URLs for corev15.css and SiteManagerCustomStyles.css, but prefixed with HTTPS (so no problem there).

    I wonder if there's any way I can force these absolute URLs to be HTTPS or force them to be relative URLs like everything else which follows.

    Wednesday, August 27, 2014 9:30 AM
  • Hi Izvor,

    Compare the returned html on both sides of the StingRay, this will tell us if the StingRay is the issue or if we need to do a workaround in SharePoint.

    Wednesday, August 27, 2014 10:09 AM
  • Thanks Paul

    If I bypass the NLB and go straight to the server I get the following results :

    Since IIS is already listening to HTTP:80 no additional config is required to get a response using HTTP to access the host-named site. HTML is rendered giving absolute links with an HTTP prefix in the sitemanager.aspx source (probably as expected, and same result as via the NLB)

    To access the site using HTTPS:443, I added a :443 binding and a self-signed cert into IIS (otherwise the page won't respond). The rendered HTML in sitemanager.aspx now has absolute links using HTTPS.

    I'm not certain whether this proves the NLB is at fault since I had to make config changes in IIS to test the issue with both protocols, and I guess the results are as expected with the new config.

    Wednesday, August 27, 2014 10:46 AM
  • Hi Izvor,

    Reading your reply I think you are not doing the right test, I don't think you want to enable SSL on IIS you are changing the test criteria/problem.

    Please sent/post me these 2 html snippets:

    1) You have choices fiddler before the StingRay and fiddler after the stringRay and send me the 2 html snippets.

    Or 2)use a host entry and go to port 80 on the SP server, copy the html sippet, and then remove the host entry and go thru the Stringray capturing the html. 

    This way we can see the difference.  Both test are a way of getting the difference caused by the StingRay/NLB.

    paul

    Wednesday, August 27, 2014 2:24 PM
  • Thanks Paul -

    That's what I did... except instead of using the HOSTS file on the server itself, I used the HOSTS file on my PC to bypass the load balancer. Your two tests were run as follows :

    1) Accessing the HNSC directly from the server using HTTP (bypassing the load balancer)

    2) Accessing the HNSC via the load balancer (as normal)

    Both return exactly the same rendered HTML with absolute URLs prefixed with HTTP.

    <link rel="stylesheet" type="text/css" href="http://<host>/_layouts/15/1033/styles/corev15.css" /><link rel="stylesheet" type="text/css" href="http://<host>/_layouts/15/1033/styles/SiteManagerCustomStyles.css" />

    I also ran a third test which was accessing the HNSC directly from the server (bypassing the NLB), but for this I had to change the config in IIS to get the site to respond (probably a useless test, but I ran it anyway :)

    Wednesday, August 27, 2014 2:33 PM
  • Hi Izvor,

    It is the stingray not interpreting/amending the return html.  With out the StingRay, the html is correctly returning all urls with the http prefix.  The device should rewrite all internal(current website urls to https). 

    It is re-writing the urls for other internal links in the site correctly.  Speak to StingRay, this is a SSL-Term issue not a SharePoint issue.  SharePoint is returning the correct data and the device is not re-writing correctly.  I have had this on another hardware device manufacturer and they talked the customer thru amending the settings until it started working.

    • Proposed as answer by paulb32 Thursday, August 28, 2014 8:18 AM
    • Marked as answer by Izvor Thursday, September 18, 2014 6:41 PM
    Thursday, August 28, 2014 8:17 AM
  • Thanks.. I see what you're saying, but this all seems a bit odd to me.

    If I examine the rendered HTML from a path-based site collection, internal absolute URLs are returning as HTTPS - so they're all working correctly.

    It's only with HNSCs that this doesn't work.

    Why is the load balancer behaving differently between PBSCs and HNSCs? Both varieties are set up "the same" in that they both listen to :80 only in IIS, the web applications are all SSL enabled and the site collection URLs are all HTTPS - pretty much identical configuration for both HNSCs and PBSCs. I don't see where the difference could be with regard to how the load-balancer processes these sites.

    It would seem to me that the host-named site-collections "think" they are HTTP sites, and the path-based ones "think" they are HTTPS, and because of that the rendered HTML is coming back wrong.

    Nonetheless, I've taken your advice and have contacted the infrastructure team in order to examine the load balancer. I'll post back results here, hopefully soon.

    Thursday, August 28, 2014 9:39 AM
  • I definitely think the team managing the SSL termination device should figure out why the html is not being re-written correctly for the HNSC.

    There has to be a difference in why the "PBSC" is behaving differently thru the load balancer device than the host name site collection site.  I had a Kemp that was not re-writing html hyperlinks to use SSL and it was to do with the way the link was written, the Kemp owner once the saw the issue change the device to pick up for the differing scenario.

    Anyway, good luck and do let me know how you solve.

    Thursday, August 28, 2014 10:56 AM
  • Understood.  We have the IE Security settings enforced via Group Policy in a Microsoft environment, so it's easy for us to deploy the browser fix for mixed content warnings.  But not all environments are managed this way, so I understand the headache.  I'm sure the other resources on this topic will help provide a workable solution.
    Saturday, August 30, 2014 9:34 PM
  • Implementing response rules on the load balancer solved the problem.

    Who knows why HNSCs "think" they're HTTP when PBSCs seem happy to "pretend" they're HTTPS (in both cases they're set up in an SSL enabled web application and have HTTPS URLs in their default zones). Nonetheless, this can be fairly easily fixed with response rules to rewrite URLs in the returned HTML content.

    Thank you paulb32 and everyone else for your help.

    Thursday, September 18, 2014 6:45 PM