RSSSubscribe  Twitter Follow on Twitter

Chris Coulson's Developer Notes

Tips on .Net, SQL Server, Sharepoint & Windows Phone 7



Mixed Http and Https Content with SharePoint 2010

By Chris Coulson on October 12th, 2011

Have you ever wanted to have mixed https and http content in SharePoint? By that I mean a login page and user pages secured by https, while the rest of the content is delivered unsecured via http. Having the content either all http or all https is a breeze, but I wanted to be able to deliver both, and I ran into problem after problem. Here’s how it’s done, step by step:

Note: This tutorial is going to use the site created in the post Mixed Anonymous and Secure Content with SharePoint 2010.  If you also want your site to have both anonymous and secured content (and I assume you do!), you may want to read that first.

1. Setup Https

I’m assuming that you already have your SharePoint web application setup and operating over Http. The first step is to enable it to operate over https as well.

  • Open IIS and select your SharePoint Web Application from the list of sites.
  • From the right-hand Actions menu, select ‘Bindings…’.
  • From the Site Bindings dialog that opens, click ‘Add…’
  • From the Add Site Binding dialog that opens, choose a type of ‘https’.  This will default to a port of 443.  You also have to select the SSL Certificate to secure the site with (You have to have already purchased an SSL certificate, or generated a private one). Click OK and close the Site Bindings dialog.

2. Configure SharePoint to use Https

In addition to configuring https in IIS, SharePoint also has to be configured to recognize the https address.

  • Open SharePoint Central Admin and select ‘Application Management’, ‘Configure Alternate Access Mappings’
  • Select your Web Application from the ‘Alternate Access Mapping Collection’.
  • Click ‘Add Internal URLs’
  • Enter the https URL for your site.  Make sure that the same zone is selected that you access the http version of your site from.
  • Click OK.

If you try to browse the site, you’ll notice that you can now browse the site from both the http and the https addresses. There are still a couple of issues though. While browsing the https version of the site, some actions (such as signing out) will bring you back to the http version of your site.  Also, if you login using https and then browse an http page, you’ll notice that you’re no longer logged in. We’re going to fix these issues in the next couple of steps.

Note: If you want ALL of your site content to be delivered via https, and don’t care about mixed content: instead of adding an internal URL, simply edit the public URLs and change the address to https and YOU’RE DONE! No need to continue with the rest of this tutorial.

This is also the step that caused me the most grief when initially configuring my SharePoint site for mixed http and https.  I had initially placed my https URL under the Custom zone of Edit Public URL’s. Since I only had one actual zone (the default zone, as I hadn’t extended the web application into multiple zones), the URL in the custom zone would point to it, which I thought would be OK.  However with this configuration I was always asked to authenticate when switching between http and https.  The problem was that even though there is only one REAL zone, SharePoint was interpreting the address change as switching between the default and custom zone and was forcing the user to re-authenticate.   This is why we add an internal URL for SharePoint to recognize, instead of editing the public URL’s.

3. Configuring SharePoint’s Authentication Cookie

Notice that even if you authenticate via https, your authentication isn’t recognized when you switch over to http. The reason for this is because SharePoint has hard-coded logic that says if it’s generating an authentication token for an https connection, then turn on the SSL Only flag on the cookie. An SSL Only flag means that the cookie can only be accessed via https. So as soon as you change the address to http, your authentication cookie is no longer recognized and you have to login again.

Tim Nugiel found the solution to this problem. He wrote his own cookie handler that override’s SharePoint’s behaviour. See his post for directions on configuring this:

Mixing it up w/ Mixed SSL & SP 2010  (The original link appears to have gone offline)

Mixing it up w/ Mixed SSL & SP 2010

You should now be able to authenticate via https, and stay authenticated while browsing content either via http or https – we’re almost there!

4. Redirecting users to Http or Https

The only issue remaining is forcing certain content to be viewed via http or https. Right now users can access your login page via https, but there’s nothing forcing them to.  They could also access it via http.  The same goes for any other content you want to secure.  To solve this problem we’re going to set up some redirect rules using the IIS 7 URL Rewrite module.

  • Install the IIS7 URL Rewrite module. You can download it from here: http://www.iis.net/download/urlrewrite
  • Open IIS and select your SharePoint Web Application from the list of sites.
  • Open the Url Rewrite module from the Features View.
First we’ll add a rule to redirect secure content to https. For this example our secure pages will be the login page and the pages in our ‘User’ site:
  • Click Add Rules…
  • Select ‘Blank Rule’ under ‘Inbound Rules’ and click OK.
  • Fill in the name with ‘HTTP to HTTPS Redirect’.
  • Set the Pattern to: ^(_forms/default.aspx|user/pages/.*aspx)
  • Add the condition: Input: {HTTPS} Check if input string: ‘Matches the Pattern’ Pattern: off
  • Set the Action Type to ‘Redirect’
  • Set the Redirect Rule to: https://demo2010a/{R:0} (Substitute for your own url)
  • Set the Redirect Type to ‘Permanent (301)’
  • Click ‘Apply’ and click ‘Back to Rules’.

What the rule we created says is:

If the url starts with /_login/Default.aspx (The default FBA login page) or /User/Pages/anypage.aspx (any page in the Pages library of our User site) AND if https is not being used THEN send back a Permanent Redirect to the https URL, using the original URL after the server address.

Now we’ll create a second rule that says all of the pages on the main site should be accessed via http.  The reason we need this rule is because once we’re browsing over https, any relative URLs in the page will also be accessed over https.  So if we want certain pages to be consistently delivered over http, we need a rule to force this:

  • From the IIS Rewrite module, add another blank inbound rule.
  • Fill in the name with ‘HTTPS to HTTP Redirect’.
  • Set the Pattern to: ^pages/.*aspx
  • Add the condition: Input: {HTTPS} Check if input string: ‘Matches the Pattern’ Pattern: on
  • Set the Action Type to ‘Redirect’
  • Set the Redirect Rule to: http://demo2010a/{R:0} (Substitute for your own url)
  • Set the Redirect Type to ‘Permanent (301)’
  • Click ‘Apply’ and click ‘Back to Rules’.

What the rule we created says is:

If the url starts with /Pages/anypage.aspx (any page in the pages library of our root site) AND if https is being used THEN send back a Permanent Redirect to the http URL, using the original URL after the server address.

This is just a simple example of what can be done with the IIS Rewrite Module.  It is very powerful and allows to you to develop very complex rules that can handle almost any redirection you’d like.

That’s it! You’re done! You can now login to your site over https and force content to be read over http or https based on rules.

I want to thank Tim Nugiel for taking time out of his busy day to help me troubleshoot issues I was having getting this to work. Tim had the only working example of this that I was able to find on the internet.  He also developed the SSL Only cookie handler solution. Thanks for all your help Tim!

Categorized under: Configuration, Sharepoint.
Tagged with: alternate access mappings, Anonymous, authenticate, authenticated, Authentication, authentication cookie, authentication token, central admin, content, cookie, cookie handler, http, https, IIS, internal urls, logged in, login page, mixed, mixed content, public urls, redirect, redirect rules, redirection, rule, secure, secured, SharePoint, Sharepoint 2010, ssl, ssl certificate, ssl only, token, url, url rewrite.

25 Responses to “Mixed Http and Https Content with SharePoint 2010”

  1. Tom DeVoe says:
    November 11, 2011 at 9:56 am

    Thank you for putting this article together. It’s a great service when people take the time to share this information. I’m in the process of trying to do the same – just have to find the time 🙂

    Respond
  2. Tom DeVoe says:
    November 11, 2011 at 2:49 pm

    I’ve implemented the IIS URL Rewrite rules together with the code modifications required (extending the SPChunkedCookieHandler).

    When I go to my site (development site on test server), it comes up fine (http). Click on SIGNIN and it hits the overwritten SPChunkedCookieHandler.DeleteCore method. The login page is displayed correctly (https).

    When you login, it hits the SPChunkedCookieHandler.WriteCore which flips the secure value from true to false. This all works fine.

    If I specify an additional page to flip to https (in IIS URL Rewrite rule) after the user is logged in (e.g. purchase.aspx), I get “The page cannot be displayed”. The error in the IIS log has the following error codes at the end of the log entry “301 0 0 203”. If I’m interpreting this correctly, the 203 is “The information received is not from the server that the information was requested from, but from another source.” Is this because the WriteCore method is not hit and the secure value not toggled? Doesn’t the token have to be set to true or false depending on whether going from http -> https or https -> http?

    Thanks for your help . . .

    Respond
    • Chris Coulson says:
      November 11, 2011 at 9:28 pm

      I’m not sure if you mean the SSL Only flag on the cookie, or the HTTPS flag on the rewrite rule.

      The SSL Only flag on the token should always be set to false. Setting it to true means that the value will only be accessible via an https session, so the token will no longer exist as soon as you change to http.

      As for the rewrite rule, you use the HTTPS flag to decide whether to run the rule. You’d only want to run an HTTPS -> HTTP rule if the HTTPS flag was true, and vice versa.

      To determine if the rewrite rule is causing the error, turn off the url rewriting and see if you can flip between the addresses manually. If you can, then there’s a problem with your rewrite rules.

      Respond
  3. Tom DeVoe says:
    November 14, 2011 at 2:05 pm

    I just typed up a scenario and question to better understand the secure cookie flag being passed into the WriteCore method and then I realized what you’re saying.

    The secure flag doesn’t act as a toggle but allows the cookie to be used both as a secure and non-secure cookie. I was thinking that a secure cookie would be used and then a non-secure cookie would be used (thus invalidating the secure cookie) and so on and so on . . . This didn’t make any sense to me.

    As you suggested, I will look at my rule definitions since it seems the problem is there.

    Thanks again for you help.
    Tom

    Respond
  4. Tom DeVoe says:
    November 14, 2011 at 7:01 pm

    I got it to work. Here is what I found. I had originally created a document library below the Pages document library called secure. For the HTTP->HTTPS rule, I had
    ^(_layouts/customloginpage.aspx|Pages/secure/.*aspx)
    and for the HTTPS->HTTP rule, I had ^pages/.*aspx. The pages in the secure doc library would not display with the error I had mentioned in my earlier response.

    I eventually created a doc library (called secure) at the same level as the Pages doc library and changed my HTTP->HTTPS rule to
    ^(_layouts/customloginpage.aspx|secure/.*aspx) and this works perfectly.

    I’m not sure whether this problem is with SharePoint or my IIS rules. The IIS rules seem pretty straight forward so I don’t think it’s the rules. Well, we can always blame it on SharePoint 🙂

    Thanks one more time for your help.
    Tom

    Respond
  5. Zeb Sadiq says:
    January 16, 2012 at 5:57 am

    Hi Chris,

    Thanks for your excellent post here, it helped me a lot. It took me ages to find it for some reason. Thats why I’ve written my own post, sharing my experience with a link this post. You can find it here.

    http://blog.zebsadiq.com/post/Achieving-partial-mixed-mode-(http-and-https)-FBA-in-SharePoint-2010.aspx

    Thanks again,
    Zeb

    Respond
  6. Fadi says:
    January 30, 2012 at 7:11 am

    Thanks for your nice post ^-^

    Respond
  7. Hemant Kumar says:
    March 20, 2012 at 10:18 am

    I followed below mentioned links :
    http://www.sp2010hosting.com/Lists/Posts/Post.aspx?ID=5

    2. http://blogs.visigo.com/chriscoulson/mixed-http-and-https-content-with-sharepoint-2010/

    3. http://www.sharepointconfig.com/2010/04/partial-ssl-sharepoint-sites-login-over-http-from-http-pages/

    In my case cookie FeAuth is set back to Http , but user is not actually logged in.

    Steps I followed:

    1. Extended the current setup on SSL . Made it working similar to the default zone application ( including resource files and web.config entries,manual dll etc.)

    2. Set the postback url for login button.

    3. Made the URL rewrite entries as suggested in both zones. ( these are spread across multiple links, REQUEST_METHOD is additional to https ON rule) URL rewriting can be done very easily with an IIS extension provided by Microsoft.

    4. Created the custom handler as suggested and replaced it with SharePoint one.

    5. Set the required SSL for cookies to false, so that they may be used on non ssl also.

    Respond
    • Hemant Kumar says:
      March 23, 2012 at 2:20 pm

      Related post :
      http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/2a3ac89e-334b-4341-9f8e-dc9a01962466/#ea01e65f-5f7d-4d12-8c6e-0d131d2ccb67

      Respond
  8. Hemant Kumar says:
    March 23, 2012 at 2:20 pm

    Related post :
    http://social.msdn.microsoft.com/Forums/en-US/sharepoint2010general/thread/2a3ac89e-334b-4341-9f8e-dc9a01962466/#ea01e65f-5f7d-4d12-8c6e-0d131d2ccb67

    Respond
  9. sathish says:
    January 7, 2013 at 3:12 am

    Great article. Very nice information.
    Thanks a Ton

    Respond
  10. Soeryana says:
    April 8, 2013 at 6:57 pm

    Hi,

    Very nice article. However, if we want to use ADFS 2.0 for the authentication solution, is it possible to apply this method by only using HTTPS to perform the authentication to ADFS server and switch back to HTTP once the user is authenticated and authorized to access the Sharepoint site? Is the cookie produced by ADFS going to be work over HTTP?

    Thanks in advance if you have ever done it.

    Respond
    • Chris Coulson says:
      April 9, 2013 at 12:29 am

      I’ve never worked with ADFS myself, but I would expect the steps in the above article to work the same. Let us know how it goes.

      Respond
  11. Matthieu says:
    September 11, 2013 at 9:34 am

    Just one note on step 3. From a security perspective, it’s a bad idea to send authentication cookies over an HTTP connection.
    An attacker could steal it (especially when using a public Wifi connection), and use it to usurp the user’s identity.
    The rest of the post is very interesting.

    Respond
  12. John Seal says:
    March 20, 2014 at 4:31 pm

    Hi,
    Tim Nugiel’s solution is not opening. Could you give me working url? Thanks for the article

    Respond
    • Chris Coulson says:
      March 20, 2014 at 11:08 pm

      Yeah, it looks like his whole site is down. Hopefully it will be up soon. In the meantime, you can check the google cache results:

      http://webcache.googleusercontent.com/search?q=cache:RlmcILZXJjEJ:www.sp2010hosting.com/lists/posts/post.aspx%3Fid%3D5+&cd=2&hl=en&ct=clnk

      Respond
  13. Pam Justice says:
    June 27, 2014 at 10:55 am

    This is a wonderful post. Is there a similar solution for II6 used with Sharepoint 2007?

    Respond
    • Chris Coulson says:
      June 27, 2014 at 9:37 pm

      Not that I know of. The IIS setup should be the same. The only thing that might be different would be the cookie handler. Of course maybe you’ll be lucky and SharePoint 2007 won’t mark the cookie SSL only.

      Respond
  14. Achraf Amine says:
    November 5, 2014 at 2:15 am

    i m trying to open Tim Nigiel solution is not opening even the google cache results, can you please provide me with the steps cooking handler

    Respond
    • Chris Coulson says:
      November 5, 2014 at 10:04 am

      Thanks for letting me know! I managed to find a cached page of the article and reposted it here. The article has been updated.

      Respond
      • Achraf Amine says:
        November 11, 2014 at 5:31 am

        Thanks a lot for your quick reply

        Respond
  15. Dave says:
    November 9, 2014 at 3:02 pm

    Great article, but have you tried getting the entire SP farm with Mysites and Office Web Apps server to work under http internal network and https external (internet access)? I’m working on a new build, have been searching all over for SP, mysites and office web apps all configured for HTTP and HTTPS, and I haven’t found one article on it. It also appears office web apps will only work with either HTTP or HTTPS, so I’m going to have to configure the entire farm for HTTPS. Poor documentation by Microsoft and none of the fixes i’ve tried for Office web apps work.

    Respond
    • Chris Coulson says:
      November 9, 2014 at 8:17 pm

      I have not tried this with Office Web Apps.

      Respond

Leave a Response

Click here to cancel reply.

Trackbacks

  1. Mixing it up w/ Mixed SSL & SP 2010 | Chris Coulson's Developer Notes says:
    November 5, 2014 at 9:58 am

    […] creating a custom cookie handler for mixed mode authentication.  I reference it in my blog post Mixed Http and Https Content with SharePoint 2010. The original article was posted at: http://www.msngn.com/blog/lists/posts/post.aspx?id=5. […]

    Reply
  2. Redirect from HTTP to HTTPS using the IIS URL Rewrite module | Damian Wiese says:
    June 7, 2016 at 2:28 pm

    […] Mixed Http and Https Content with SharePoint 2010 http://blogs.visigo.com/chriscoulson/mixed-http-and-https-content-with-sharepoint-2010/ […]

    Reply
← Mixed Anonymous and Secure Content with SharePoint 2010
Bulk Delete ASP.NET Membership Users →

Recent Activity

  • Posts
  • Comments
  • SharePoint FBA: SSL Required
  • SQL Server Spatial Data: Finding and Ordering Distance Between 2 Points
  • Now Hosting Inline Styler for Emails
  • SharePoint 2016 compatible version of the SharePoint Solution Installer released
  • Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 – Part 4 – Adding Users to the Membership Database
  • Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 – Part 3 – Configuring SharePoint
  • Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 – Part 2 – Editing the Web.Config Files
  • Configuring Forms Based Authentication in SharePoint 2016, SharePoint 2019 and SharePoint Subscription Edition – Part 1 – Creating the Membership Database
  • SharePoint 2016 FBA Pack Released
  • Mixing it up w/ Mixed SSL & SP 2010
  • Tim on Configuring Forms Based Authentication in SharePoint 2016, SharePoint 2019 and SharePoint Subscription Edition – Part 1 – Creating the Membership Database
  • ImplementingSolution on SSD Freezing Fix
  • Chris Coulson on Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 - Part 2 - Editing the Web.Config Files
  • Steve Johns on Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 - Part 2 - Editing the Web.Config Files
  • Zer0Byte1 on SSD Freezing Fix
  • Chris Coulson on Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 - Part 2 - Editing the Web.Config Files
  • Irfan Khan on Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 - Part 2 - Editing the Web.Config Files
  • Chris Coulson on Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 - Part 2 - Editing the Web.Config Files
  • Sampath on Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 - Part 2 - Editing the Web.Config Files
  • Chris Coulson on Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 - Part 4 - Adding Users to the Membership Database

Archives

  • Categories
  • Tags
  • Dates
  • Authors
  • .Net
    • ASP.NET
    • ASP.Net Membership
    • Performance
  • Amazon Web Services
    • EBS
    • EC2
  • Hardware
  • HTML, CSS & Javascript
  • Other
  • Sharepoint
    • Administration
    • Configuration
    • Development
    • Forms Based Authentication
    • Localization
    • Performance
    • Search
    • SharePoint Designer
  • SQL Server
    • Reporting Services
    • Spatial Data
  • Uncategorized
.Net ASP.Net asp.net membership aspnetdb ASPX Assemblies Authentication central admin change password CodePlex deployment FBA FBA Pack Forms Based Authentication global assembly cache IIS javascript Localized machine.config MediaElement.js Membership membership provider package Performance register Resource role management SharePoint Sharepoint 2010 SharePoint 2010 FBA Pack SharePoint 2013 SharePoint 2013 FBA Pack SharePoint 2016 SharePoint 2016 FBA Pack SharePoint 2019 SharePoint 2019 FBA Pack SharePoint FBA Pack sqlmembershipprovider sql server user management users video visual studio web.config web part
  • July 2022 (1)
  • February 2020 (1)
  • January 2018 (1)
  • November 2017 (1)
  • May 2016 (5)
  • November 2014 (1)
  • May 2014 (1)
  • March 2014 (2)
  • January 2013 (5)
  • December 2012 (1)
  • November 2012 (1)
  • July 2012 (1)
  • June 2012 (3)
  • November 2011 (3)
  • October 2011 (2)
  • August 2011 (4)
  • June 2011 (2)
  • April 2011 (2)
  • March 2011 (1)
  • Chris Coulson (38)

Tags

.Net ASP.Net asp.net membership aspnetdb ASPX Assemblies Authentication central admin change password CodePlex deployment FBA FBA Pack Forms Based Authentication global assembly cache IIS javascript Localized machine.config MediaElement.js Membership membership provider package Performance register Resource role management SharePoint Sharepoint 2010 SharePoint 2010 FBA Pack SharePoint 2013 SharePoint 2013 FBA Pack SharePoint 2016 SharePoint 2016 FBA Pack SharePoint 2019 SharePoint 2019 FBA Pack SharePoint FBA Pack sqlmembershipprovider sql server user management users video visual studio web.config web part

Links

  • SharePoint 2010 FBA Pack
  • SharePoint 2013 FBA Pack
  • Visigo Software Consulting
My LinkedIn Profile Connect On Facebook

    Recent Posts

    • SharePoint FBA: SSL Required
    • SQL Server Spatial Data: Finding and Ordering Distance Between 2 Points
    • Now Hosting Inline Styler for Emails
    • SharePoint 2016 compatible version of the SharePoint Solution Installer released
    • Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 – Part 4 – Adding Users to the Membership Database

    Recent Comments

    • Tim on Configuring Forms Based Authentication in SharePoint 2016, SharePoint 2019 and SharePoint Subscription Edition – Part 1 – Creating the Membership Database
    • ImplementingSolution on SSD Freezing Fix
    • Chris Coulson on Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 – Part 2 – Editing the Web.Config Files
    • Steve Johns on Configuring Forms Based Authentication in SharePoint 2016 and SharePoint 2019 – Part 2 – Editing the Web.Config Files
    • Streaming MP4 video through .NET HTML5 on Easy Handling of Http Range Requests in ASP.NET
Powered by WordPress and the PressPlay Theme
Copyright © 2023 Chris Coulson's Developer Notes