In this case, the error code you are looking at (0x80860000, BadSecureChannelClosed) is most likely coming from the server. That's logical - it is the server that rejects the client certificate. If you are getting something different sometimes, I will need to know the error details (including the full message), but if it is also coming from the server (which is likely), you will need to ask the server vendor about it. AFAIK, according to OPC UA specs, there isn't much a compliant server is allowed to tell the client about the rejection - not even by means of really differentiating the error codes much - for security reasons. But this fact might be good for you, you really do not want too many error codes to deal with.

Best regards

Before I get to the specifics of the question, here is a more general statement:

The QuickOPC design concept is based on the idea that the aim of the component is to deliver the data,or perform the requested operation if possible. In casy of a problem the component:
1. Tries to remedy the situation, if possible (there may be workarounds for things like missing server features etc.). In this case you won't even know that this has happened, through the "normal" API channels (it might be in the logs, but that's for troubleshooting, not for normal operations).
2. If the above is not possible, you get to know about the problem through the API; if it affects an operation that spans a time range (like subscription), the component will keep trying to fulfill what it has been asked to do.
In the second case, to us, all errors are about the same - it does not matter what it was; it is up to the user to decide whether the problem needs addressing or how. The range of possible problems is enormous - client, server, network, configuration of them, etc. We do not generally expect the *software* to handle the errors, or handle some errors differently . It is possible to do, but it is not something we are designing for. Also the details of the errors are change to subject.

Now to your question: Are we talking about the situation when the client (your app) certificate is not trusted by the server (that is the "controller")?
If so, what is there on the client that you want to do differently from other error situations, and why? Is it just to provide better diagnostics to the operators of the software, or is there something more involved? The way we see it, as explained above, this error just like thousand other possible errors that can happen - somebody needs act upon it and resolve it, based on what the error message says - or not?

Thank you