Have you sniffed the client-to-server handshake between IE6 and the IIS machines yet? (http://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake_in_detail) I suspect that this will give you the first bit of information about what's going wrong, especially if you compare the handshake to a working IE7-based client-to-server conversation. An incompatible handshake is my guess as to what's happening.
Here's Microsoft's "official" "changes to HTTPS in IE 7" document: http://msdn.microsoft.com/en-us/library/bb250503(VS.85).aspx
I'm wondering about the "Use TLS 1.0" checkbox in the "Advanced" settings of your IE6 clients. IE7 enables TLS 1.0 by default, and IE6 disables it. It's unclear if your Customer's pentesters played around with the settings on the servers, clients, or both. I can imagine that, assuming they were playing around with the servers, they disabled SSL v2 on the servers (see http://support.microsoft.com/kb/187498) but didn't tell anybody to enable TLS 1.0 on the IE6 clients.
On the servers, they would have altered/created the "Enabled" DWORD value under "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server" and set it to 0, assuming they did disable SSL v2.
David,
In case you're still hitting up against this problem, it's actually rather simple to fix. But it's not documented ANYWHERE, and it took me ages to sort it out in my environment. Everything you've done is good, and it's what I'd call a bug in how IE gets it's WPAD info and connects to the web server.
First of all, you can't use a CNAME record for WPAD. Use an A record. Silly, I know, and it shouldn't make any difference, but it's definitely the case. So remove your CNAME in your DNS, and make an A record for the IP Address of the web server.
Secondly (and this may be more tricky for you), you need to have the WPAD.DAT file located on the root of the default website that's listening on the IP Address that you've assigned above. This is the key. It WILL NOT work with a host-header field or anything like that.
Explanation: What IE does is resolve the name WPAD to an IP Address. It's got to be able to resolve it directly to an IP Address. If it resolves as a CNAME query does to a different name, it won't work. So once IE's got the IP address that WPAD resolves to, what it actually does is connect to http://<>/WPAD.dat. If you've got a different website set up on the same webserver, listening on port 80 but using a host header field like I had (IE, "default web site", as well as "WPAD Website"), then you'll have everything set up correctly, but it won't work for that very reason. Put a copy of your WPAD.DAT file on the root of your default website, and things should start working.
Of course, if you can't get access to the root of that website (or you can't secure the root of that website), then you may need to look at moving your WPAD site to a different server where it can be at the root of the IP Address assigned to that server.
Give that a shot anyway. That's the process that worked for me. It took me ages to get it working, but it's been reliably working now for a long time. All the above though is simply my understanding of how IE works in relation to WPAD.DAT files, and might not be correct - it's simply based on the observation of what it does in my own environment. Yours may be different, but I'd put some money at least on that fixing your issue.
Let me know how you get on!
Matto :)
Best Answer
On the same computer, do you connect to the same server which hosts IIS using a different account? For example to connect a shared network resource (folder share)?
To test, if this is the case, try to disconnect that account, reboot the client machine and try again.
Possible solutions:
This link from the Microsoft support site may be interesting too:
Error message when you use user credentials to connect to a network share from a Windows-based computer: "The network folder specified is currently mapped using a different user name and password"