Hello.

1.

I do not understand why are you deleting the MachineDefault folder.
If you delete it, QuickOPC based client application will, by default, create its own new app instance certificate there. And it will have a different thumbprint each time, this is normal. But the servers will see it as a different certificate and the trust will have to be set up again.
Normally you will keep the MachineDefault folder. On subsequent runs on QuickOPC applications, the application will find and reuse the app instance certificate it is there.
Or, are you trying to say that new certificate with the same subject name but different thumbprint are created even if you do not delete the MachineDefault folder?

For the other party (server), each certificate is different (it fact what matters is the contents, not the name(, the fact that they have the same name before square brackets is irrelevant in this respect.

2.

Other SDKs might be using different folders or storage mechanism for their certificates.

So far I have not noticed any "problem" with the QuickOPC handling of certificates in your posts, just misunderstandings of how things work.

It is not possible to setup OPC UA secure communication without having to deal with certificate trust issues, not with any SDK in the world.

3.

I do not understand what the problem is. Are you saying that you have enabled the "break" on when the exception is *thrown* (not just unhandled?). if so, you will get various exceptions and you need to Continue on them.

All QuickOPC assemblies used in you project must be the same version and build. The error could be caused by improper references. Your sentence " I have installed this assembly from Nuget package manager but I still get the same error." scares me. You need to decide whether your project will be referencing the assemblies from the local installation, or using NuGet. If it was using local assemblies and then you decide to reference via NuGet, a mixup is almost guaranteed. Decide on which way you want to use, and use it consistently.

Regards

Hello.

The client already sends the certificate to the server when trying to connect. Vast majority of servers, when they encounter an "unknown" client, would put this received certificate into some kind of "rejected" folder. And then they have an administrative action which makes it simple to trust this rejected certificate that they already have.

So, when you have already attempted to connect to the server, I would expect the certificate be already there. But there can be servers that do not support this.

In such case, the location of the certificate stores folders is described in the links I gave you earlier. Most likely it will be "C:\Users\All Users\OPC Foundation\CertificateStores\MachineDefault\certs".

Note: Never give out the certificate with the private key (.PFX usually, in the 'private' subfolder). Just the one with public key (.DER usually).

Regards

Hello.

I do not see anything obviously wrong with this code, maybe except for the fact that Isolated = true is missing (you really need that if you are setting IsolatedParameters; you already had that in some earlier post, so maybe it is elsewhere in your code - but you definitely need it also with the code you posted now).

Less important comments:

- Unless you really know that the policy you want is Basic256Sha256 , it would be better to simply leave out the line that sets the policy. AllowedMessageSecurityModes should be sufficient, and the client and server will then negotiate a signed&encrypted endpoint with the best policy. If you *do* specify a concrete policy, you risk that in the future, some better policies will be implemented by the client&server, and this one will stop working.

- The parameters you are setting can also be set directly on the endpoint descriptor (and they will override those that come from SessionParameters). This might be a preferred way if you want to use the same EasyUAClient object with multiple servers - it then becomes easy to specify the endpoint selection policy and user identity differently for each server.

Regards

I have replaced the password by asterisks.

Hello.

"AcceptAnyCertificate = true" is only instruction for the client to trust the server, not otherwise. So, in the list of 3 issues I was addressing in my last client, it is *only* applicable in the 3rd case. And, after you put it there, you can still get the 2nd error, because it is given by the server, and needs to be resolved on the server.

Regards

Hello.

Regarding the connection from EURW157325 to remote Siemens server, and "Self Signed Certificate is not trusted. IssuerName: CN=DE.RuntimeService, DC=EURW157325":
This is the server not trusting the client. For secure connections, this is a must. You need to go to the server and make it trust the client certificate. Clients that work without error have probably already done this earlier.

Regarding the connection on EURW157325 to a local server, and "Certificate is not trusted. SubjectName: CN=DE.RuntimeService, DC=EURW157325 IssuerName: CN=DE.RuntimeService, DC=EURW157325". Same thing. You need to configure that local server to trust the client.

Regarding the connection on EURW157325 to a local server, and "Self Signed Certificate is not trusted. IssuerName: CN=MHWirth Reference Server, C=US, S=Arizona, O=OPC Foundation, DC=eurw157325". This time it is the client not trusting the server. If you are OK bypassing the security (do not do that for anything else than testing), you can use "AcceptAnyCertificate = true" in QuickOPC. The proper method, however, is placing the server's certificate into the client's trusted peers cert store. The QuickOPC documentation has articles on that. E.g.:

- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...%20Instance%20Certificate.html
- 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
- kb.opclabs.com/Using_OpcCmd_Utility_for_OPC_UA_Administration


Regards