I have a configuration with ARR on a front-end server and an IIS (8) web farm behind it. SSL is enabled with the same certificate on the ARR server and the IIS web farm servers and I am not using SSL offloading. The servers are using Shared Config so the setup is theoretically identical. Interestingly, when the ARR round robin configuration hits ONE of the servers, it returns a "502 - Web server received an invalid response while acting as a gateway or proxy server." error. Another server returns the page fine with SSL working. If I point my browser to the "bad" server directly, without ARR, it works fine in HTTPS / SSL mode. I checked the configurations and found nothing different between the servers and even enabled Failed Request Tracing on the ARR server, which wasn't that helpful but I saw a different 502.3 error within the log. Why would I get a 502 error of any kind, especially on just one server in the farm when they are configured identically with shared config and certificates are on all servers?

3 Answers 3


Even with IIS setup on a shared config with all the nodes, each node's Operating system is able to set SSL binds outside of IIS, which wouldnt be shared between the nodes. So what I believe the issue is an SSL binding on the OS side (not IIS) on the one node and thereby not allowing the match that IIS was asking it to do. To fix that look at the OS SSL bindings and compare it to the other server nodes, correct any difference there so that the nodes are all match would resolve this issue for you.

I had a similar issue happen, and by mistaken on of my co-works forgot to tick the use SNI when binding a certificate, which caused it to push through to the OS and bind it there. subsequently changing that to use SNI did not remove the OS SSL binding, and after some checking we noticed that and removed it and all was well again.


Let me answer my own question.

I disabled "Require Server Name Indication" and suddenly everything worked. This is weird because SNI was enabled on all servers in the farm for the same site but for one of them, unchecking it made it all work.

My theory is this: Even with shared config, SSL binding information doesn't really transfer from one server to the other, from the IP to the certificate. As many of you know, you still have to manually go to the other server and select the certificate.

So that was a clue about how the setups could be different. I actually believe the setups were the same visually but somewhere under the hood something was different for one binding somehow.

Anyway, I spent hours on this issue and nowhere did I read anything about "Require Server Name Indication" being related to a 502 error. So I wanted to share with the internet community so that future people will know to look at that setting if they are stuck with a 502 error when using SSL.

Maybe there is a way to keep it enabled, since it was working on the rest of my farm, but at the very least you'll know in what area you might need to be looking to solve your 502 error.

Of course, remember that the first cause of 502 errors, in my opinion, is not having the certificate installed on all servers when not using SSL offloading but that was not my issue, and mine was unique in that just one server in a farm was misbehaving with SSL enabled.

I hope this helps someone else.


I was getting a similar error. Going to rewrite Url directly worked fine, however, ARR would give 502 Security Errors. I'm using a self-signed cert to do Dev work and it turns out that "how" I create the cert makes a difference. When I use Powershell:

New-SelfSignedCertificate -DnsName *.localmachine.com  -CertStoreLocation cert:\LocalMachine\My

The cert works fine going direct to several sites using the cert, however, through ARR throws the errors. If I use the old-school makecert:

makecert -n "CN=*.localmachine.com" -pe -ss My -sr LocalMachine -sky exchange -m 120 -in "WebTeam Dev WildCard Root CA" -is Root -ir LocalMachine -a sha256 -eku

It works fine both direct and through ARR - even the trace logs didn't give any detail on what the actual issue was :(

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .