[GH-ISSUE #1172] [SOLVED] Windows 7 client/server SSL handshake not working

kerem commented

2026-02-27 15:52:10 +03:00

Owner

Originally created by @dedosmedia on GitHub (Jun 9, 2023).
Original GitHub issue: https://github.com/quasar/Quasar/issues/1172

Quasar version

1.4.1

Server installed .NET version

.NET 4.8.4034

Server operating system

Windows 10/Server 2019/2016

Client installed .NET version

.NET 4.0.30319

Client operating system

Windows 7/Server 2008 R2

Build configuration

Release

Describe the bug

I am using the latest release v1.4.1 (I am not compiling by myself).
I have created a quasar.p12 certificate. Then I proceed to create a client "office.exe", with those settings:
dns: someserver.ddns.net
port: 4799

The server will be running on a PC (LAN IP: 192.168.1.8), so I forwarded the port on my router.
Anything incoming from 0.0.0.0:4799 will be redirected to 192.168.1.8:4799
I am pretty sure port redirection is working because I have checked it with https://canyouseeme.org/

I have double checked the port forwarding simulating a server with netcat and running it on 192.168.1.8:4799.
I was able to interact with it from another external PC connecting to someserver.ddns.net:4799, so portforwarding is working.

When I run the previously created quasar client on an external PC. I receive the handshake encrypted connection on my server (remember I am simulating it with netcat and I can see "garbage" in the terminal), so I am pretty sure the client is succesfully reaching my server and it's trying to make a connection.

However when I run my real quasar server instead of netcat server... The connection is never stablished, the client never appears into quasar server client's list.

But, if I run the same client "office.exe" in the same machine as my quasar server (remember it tryes to connect to someserver.ddns.net:4799), it works... it appears in the client's list.

So, I know the client is reaching my server, I know it sends the handshake data, but it seems that quasar server is not accepting its request

How to reproduce

already described

Expected behavior

Quasar shows a new conenction when client is runing outside LAN.

Actual behavior

Client never appears into quasar server client's list.

Additional context

No response

Originally created by @dedosmedia on GitHub (Jun 9, 2023). Original GitHub issue: https://github.com/quasar/Quasar/issues/1172 ### Quasar version 1.4.1 ### Server installed .NET version .NET 4.8.4034 ### Server operating system Windows 10/Server 2019/2016 ### Client installed .NET version .NET 4.0.30319 ### Client operating system Windows 7/Server 2008 R2 ### Build configuration Release ### Describe the bug I am using the latest release v1.4.1 (I am not compiling by myself). I have created a quasar.p12 certificate. Then I proceed to create a client "office.exe", with those settings: dns: someserver.ddns.net port: 4799 The server will be running on a PC (LAN IP: 192.168.1.8), so I forwarded the port on my router. Anything incoming from 0.0.0.0:4799 will be redirected to 192.168.1.8:4799 I am pretty sure port redirection is working because I have checked it with https://canyouseeme.org/ ![2023-06-09_07-43](https://github.com/quasar/Quasar/assets/4777739/2dd85b18-7701-45a4-a0fc-b4265ec8f966) I have double checked the port forwarding simulating a server with netcat and running it on 192.168.1.8:4799. I was able to interact with it from another external PC connecting to someserver.ddns.net:4799, so portforwarding is working. When I run the previously created quasar client on an external PC. I receive the handshake encrypted connection on my server (remember I am simulating it with netcat and I can see "garbage" in the terminal), so I am pretty sure the client is succesfully reaching my server and it's trying to make a connection. However when I run my real quasar server instead of netcat server... The connection is never stablished, the client never appears into quasar server client's list. But, if I run the same client "office.exe" in the same machine as my quasar server (remember it tryes to connect to someserver.ddns.net:4799), it works... it appears in the client's list. So, I know the client is reaching my server, I know it sends the handshake data, but it seems that quasar server is not accepting its request ### How to reproduce already described ### Expected behavior Quasar shows a new conenction when client is runing outside LAN. ### Actual behavior Client never appears into quasar server client's list. ### Additional context _No response_

kerem

2026-02-27 15:52:10 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@BurntDog commented on GitHub (Jun 9, 2023):

Just to eliminate any possible issue with the Firewall, did you test with Firewall temporarily disabled?

@BurntDog commented on GitHub (Jun 9, 2023): Just to eliminate any possible issue with the Firewall, did you test with Firewall temporarily disabled?

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@dedosmedia commented on GitHub (Jun 9, 2023):

The connection is not an issue... I have been debugging quasar server and the client's connection is going into, but it always dispatch an exception at this line

github.com/quasar/Quasar@bcca6010de/Quasar.Server/Networking/Server.cs (L331)

and It happens after this line:

github.com/quasar/Quasar@bcca6010de/Quasar.Server/Networking/Server.cs (L282)

It seems an issue with with SSL authentication. The weird thing it's that the client running on the same machine as the quasar server is able to authenticate, but that same client running in another PC is not able to authenticate.

@dedosmedia commented on GitHub (Jun 9, 2023): The connection is not an issue... I have been debugging quasar server and the client's connection is going into, but it always dispatch an exception at this line https://github.com/quasar/Quasar/blob/bcca6010de2c3cf5780deaaed33d1f44b097d10a/Quasar.Server/Networking/Server.cs#L331 and It happens after this line: https://github.com/quasar/Quasar/blob/bcca6010de2c3cf5780deaaed33d1f44b097d10a/Quasar.Server/Networking/Server.cs#L282 It seems an issue with with SSL authentication. The weird thing it's that the client running on the same machine as the quasar server is able to authenticate, but that same client running in another PC is not able to authenticate.

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@dedosmedia commented on GitHub (Jun 9, 2023):

I took some screenshots.

First I am running my client from the same machine as my quasar server.
It's trying to connect to somedomain.ddns.net:4799

Once the connection is established, a breakpoint on line github.com/quasar/Quasar@bcca6010de/Quasar.Server/Networking/Server.cs (L323)

Shows this:

And the same client but running from another machine, shows this:

You can appreciate when the client is run on another PC, it's not able to authenticate. isEncrypted and isAuthenticate property is false, but it does not happen when the client is run on the same machine as the server...

What is going on? Any help aprreciated

@dedosmedia commented on GitHub (Jun 9, 2023): I took some screenshots. First I am running my client from the same machine as my quasar server. It's trying to connect to somedomain.ddns.net:4799 Once the connection is established, a breakpoint on line https://github.com/quasar/Quasar/blob/bcca6010de2c3cf5780deaaed33d1f44b097d10a/Quasar.Server/Networking/Server.cs#L323 Shows this: ![office desde misma maquina server (1)](https://github.com/quasar/Quasar/assets/4777739/47dfbb59-3760-4474-8047-e9bf725eb2b4) And the same client but running from another machine, shows this: ![office running on another pc (1)](https://github.com/quasar/Quasar/assets/4777739/840f93e0-474a-4915-9c95-c2b8ddfcd101) You can appreciate when the client is run on another PC, it's not able to authenticate. isEncrypted and isAuthenticate property is false, but it does not happen when the client is run on the same machine as the server... What is going on? Any help aprreciated

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@dedosmedia commented on GitHub (Jun 9, 2023):

My server machine is Windows 10
The client PC is a Windows 7 machine... I don't know if this could lead to the issue, I will try to make tests with another W10 Machine as a Client.

@dedosmedia commented on GitHub (Jun 9, 2023): My server machine is Windows 10 The client PC is a Windows 7 machine... I don't know if this could lead to the issue, I will try to make tests with another W10 Machine as a Client.

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@dedosmedia commented on GitHub (Jun 10, 2023):

Windows 7 SP1:

Quasar v1.3.0

A client running on the same host as the server, trying to connect to loopback (127.0.0.1) will connect without issues.

Quasar v1.4.0
Quasar v1.4.1

A client running on the same host as the server, trying to connect to loopback (127.0.0.1) will not connect.

Windows 10:

Quasar v1.3.0
Quasar v1.4.0
Quasar v1.4.1

A client running on the same host as the server, trying to connect to loopback (127.0.0.1) will connect without issues.

To summarize:

A client running in W7 won't connect with a server (running in W7 or W10) for quasar server v1.4.0+
A client running in W10 won't connect with a server running in W7 for quasar server v1.4.0+

So I think the issues are with SSL certificate and Windows 7. SSL was added as of v1.4.0.
I hope anyone has an idea how to solve it and make it possible to use the clients ( v1.4.0+) under Windows 7 machines.

@dedosmedia commented on GitHub (Jun 10, 2023): **Windows 7 SP1**: **Quasar v1.3.0** - A client running on the same host as the server, trying to connect to loopback (127.0.0.1) will connect without issues. **Quasar v1.4.0** **Quasar v1.4.1** - A client running on the same host as the server, trying to connect to loopback (127.0.0.1) **will not connect**. **Windows 10**: **Quasar v1.3.0** **Quasar v1.4.0** **Quasar v1.4.1** - A client running on the same host as the server, trying to connect to loopback (127.0.0.1) will connect without issues. To summarize: - A client running in W7 won't connect with a server (running in W7 or W10) for quasar server v1.4.0+ - A client running in W10 won't connect with a server running in W7 for quasar server v1.4.0+ So I think the issues are with SSL certificate and Windows 7. SSL was added as of v1.4.0. I hope anyone has an idea how to solve it and make it possible to use the clients ( v1.4.0+) under Windows 7 machines.

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@MaxXor commented on GitHub (Jun 10, 2023):

Hmm, interesting. I thought I tested it correctly. I'll check it this afternoon. Thanks for the report @dedosmedia.

In the worst case scenario I'll have to drop Windows 7 support and you have to keep using Quasar v1.3.0 for it... however Windows 7 support ended a few years ago so it's not thaaaat bad.

@MaxXor commented on GitHub (Jun 10, 2023): Hmm, interesting. I thought I tested it correctly. I'll check it this afternoon. Thanks for the report @dedosmedia. In the worst case scenario I'll have to drop Windows 7 support and you have to keep using Quasar v1.3.0 for it... however Windows 7 support ended a few years ago so it's not thaaaat bad.

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@MaxXor commented on GitHub (Jun 10, 2023):

v1.4.1 Windows 7 client connected to Windows 10 server:

v1.4.1 Windows 10 client connected to Windows 7 server:

Also checked Release configuration, besides Debug. Worked as well... unfortunately i'm not sure what's wrong on your side, but the exceptions you've shown looks like something is intercepting with your TLS connections, or an outdated(?) installation of .NET Framework? I'm really not sure...

edit1: The properties you showed IsAuthenticated and IsEncrypted are both false before the TLS handshake completes, that is correct behavior. It changes to true once the handshake is completed. According to your summary of findings it looks like something is preventing your Windows 7 machine from completing the TLS handshake while Windows 10 has no problems.

edit2: Can you check if maybe TLS 1.2 is disabled on your Windows 7 machine somehow? That's definitely not the default option, but could still be possible.

Execute these Powershell lines, reboot and try to connect again:

# set strong cryptography on 64 bit .Net Framework (version 4 and above)
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

# set strong cryptography on 32 bit .Net Framework (version 4 and above)
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

@MaxXor commented on GitHub (Jun 10, 2023): v1.4.1 Windows 7 client connected to Windows 10 server: ![image](https://github.com/quasar/Quasar/assets/7271470/20870fef-203a-4dd6-9a4c-87b4e48f9ba0) v1.4.1 Windows 10 client connected to Windows 7 server: ![image](https://github.com/quasar/Quasar/assets/7271470/6f19b663-73e4-4e44-a26f-ea18dc16d174) Also checked Release configuration, besides Debug. Worked as well... unfortunately i'm not sure what's wrong on your side, but the exceptions you've shown looks like something is intercepting with your TLS connections, or an outdated(?) installation of .NET Framework? I'm really not sure... edit1: The properties you showed `IsAuthenticated` and `IsEncrypted` are both `false` before the TLS handshake completes, that is correct behavior. It changes to `true` once the handshake is completed. According to your summary of findings it looks like something is preventing your Windows 7 machine from completing the TLS handshake while Windows 10 has no problems. edit2: Can you check if maybe TLS 1.2 is disabled on your Windows 7 machine somehow? That's definitely not the default option, but could still be possible. Execute these Powershell lines, reboot and try to connect again: ```ps1 # set strong cryptography on 64 bit .Net Framework (version 4 and above) Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord # set strong cryptography on 32 bit .Net Framework (version 4 and above) Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord ```

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@dedosmedia commented on GitHub (Jun 10, 2023):

Thanks for looking into this so quickly!!
I will try to do it.
Thanks

@dedosmedia commented on GitHub (Jun 10, 2023): Thanks for looking into this so quickly!! I will try to do it. Thanks

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@dedosmedia commented on GitHub (Jun 10, 2023):

I have made some mores tests.

The DEBUG version works without issues on Windows 7 SP1 x64, it's a fresh windows install with just .NET Framework 4.5.2.

So it seems the issue is just with Windows 7 SP1 x86. I will try to find a workaround ( The registry changes you suggested did not work).

@dedosmedia commented on GitHub (Jun 10, 2023): I have made some mores tests. The DEBUG version works without issues on Windows 7 SP1 x64, it's a fresh windows install with just .NET Framework 4.5.2. So it seems the issue is just with Windows 7 SP1 x86. I will try to find a workaround ( The registry changes you suggested did not work).

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@BurntDog commented on GitHub (Jun 11, 2023):

I have made some mores tests.

The DEBUG version works without issues on Windows 7 SP1 x64, it's a fresh windows install with just .NET Framework 4.5.2.

So it seems the issue is just with Windows 7 SP1 x86. I will try to find a workaround ( The registry changes you suggested did not work).

The one you're having issues with is changed from Debug to Release, yes?

@BurntDog commented on GitHub (Jun 11, 2023): > I have made some mores tests. > > The DEBUG version works without issues on Windows 7 SP1 x64, it's a fresh windows install with just .NET Framework 4.5.2. > > So it seems the issue is just with Windows 7 SP1 x86. I will try to find a workaround ( The registry changes you suggested did not work). The one you're having issues with is changed from Debug to Release, yes?

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@dedosmedia commented on GitHub (Jun 11, 2023):

Either DEBUG or RELEASE was having the issues on my Windows 7 Ultimate x86 machine...

Anyway I think it's something particular to the Windows build I had.
I downloaded a Windows 7 Professional x86 (6.1, Build 7600) with .NET framework 4.5.2, and it works perfect either DEBUG or RELEASE.

I will post any further find just to document it.

Thans for your help.

@dedosmedia commented on GitHub (Jun 11, 2023): Either DEBUG or RELEASE was having the issues on my Windows 7 Ultimate x86 machine... Anyway I think it's something particular to the Windows build I had. I downloaded a Windows 7 Professional x86 (6.1, Build 7600) with .NET framework 4.5.2, and it works perfect either DEBUG or RELEASE. I will post any further find just to document it. Thans for your help.

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@BurntDog commented on GitHub (Jun 11, 2023):

Either DEBUG or RELEASE was having the issues on my Windows 7 Ultimate x86 machine...

Anyway I think it's something particular to the Windows build I had. I downloaded a Windows 7 Professional x86 (6.1, Build 7600) with .NET framework 4.5.2, and it works perfect either DEBUG or RELEASE.

I will post any further find just to document it.

Thans for your help.

The reason I asked is it must be compiled as RELEASE for it to work correctly for normal use in or out of network.

@BurntDog commented on GitHub (Jun 11, 2023): > Either DEBUG or RELEASE was having the issues on my Windows 7 Ultimate x86 machine... > > Anyway I think it's something particular to the Windows build I had. I downloaded a Windows 7 Professional x86 (6.1, Build 7600) with .NET framework 4.5.2, and it works perfect either DEBUG or RELEASE. > > I will post any further find just to document it. > > Thans for your help. The reason I asked is it must be compiled as RELEASE for it to work correctly for normal use in or out of network.

kerem commented

2026-02-27 15:52:11 +03:00

Author

Owner

@dedosmedia commented on GitHub (Jun 11, 2023):

I was able to get it working properly with any Windows version.

I just changed two lines:
github.com/quasar/Quasar@bcca6010de/Quasar.Client/Networking/Client.cs (L277)
and
github.com/quasar/Quasar@bcca6010de/Quasar.Server/Networking/Server.cs (L282)

Changing SslProtocols.Tls12 to SslProtocols.Default made it possible to my old OS (without TLS1.2 support) to communicate with my quasar server. This way I did not have to make changes to registry nor other settings.

On my tests I was running DEBUG and RELEASE versions and it always connected it does not matter who is the server (W7 or W10), so at least for me this workaround works!. I don't know what implications the change have to other cases.

Thanks for your help!!

@dedosmedia commented on GitHub (Jun 11, 2023): I was able to get it working properly with any Windows version. I just changed two lines: https://github.com/quasar/Quasar/blob/bcca6010de2c3cf5780deaaed33d1f44b097d10a/Quasar.Client/Networking/Client.cs#L277 and https://github.com/quasar/Quasar/blob/bcca6010de2c3cf5780deaaed33d1f44b097d10a/Quasar.Server/Networking/Server.cs#L282 Changing **SslProtocols.Tls12** to **SslProtocols.Default** made it possible to my old OS (without TLS1.2 support) to communicate with my quasar server. This way I did not have to make changes to registry nor other settings. On my tests I was running DEBUG and RELEASE versions and it always connected it does not matter who is the server (W7 or W10), so at least for me this workaround works!. I don't know what implications the change have to other cases. Thanks for your help!!

Rows
Columns

[GH-ISSUE #1172] [SOLVED] Windows 7 client/server SSL handshake not working #867

Quasar version

Server installed .NET version

Server operating system

Client installed .NET version

Client operating system

Build configuration

Describe the bug

How to reproduce

Expected behavior

Actual behavior

Additional context