0

We have intranet websites in an enterprise environment. About a month ago, we started receiving emails from users who were unable to reach pages on a specific server. There are hundreds of users for this particular site and about 20 have reported that they get "connection refused" messages in their browser when clicking a link to this site.

After investigation I found that their browser was forcing an http link to https. The site does not use https. These corporate PC's have 3 browsers installed. IE, Edge, and Chrome. All 3 browsers force https to this particular server. The link looks something like this:

http://alias.corporation.com/website

So I had them try this instead:

http://servername/website

And it worked. It did not force https and the users were able to navigate to the page.

Since it's a relatively few people experiencing this issue, I'm thinking it's PC specific and I tried browser basics like clearing cache, cookies, etc. But that didn't help.

If something was misconfigured in the server it should affect everyone but it isn't.

I have searched for this issue and the only results I get are how to configure a server to redirect to https.

The easy fix would be to tell all users to start using the servername link instead of the alias. But that's not ideal and the list of users affected by this is growing by about 2-5 people every week.

What could possibly be causing this? Any suggestions?

tolsen64
  • 101
  • 1
  • Is it possible one of your intranet sites sets a domain-wide HSTS header? https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security – ceejayoz Nov 15 '18 at 16:54
  • I hadn't heard of this before now. I knew a server could redirect an HTTP request to HTTPS. If one of the intranet sites does set a domain-wide HSTS header, that'll be like looking for a needle in a haystack. I'll have to dig into this a bit. – tolsen64 Nov 15 '18 at 17:26
  • I just found this [question](https://serverfault.com/questions/433418/http-subdomain-redirect-to-https-automatically-why?rq=1). The answer suggests that clearing the browser cache should fix the issue. But for me it doesn't as I've already tried that. – tolsen64 Nov 15 '18 at 17:35
  • 1
    Check `curl -I http://alias.corporation.com/website` from the affected users. If your server's issuing a 301/302 to them, it'll have nothing to do with particular browsers, and everything to do with the server config. – ceejayoz Nov 15 '18 at 17:41
  • I tried it but get 401. Our website uses windows authentication. I tried --anyauth, --NTLM, and --Negotiate but still get 401. Never used curl before so may be doing it wrong. – tolsen64 Nov 15 '18 at 18:30

0 Answers0