Differences in TcpServerChannel behavior under Linux and Windows .NET 8 builds #2551
Open
1 of 5 tasks
Labels
need triage
Pending Feedback
Pending on further feedbacks or clarification from person who create the issue.
Type of issue
Current Behavior
I'm building a OPC UA Server application using .NET 8 and which I plan to run inside a docker (linux) container. Some of the developers work with Windows-based machines and some work with Linux-based machines. The difference appears when I try to connect to my application using a third party OPC UA Client with Basic256Sha256/Sign&Encrypt and my application DOES NOT yet trust the Application Certificate of the client.
The following combinations were tested
In the faulty case, UA Expert tries to connect but receives Bad_SecurityChecksFailed and then the connection is not terminated until 5 minutes has passed (meaning e.g. that I cannot try to re-connect using UA Expert before the connection has closed).
The problem only appears when both Linux version of UA Expert and Linux version of my application are involved. I tracked to problem down to TcpServerChannel.ProcessOpenSecureChannelRequest() which checks the client's Application Certificate which fails due to not being trusted. The function then calls TcpListenerChannel.ForceChannelFault() which check whether the connection state is "Connecting" or not.
I tried to check what might have caused the TcpServerChannel.State to become something other than "Connecting" but could not find it.
Expected Behavior
I would expect both Windows and Linux versions to behave identically.
Strange part is that it also seems to have something to do with UA Expert's Linux build since Windows version of UA Expert AND Linux version of Prosys Browser works.
Steps To Reproduce
Environment
Anything else?
No response
The text was updated successfully, but these errors were encountered: