Hello.

what QuickOPC (but, in fact, all UA applications I know) is using to find the right certificate in the certificate store is the "Subject Name". This is a so-called X509 distinguished name, which a series of one or more elements. It can also be expressed as a string, e.g. "CN=UADocExamples, O=CODE Consulting and Development, s.r.o.". The order of the element matters. It should be read as an instructions to look up in a directory service, read from right to left: In the example I gave, first find the organization given by the "O=...", then in this organization, find something with "common name" given by the "CN=..." part.

The subject name is *inside* the certificate, and in general case it is unrelated to the file name of the certificate.

To find out the subject name of the auto-generated (or some other) certificate, find the certificate-s .DER file in Windows, and double-click on it, the switch to the Details tab, and find the "Subject", as on the following picture:



If you are generating the certificate on your own, you need to instruct your tool to use the precise subject name you need. In addition, OPC UA specs put other requirements on certificate for UA application. For example, the Application URI needs to go to "Subject Alternative Name" (this also can be seen on the picture above). And there may be other requirements (see UA specs); failing to fulfill them will most likely result in the certificate being rejected, sometimes without an option to override that.

The naming scheme that QuickOPC (and some other UA apps) use for certificate in file-based certificate store is that it starts with the "common name", which is the "CN=" part from the subject name, and it is then followed by a certificate thumbprint in [ ] brackets (think of a thumbprint as a checksum). It should *not* be necessary to follow this naming scheme for your own certificate - even if it will look differently from all other files in that directory. What is used for finding the certificate is the subject name inside the certificate (i.e. QuickOPC needs to load *all* files to "look inside" for them), as described above. Your file name may be just about anything, so you do not need to worry about replicating the naming scheme correctly.

If you change the subject name inside your certificate to precisely the one used by the default auto-generated certificate, then there is no code change needed inside your program. That is the recommended approach.

For a different name, what needs to be changed - before performing any OPC operation in the program - is the value of EasyUAClient.SharedParameters.EngineParameters.ApplicationParameters.ApplicationManifest.InstanceCertificateSubject, to a string with syntax like "CN=UADocExamples, O=CODE Consulting and Development, s.r.o.".

Regarding where to put the certificate: What you have written looks most likely correct. In some cases, applications built for .NET Core/.NET 5+ may use "local" directory stores - in which cases you will such certificate directory structure under the directory where the .EXE of your program is. If such structure is not there (after running the program), then it is using the common folder you have identified.

Best regards

Oh, I see. Unfortunately, the ability to configure the validity of the auto-generated certificate is also not in the current version (2022.2); it will be in version 2023.1. Note, however, that although 1 year might be short, the practice of setting the expiration period very long is not secure (one reason for that is that the key might be discovered by brute force by that time).

If you generate the certificate for QuickOPC yourself, the main thing to watch for is the subject name. You should either
a) examine the auto-generated certificate and take the precise subject name from it (this is the recommended, because easier and less error prone way), or
b) choose your own subject name, and then instruct QuickOPC to use it (I can point you to more info about this if you request).

The next thing is where to put the certificate. It should go into two two stores:
1) the store for "own" certificates - this is where QuickOPC will take it from - this story will have the .DER part and then, in the "private" folder, the cert with the private key in the PFX format, and
2) the store for "trusted peer" certificate (I repeat: not the "trusted issuers") - because QuickOPC will also validate its own certificate, and it needs to trust it too.

See:
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...0Client-Server%20Security.html
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...%20Instance%20Certificate.html
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ry%20Certificate%20Stores.html

If you have a client certificate all set up correctly, and you then try to make a secure connection to a server while the mutual trust has not yet been established (which you can do by placing the other-party certs to the right stores too), two things then typically happen (both of them!):
1) The server does not trust the client. It rejects its certificate and puts it into its "rejected" folder. By moving it to trusted peers it can be made trusted.
2) The client does not trust the server. It rejects its certificate and puts it into its "rejected" folder. By moving it to trusted peers it can be made trusted.

Only after all of this is properly done, the secure connections will work as they should.

Regards

Hello.

You will need two certificates. You cannot reuse the same one for both server and client (technically it might be possible to make it work, but it is totally against the OPC UA rules, and insecure).

Why precisely are you creating the certificate for the QuickOPC side by yourself? I am asking this before we go further, because in fact you do not have to do this at all. QuickOPC will create such certificate automatically (self-signed). It will have reasonable defaults, and you can even change those using some parameters that we have. So please first answer this - because using the auto-generated certificate is easier than tying the QuickOPC to an existing "external" certificate.

Best regards

If this is a client certificate, it needs to be placed in the "Trusted Peers" (not Trusted Issuers) store on the client side, plus the certificate with its private key needs to be placed in the "own" store (Machine Default).

On each server side, how it is done depends on the server, but generally the self-signed client certificate needs to appear in something that has the meaning of the "trusted peers" as well.

However, QuickOPC does not currently support password-protected private keys, so in this sense you cannot do what you are asking for. Private key password protection will be available in version 2023.1.


More info:

opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...0Client-Server%20Security.html

Best regards