Please create a separate forum thread for the new issue.

Yes, this should work in general.

One source of potential conflict would be if the two branches happen to produce the same certificate subject name (QuickOPC determines it automatically from info such as assembly name assembly description etc.). This can be resolved by setting the name from the code - see the example I pointed to earlier. But, even if they "share" the same certificate, which is technically not right, you will probably not notice a difference.

Regards

Actually, there is more to it.

First of all, if you have two or more "copies" of the same application, in the OPC UA world they should have, for security reasons, different instance certificates. Things will probably appear to work just fine even if you reuse the same certificate, but it would still not be the correct way to do it.

So, strictly speaking, the approach described in the previous post is correct if you "move" the application from the development computer to the production computer (never use it from the development computer again), but not if you "copy" it (ever intend to use them both).

Then, there is another thing I have not considered in my previous reply: By default, the QuickOPC application looks for its own instance certificate using a name which I think includes the computer name it is running on. This means that it may not find your copied certificate on the new machine anyway. if this happens, the solutions are:

1) Give the machines the same name

2) Let QuickOPC auto-generate a new certificate on the new machine (as opposed to my advice in the previous post) - and pass that new certificate to the party that runs server, so that they can trust it (and they remove the older ones that should no longer be able to connect, etc.). This is what I would recommend to do.

3) Tell QuickOPC not to use the default name generation, but instead specify the name directly in your code - so that it won't change based on the computer it is running on. opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...he%20client%20certificate.html . As in (2), this will generate a certificate that needs to be passed to and trusted by the party that runs the server (but it can be the same one from the moment it is implemented, regardless of the machine it runs on).

Regards

I am glad that it works.

Yes, precisely so.

And ideally you would do this before you first start the app there. Because otherwise it will auto-generate its own instance certificate, so you would end up with 2 of them (the auto-generated one, and the one you place there manually), which may lead to unpredictable behavior as long as they are both valid. And you would have to remove the auto-generated one anyway.

Regards

Note that - unless you want to keep using AcceptAnyCertificate - you should also place a copy of the issuer's certificate (.DER, again) into the Trusted peers store.

Hello.

I repeated your steps, and I got the same error.

I then renamed the issuer's certificate form .CER to .DER.
I was then able to connect to your server and read its data:



Regards