Certifcate Issue solved after Windows restart

[HamSolo]

Hello,

many years ago, we have implemented an OPC-UA Server for our customer based on UA-SDK .NET Bundle 2.6.1 with special communcation protocals to the source system. Since that the UA-Servers is running under Windows Server 2012R2. Because the software and the whole system is running on an totally isolated network the customer had never the need for any updates.

But now the customer implemented a new OPC-UA Client and now we had a curious behavior which i just want to understand and hopefully someone can give me a hint.

The new UA-Client connects to the OPC-UA Server and the certificate from the client was accepted but the connection could not etablished (BadCertificateHostNameInvalid). All other not updated UA-Clients (even our test with UA-Expert) were still able to connect. After many restarts of the OPC-UA Server (killing also via Task-Manager) and deleting existing certifcates the issue still remained.
Then we decided to reboot Windows. So I initilized the reboot of windows while the OPC-UA still run. And just one second later the new UA-Client was able to connect and read some values without any problem after the process was killed by the reboot process. After the restart of Windows and the autostart of the OPC-UA Server the UA-Client could etablish the connection automatically without any problem!

This behavior leads me to the point where I ask what kind of Windows features could be raise the issue, because kill and restart the OPC-UA Server only brought no success.

Any ideas what could be the problem?

Thanks in advance

[Support Team]

Hi,

no not really any idea. The file trace function in UA Server (based on .NET SDK) would be the best option to see details in start up phase of server, and first connect attempt of client.

The .NET SDK Server is capable of certificate bassed OPC UA security features ever since, so even for the "old" v2.6 it should work right out of the box. You should consider following:

• The .NET SDK can use either "file store" or the "Windoes Certificate store" for storing it's own and the trusted certs (default is file store)

• The .NET SDK (like all other SDK from Unified Automation) automatically creates it's own self signed cert on very first startup (first start ever, use "/install" parameter on command line, must have admin rights, typically done from setup/installer). This cert has livetime/expiry (default) 10 years, or what ever the manufacturer of the server has coded.

• The .NET SDK requires extra tool to create initial cert automatically, "certificategenerator.exe" which must be installed together with the UA Server.

• If you NOT have cert-generator or not want to use auto-self-created certificates, the own-certificate (pair of public and private) must be created externally (e.g. engineering tool, Certificate Authority, fall from sky) and must be copied into file store BEFORE first ever start up of the server.

Note: the "old" .NET SDK v2.6 may have SecurityPolicies that are today "deprecated" (e.g. using Sha1 instead of Sha256, or have short key length 1024). There might be (modern) Clients that, do not support the deprecated SecurityPolicies anymore. Check out here:

https://documentation.unified-automation.com/uasdknet/3.3.1/html/L1_SupportedPoliciesFrameworks.html#platform_overview

I can not see any impact difference in "reboot Windows" instead of "restart UA Server", except you have virtual file system active, in that case you would have started from "zero" after the reboot. But that is just guess. In case of any error, you must use (switch on) trace function and analyze log file.