Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Monday, March 19, 2018 8:23 PM
I am troubleshooting an application that fails to make a HTTPS connection from one machine (Windows Server 2012 (not R2)) but succeeds from all others.
IE 10 on that machine also fails to connect but Firefox succeeds. This suggests that the application and IE both use the same communications library which has the problem connecting. Internet options has TLS 1.0, 1.1 and 1.2 enabled. IE is v10.0.9200. The application succeeds on every other machine including one that has the same OS and IE.
On the machine with the same OS and IE where the connection succeeds, the Wireshark capture looks like this:
On the machine where this fails, the capture looks like this:
Notice that the Server Hello is missing. Does this mean that the server has refused to send the hello?
I have checked that the cipher suites on this machine match the cipher suites on the destination server.
The destination server belongs to a third party and we do not have access to it (other than being to make this https) connection. But it is likely that the problem is not on the destination computer, but on the one computer that we are trying and failing to connect from, because the same client is able to connect from all other computers. There must be a security setting on this source machine that needs to be changed.
Any ideas about what I haven't checked yet?
Wednesday, March 21, 2018 2:15 AM ✅Answered
Hi,
Could you please post the details of Client Hello and Alert? Let's check if there is any useful information.
Best Regards
Cartman
Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com
Thursday, March 22, 2018 8:17 PM
Could you please post the details of Client Hello and Alert? Let's check if there is any useful information.
Asking me to fetch the details of Hello and Alert lead me to the answer. When I expanded the Client Hello packet, it showed me the cipher suites that the client is sending. I reevaluated this and discovered that the client was not sending any that the server was looking for. When I added the missing ones, the connection started working.
I mentioned in my OP that the cipher suites on this machine match the cipher suites on the destination server. I had actually checked this list at gpedit.msc > Computer Configuration > Administrative Templates > Network > SSL Configuration > SSL Cipher Suite Order. There were some entries in this list that match what is supported on the server, but they must have been too new for this OS. Wireshark was a better indication of what this computer supports.
Friday, March 23, 2018 1:11 AM
Hi,
Glad to hear that. If you have any other question, please feel free to ask here.
Best Regards
Cartman
Please remember to mark the replies as an answers if they help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com
Saturday, August 1, 2020 6:10 PM
For folks who come across this issue, I created a checklist:
Make sure all TLS versions are enabled in Internet Explorer (This is for testing. You can later disable the unsecure versions once you find out the root cause)
Check the registry keys below to make sure what you set in Internet Explorer is applied at registry level. If there are working and non-working servers, mirror the working server’s settings HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Collect a network trace from the client side. Check if the client and server are agreeing on a cipher suite. If they are not, make sure the client uses the cipher suites the server is trying to use. The Group Policy setting is below Computer Configuration > Administrative Templates > Network > SSL> Configuration Settings > SSL Cipher Suite Order
If the issue sill exists, look for any network device (proxy, firewall, load balancer etc.) in between that might be blocking TLS traffic
Check the website binding in IIS. Make sure the certificate is valid and the port is set to 443
Make sure the port 443 is listened in the server (netstat -an -p TCP | find /I "listening"). More details: Port 80 and 443 are not listened in IIS server
Change the port number to 444 and test website. If it is accessible, it means there is a software blocking or overwriting 443 port. More detailsDisable Windows Firewall (If it works, you can enable it back and set up rules accordingly)
Look for any third-party applications such as antivirus or endpoint protection software in the server such as Symantec Endpoint Security and Symantec Data Center Security Server Agent (Based on this document, Security Server Agent uses port 443). Uninstall them (Don’t just disable. Uninstall completely. If it works, you can install them back and configure them accordingly)
Check if there is any Microsoft software that is using port 443. Applications like SQL Server Reporting Services (SSRS) and Windows Admin Center might interfere the port 443. An example
Source: The missing Server Hello in TLS handshake (ERR_SSL_PROTOCOL_ERROR