Windows Server 2025 blocking "Server Hello" package from localhost self-signed HTTPS web service

Question

Hello,

I have successfully installed a standalone web server (Siemens Gridpass) on my Windows Server 2025 VM. When I did the installation on a normal Windows 11 VM, the software worked fine. During the installation the software creates a new local user on the VM, which I than have to setup as admin for the installation to succeed due to domain policies. Once the installation is finished, the services are running and listening on the specified ports (443 for the https web service). However, once I try to access the web server on my local machine (https://127.0.0.1) the server is not responding even though it is running and on my normal Windows 11 VM I have no issues there. I checked the traffic on my loopback using wireshark and found out the server is never responding with a "Server Hello". What I am currently thinking is that there maybe some Windows Server policy that prevents the connection a self-signed https server. However I am unfamiliar with the system so I could be wrong here.

If anyone has an idea what the issue could be, or what security policy is blocking my server from sending the "Server Hello" packet, I would be grateful.

Thank you in advance!

Answer 1

Hi Sieber, Patrick Hristo,

From what you’ve shared, the fact that the Siemens Gridpass service works fine on Windows 11 but fails to respond with a “Server Hello” on Windows Server 2025 suggests that the difference lies in server-side security policies rather than the application itself.

Windows Server enforces stricter defaults for TLS and certificate handling compared to client editions. A self-signed certificate may be blocked if the local security policy requires trusted root certification authorities. I recommend checking the Local Security Policy under Security Settings > Public Key Policies to confirm whether self-signed certificates are permitted. Additionally, review the Schannel settings in the registry (HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL) to ensure TLS protocols are enabled and not restricted.

Another useful step is to run netsh trace start capture=yes while attempting the connection, then analyze the trace with Microsoft Message Analyzer or Wireshark to see if the handshake is being rejected by policy. You can also test by temporarily importing the self-signed certificate into the Local Computer Trusted Root store to see if that resolves the handshake failure.

If these adjustments allow the server to respond with “Server Hello,” you’ll know the block was policy-related. Give this a try and let me know how it goes. If you find this answer helpful, kindly hit “accept answer” — it’s a small way to let me know we’re on the right track.

Jason.