I'm using SharePoint 2016.

I would like to enable and force redirect to HTTPS, and I have followed this solution https://sharepoint.stackexchange.com/a/209004/20605 and seems to work fine when users access the SharePoint site from the "main" URL like http://myportal.mydomain.tld. They are automatically redirected to https://myportal.mydomain.tld.

I've noticed a problem with users that are using bookmarks saved with HTTP protocol: SharePoint is prompting authentication from HTTP and serve the page on HTTP when the user log in.

Then, when the user returns to the home page, the HTTPS redirect works and a new authentication panel is prompted.

My goal is to immediately redirect user from HTTP to HTTPS and, eventually, prompt the authentication panel. How can I immediately redirect to HTTPS?

PS: I've also tried some solutions with URL Rewrite in IIS, but these methods are always returning TOO_MANY_REDIRECTS error.

  • Its easy, remove HTTP binding from IIS, send all users information email, that new security is the Cause, create a short manual for editing bookmarks to https from http. There is no easy way. Employees must adapt. Commented Jan 30, 2019 at 9:06

2 Answers 2


As mentioned in the comments, this solution does not redirect every deeplink within SharePoint.

URL Rewriting in IIS also gives a bunch of drawbacks (i.e. Outlook doesn't follow redirects if you connect a contact list).

Switch existing environments from HTTP to HTTPS is always a bit of pain. As i haven't found a perfect technical solution yet, lots of things need to be resolved in support.


I ran into the same issue on our 2013, 2016, and 2019 farms, and there seem to be drawbacks with every method. As you say, if you change the public URL to be HTTPS and add the internal as HTTP and setup IIS bindings, this does not accomplish a true redirection. It's not just saved links that do not redirect - you can make it happen simply by changing the URL manually in your browser on some pages, too.

Literally the only way we have solved this with minimal disruption to users (no retraining!), and minimal drawbacks is to do it with a load balancer (LB), even if you only have one WFE server. I know this isn't an option for everyone, but I'll offer this up for those that may be able to take advantage of it.

Most LB vendors have procedures for setting them up with SharePoint, but here's what we did on four of our farms (2013 & 2016, but soon to be 2019, and I don't anticipate any differences):

Setup a VIP on the LB, and put your WFE(s) into a LB pool as members. Add A record(s) in DNS to aim your web app URL(s) at the VIP. Install your certificate(s) on the LB, setup the LB to terminate the SSL tunnels with clients (SSL offloading), and setup a HTTP > HTTPS redirect rule.

All client traffic to your web app URLs will then occur over SSL to your LB, but the traffic between the LB and your WFE(s) will occur over HTTP.

At this point, it probably seems like you could avoid installing the cert and setting up HTTPS on your SharePoint servers because you are terminating SSL on the LB, but that only covers client traffic.

You also need to cover intra-farm traffic, so in SharePoint, install your certificate(s), setup your public URL as HTTPS, with an internal URL of HTTP, both in the default zone. Setup IIS bindings for both HTTPS and HTTP on your WFE(s), and change the Search content source URLs, MySites host, search center urls, etc., to HTTPS.

For multi-server farms, add hosts file entries on your search servers to aim the web app URLs at the internal IP of the WFE that you want to have them index - this keeps search traffic from traversing the LB. In a farm with 2 WFEs and 2 Search servers, I aim the web app urls on search server 1 at WFE 1, and search svr 2 at WFE 2. Or, if you have a dedicated WFE for search that's outside your LB, you're probably already aiming your search servers at that WFE server.

Because the SharePoint farm has the HTTPS and HTTP AAMs and bindings, this means you are also easily able to bypass the LB whenever you need to test something. Just change the hosts file on your PC to aim directly at the IP of one of your WFEs, and your path will not go through the LB, but you'll still be able to do either HTTP or HTTPS. That's hugely useful in cases where you suspect a LB problem.

Hope this is useful - why does HTTPS redirect have to be such a pain?!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.