Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


HTTPS is no longer "Enforced"

Posted on 2011-02-13
Medium Priority
Last Modified: 2012-05-11
We have a web app since Adam and Eve. It is a ASP.NET app running on IIS 6 over a w2003 server. When a User logged in, somehow the app changed to HTTPS. Do not ask me how as that is now a matter of original development team vs. new.

However, I know for a fact this was the case. Now, it is not. New Head developer states nothing has changed and worst, than there is no code in the app to do this.

So, if anyone has any advice, it will be really appreciated.

Thanks in advanced.
Question by:phermi
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 4
LVL 12

Assisted Solution

Amick earned 200 total points
ID: 34882945
If it isn't in the program, I'd look in the server configuration.
Review this information: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/56bdf977-14f8-4867-9c51-34c346d48b04.mspx?mfr=true

Author Comment

ID: 34883174

Thanks but that is too obvious. I know how to do that and i fact the server accepts HTTPS request with no problems.

Is the change to HTTPS after the user logs in what does not work.

As a workaround, while I fight the developers, I thought I could re-direct all request to http://site.com to https://site.com by doing something on IIS. I have not found the way to accomplish that either.


Author Comment

ID: 34883186
Forgot to add .. if you do that, REQUIERE SECURE CHANNEL, HTTP request will produce an error.
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

LVL 11

Accepted Solution

b_levitt earned 1800 total points
ID: 34887712
most likely there was a redirect in there somewhere.  There's a number of ways to do this:
* From the asp.net code itself

* By setting up two IIS Sites.  One for the ssl site.  A second for the http site that has a redirect rule to the https site (properties -> home directory -> "a redirection to a url")

* Similar to the above but the redirect occured on the firewall/load balancer instead.  If the developers say nothing has changed, and if whoever manages iis has said nothing has changed, then your network engineer might be the next person you go after.
LVL 11

Expert Comment

ID: 34887741
A little more info: The second one was the one I used.  I would set up a www.mysite.com site and a www.mysite.com (redirects).  In addtion to ssl redirects where necessary, I'd do redirects from mysite.com to www.mysite.com.

Also, if you are using a firewall/load balancer to do the redirect, it's possible that it is still working.  What might of changed is your internal routing, dns, or proxying.  Last week your traffic might have been routed so it followed the same route that external traffic did, which means that it would hit the same redirect.  You now might be going to the iis server directly, thus bypassing the firewall's redirect.

Author Comment

ID: 34888113
d_levitt: Yes, and I tried that approach. The problem is that ALL pages are re-directd to HTPPS and we have one public page that uses CAPTCHA and it seems to be a proble displayng the CAPTCHA elements on HTTPS, which means that upon LOGOUT, we will reverse back to HTTP.

So, not to start a witches' hunt here, I am ordering the addition of code to fix this so that production and development environment work correctly .... The code looks like ths (for others in the future):


function forceSSLSubmit() {
    var strAction = document.forms[0].action.toString();

    if (strAction.toLowerCase().indexOf("http:") == 0) {
        strAction = "https" + strAction.substring(4);
        document.forms[0].action = strAction;


string url = Context.Request.Url.AbsoluteUri;
if (url.IndexOf("https") == 0)
url = url.Replace("https", "http");

HttpContext.Current.Response.Redirect(url, true);
LVL 11

Expert Comment

ID: 34888305
ah, well if the ssl redirect is conditional, it is unlikely (but not impossible) that it was anywhere other than in code.  I appologize, I missed the "when the user logged in".

As far as your code goes, I would either recommend redirecting on the server side (although you seemed to indicate this is not possible because of your captcha control), or simply changing your form action or link to an absolute url (including the https).  Your javascript code may fail or be bypassed, plus the form url could be a relative link and not have "http:" in it in the first place.

Also, be sure that your logout redirect is after any logic that needs to occur.  A redirect to a non-ssl page will start a new session, which would probably cause your log out logic to fail.

Last, you could also have a secure.domain.com to redirect to.  This would give you better control of "forcing" ssl on all pages.  Although even sites like amazon don't redirect if the user manually changes the https to http so I'm not sure how much you need to worry about protecting users from themselves.


Author Comment

ID: 34889070
b_levitt: Thanks again. A far as we understand, JS can only fail if JS is not enabled in the browser. This is a system requirement for us as we used AJAK intensively. We are in fact changing the form action with that code, or so do we believe.

Logout: no problems, we are doing exactly that.

The redirect via another site is what I implemented as a workaround, but some "experts" state that this will mess up the search engines ratings.

Who knows?

For now, I am moving ahead with the code shown above, unless you bring me a compelling reason not to.

Thanks again.
LVL 11

Expert Comment

ID: 34889427
Sounds good on all accounts other than the "search engine ratings" ...

I beleive you said the secure portion of this is protected by a captcha control so I'm not exactly sure how your "experts" think any spider is getting by that to index the site to begin with, let alone ranking it.  Even if it did, intrasite linking is NOT going to raise your ratings (links = votes and google isn't so stupid to let you vote for yourself).  Last, google is not going to see that javascript, so I would think that it would be better to have a link vs no link at all.

Sorry, don't mean to rant.  But SEO seems to be falling into the hands of marketing dolts that have captured a few technical buzzwords and then slap a name like "link juice" on a glass of cool-aid and sell it as something new.

Author Comment

ID: 34889489
No No .. I am confusing you.

Re-directing ALL traffic to HTTPS causes an issue in a PUBLIC page that uses CAPTCHA. That page is used to request DEMOs of the System and we do not want in any way to affect that part. Obviously, we can't afford non-SSL logins, so we put the redirect in place being the lesser of two evils.

Now, the "experts" advised us against using re-direct because it may have a negative impact on ratings. Whether that is true or not, I do not know ... but the problem is fixed now ...

Have a great one

Featured Post

Q2 2017 - Latest Malware & Internet Attacks

WatchGuard’s Threat Lab is a group of dedicated threat researchers committed to helping you stay ahead of the bad guys by providing in-depth analysis of the top security threats to your network.  Check out our latest Quarterly Internet Security Report!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Logparser is the smartest tool I have ever used in parsing IIS log files and there are many interesting things I wanted to share with everyone one of the  real-world  scenario from my current project. Let's get started with  scenario - How do w…
Lync server 2013 or Skype for business Backup Service Error ID 4049 – After File Share Migration
In this video, Percona Solutions Engineer Barrett Chambers discusses some of the basic syntax differences between MySQL and MongoDB. To learn more check out our webinar on MongoDB administration for MySQL DBA: https://www.percona.com/resources/we…
Are you ready to place your question in front of subject-matter experts for more timely responses? With the release of Priority Question, Premium Members, Team Accounts and Qualified Experts can now identify the emergent level of their issue, signal…

636 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question