Hello.

Yes, the key delivered with the latest upgrade assurance extension you have purchased covers version 2023.1.

Here are the instructions:

- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...UA%20Application%20Dialog.html

Regards

Hello,

going back to the "concepts" of the PKI, I was told that a good introduction is here (haven't really checked it): .

I understand that now you might have that part (certificate placement) correctly in place and the problem could be elsewhere; I just wanted to provide additional info.

Regards

Hello,
Thank you.

I can confirm that these are probably the rights certificates. At least, their subject names are the same as in the original error message, and the server certificate states the name of the issuer name properly.

Can you confirm that the error message you are now getting on the client is precisely the same as before? Ideally, grab it again and post it here?

Secondly, it looks like you are in position to make some changes/rebuild your application, right? Would it be possible that you upgrade to the newest QuickOPC version (if you have not done that yet), and extend the application so that the end user can invoke the OPC UA Application Administration dialog? Not only would that greatly enhance your product , but it would make it easier to troubleshoot further.

Regards

Hello.

In general I recommend you look around for information about OPC UA security with CA certificates - in OPC UA specifications, or elsewhere on the Web, or via some trainings. It is a long subject.

But I will try in the briefest form:

The server you are trying to connect to does not have "just" its own, self-signed certificate, which was what you were probably dealing with so far in other setups. Its certificate (server certificate) has been issued by some other entity - certificate authority (CA). And inside the server certificate, there is a reference to the issuer certificate (a simple two-element chain; in other cases the chain be longer).

This is usually done in this way so certificates for various client and servers cannot "just" be created on the fly, but are created by the CA, and somebody (the CA operator) actually has control of what goes into the system. And certificates created without the CA won't work.

OPC UA specification requires that the client *must* validate the whole chain - not just the server certificate, but also all issuer certificates in its chain. I have sent you the references to those specs. But your client application has not been given the issuer (CA) certificate. So it will keep rejecting the server until this is fixed.

Whoever had set up the OPC UA server, must have been the using the CA, because the server has the certificate that was generated by the CA.

In some cases, the CA is "inside" the OPC UA system, and is represented by GDS/CM (Global Discovery Server/Certificate Manager services). In other cases, it is some system unrelated to OPC UA. This is something your customer must know, otherwise there is no help. I have no way of knowing.

In order to resolve the issue, you/your customer's task is to obtain the CA certificate (public part) from the CA, and place it onto the client side in the way I described.

Note that the OPC UA server must also have it somewhere, currently.

Regards

Hello.

From your description, you/your customer have not done what I have instructed you to do. There are at least two significant differences:

1) You wrote "... and placed the server's certificate in it. ". I have not instructed you to place the server certificate there. I have instructed you to place the CA (issuer) certificate there. Without understanding the difference between the server certificate and issuer certificate, and dealing with them correctly, you will not be able to make it work.

2) In addition, I instructed you to put the certificate into two places, not just the one you listed - but that would only make difference after you actually place there the issuer certificate, and not the server certificate.

Regards

Thank you.

It looks like that the newer UA stack from OPC Foundation (which we link to) has stricter checks. Specifically, it is now compliant with OPC UA specification which, for Bad_CertificateChainIncomplete error, says that "An error during the chain creation may not be suppressed." (there are errors that the spec allows the user to suppress, and other errors that must not be suppressed). This explains three things at once: 1) why AcceptAnyCertificate = true does not work in this case, 2) why the application doe snot show a pop-up to the user showing the error and offering him the choice to accept the certificate, and 3) why no RejectedCertificates folder has been created yet.

Reference: reference.opcfoundation.org/Core/Part4/v105/docs/6.1.3 - Table 106

So the only option is to do it right: I.e. place the CA (issuer) certificate as described earlier.

Best regards