Hello,

OPC UA certificates *can* be stored in platform-specific (Windows) certificate stores, but it is not the default behavior.
Normally they are in certificate stores that exist in the file system (in a directory/directories).

Try "C:\ProgramData\OPC Foundation\CertificateStores", and read
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...html#Certificate%20Stores.html
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ry%20Certificate%20Stores.html

Best regards

Hello.

While it is possible to configure aspects about the certificate selection, I would actually recommend an easier way, without modifying your program.
What the component uses uses to find the certificate is its "subject (name)", which by default it generates from information such as your project's assembly properties.

So, this is what I recommend to do:

1. On the "old" computer, where the same application runs, use some certificate viewer to find out the subject name.
2. Using Opc.UA.CertificateGenerator.exe, generate a new certificate with exactly the SAME subject name. Links: download kb.opclabs.com/Tool_Downloads#UA_Certificate_Generator , documentation github.com/OPCFoundation/Misc-Tools .
3. Verify that the subjects names are really equal.
4. Place the new certificate into the certificate store on the new computer. By default the certificates are *not* in the application subdirectory. They are in the global (shared) store. In fact you will need to have 3 locations:
4a. The .PFX in "C:\ProgramData\OPC Foundation\CertificateStores\MachineDefault\private"
4b. The .DER in "C:\ProgramData\OPC Foundation\CertificateStores\MachineDefault\certs"
4c. The same DER in "C:\ProgramData\OPC Foundation\CertificateStores\UA Applications\certs"

Your program on the new computer then should be able to find the certificate and use it, without attempting to re-generate it.

Regards

Hello.
This is a very old version of the software and we do not support it. I will try to help you but only to some extent.

The problem has to do with auto-creation of the client ("your") certificate on the client machine.

It also should be noted that running under Windows Service is many times challenging, due to restricted permissions (which can be the issue). So, in fact the first thing I would recommend to do, would be to configure the service to run (temporarily, just for test) under normal user account, to see if the behavior changes. (if that is what you are already doing when you wrote "We're running the service with adminstrator privileges.", then ignore this suggestion).

Also, please provide more information about the error: The exception message full text, the call stack, and if there is an .InnerException, the same for it.

From the error text, it is quite possible that the problem has to do with the library trying to call an external EXE for the OPC UA certificate generator - again, a demanding thing to do from inside the Windows service. The recent versions of QuickOPC do not use the external EXE and are therefore more reliable in such situations.

If everything else fails, you can consider placing the certificate in the store yourself. When properly configured, QuickOPC will then find and use it, and will not attempt to create it - which is causing the issue probably.

Regards