Professional OPC
Development Tools

logos

Best practice for detecting the cert needs to be trusted on the server

More
03 Jul 2019 20:14 #7488 by support
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

Please Log in or Create an account to join the conversation.

More
03 Jul 2019 14:43 #7484 by sjscheider
One of the client requirements is that we alert when the device/server/controller is not trusting the cert. This information is being relayed to cloud and alerts are sent so that a tech can go out to the device and accept the cert.

The code I have works, most of the time. But there are conditions where a different exception is thrown and I have yet to determine why.

Thanks,
Scott

Please Log in or Create an account to join the conversation.

More
03 Jul 2019 10:29 #7483 by support
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

Please Log in or Create an account to join the conversation.

More
03 Jul 2019 03:39 #7480 by sjscheider
Can you please recommend the best practice for determining that the client cert needs to be trusted on the server?

Currently we are inspecting the exception which is thrown when the initially try to browse a single node on the server. The code does not seem efficient so I'm hoping there is a better way and that I missed it in the documentation.

Here is the code we are using:
catch (UAException uaEx)
{
	if (uaEx.InnerException is UAServiceException uaServiceException)
	{
		controllerInfo.Status = (uaServiceException.InternalCode == 2156265472)
			? ControllerConnectionStatus.CertNotTrustedOnController
			: ControllerConnectionStatus.ControllerConnectionError;
	}
	else
	{
		controllerInfo.Status = ControllerConnectionStatus.ControllerConnectionError;
	}
}

Thanks,
Scott

Please Log in or Create an account to join the conversation.

Moderators: support
Time to create page: 0.182 seconds

      

 Recommend this on Google