Professional OPC
Development Tools

logos

Trusting certificate with AcceptAnyCertificate

More
09 Jul 2020 20:35 #8650 by support
Yes, this is the right way. Not the only one, there are more, but quite a common one with OPC UA.

Security-wise, the sensitive point here is the copying or moving from rejected certificates to the trusted peers store. Normally people do not pay much attention to it, because it is done in controlled environment where no attackers are "expected", but in principle, you must be sure you are trusting the right certificate. This is normally done by manually comparing its thumbprint (which is not that long and can be done by human) to the thumbprint of certificate on the proper server).

And, you should remove the extra settings made before, of course.

Best regards

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

More
09 Jul 2020 12:47 #8649 by SolutionNow
I've tried to review all the things you've written me and I finally understood and solved the problem. I understood the best policy would be to make the client accept the certificate, but I didn't understand how to achieve this. Then I found the certificate store folder, and it had a certificate deposited in the rejected certificate folder,I essentially cut and pasted the folders in the rejected certificate folder into the UA Applications folder, and it appears to be working correctly now. Even if it is working please let me know if there is anything mistaken in this approach.

Thank you for your assistance

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

More
07 Jul 2020 21:47 #8648 by support
First, I should make clear that using TrustedEndpointUrls is insecure in principle. Security-wise, it is only slightly better than setting AcceptAnyCertificate to 'true'. An attacker can either manipulate the DNS, or put a malicious server in place of the intended server, and the client application wouldn't be able to recognize it. You should only use these settings if you understand and accept the consequences. The proper way is to make the server's certificate be trusted on the client side.

Regarding the issues you are seeing, it is difficult to determine the cause without gathering more information. I suspect you have some mismatches in the way you configure things, but cannot tell for sure. A way to go forward would be to collect the QuickOPC trace information from your app - see kb.opclabs.com/QuickOPC:_How_to_enable_extended_tracing . That should be done for both the cases you described (with and without UI). If you do that, I still cannot guarantee that I will be able to tell the reason, but it may steer the investigation to the right direction then.

Best regards

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

More
07 Jul 2020 13:01 #8647 by SolutionNow
Hello again,

I reread the previous messages and it seems I was a bit confused about things. You said a few messages that simply turning off the UI interaction won't solve any problem as the connection would fail, as the connection problem was a result of the trusted certificate problem.

I had not responded further because it seems I found a way to correctly set the TrustedEndpointUrls property and the problem appeared to be resolved. But at one client using our application which had been functioning correctly for six months, last week the problem suddenly represented itself. Changes were made in the system, aside from a Windows update in the PC running our easyOpcUA application. When our windows service opens our easyOpcUA application (therefore the app runs without a UI) it throws an error due to the certificate not being trusted. What is particularly strange is when the application is opened directly (therefore with the UI), the certificate confirmation dialog never appears the readings from the machine occur without errors.

In your last reply you asked if I was sure I was setting the configuration parameters before the first instance was created, I believe that is the case but I tried to refactor anyway but this made no difference.

Thank you for the support

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

More
16 Jan 2020 20:10 #8141 by support
Hello,

I am surprised that you still got the confirmation window in the cases you described. Are you sure you are setting the configuration parameters before any static methods calls on EasyUAClient are made and before its first instance is created?

Anyway, following statement - also done early, under the same conditions I just described - completely turns off any window interaction:
EasyUAClient.SharedParameters.PluginSetups.FindName("UAWindowsFormsInteraction").Enabled = false;
And, to be absolutely sure (that the service wouldn't be recognized as console app instead), you may also do:
EasyUAClient.SharedParameters.PluginSetups.FindName("UAConsoleInteraction").Enabled = false;

I believe you can still have just one build of your program. The necessary "switch" can be made in runtime, by giving it a command-line option, or by detecting that you are running as a service.

I hope this helps.
Kind regards

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

More
16 Jan 2020 12:55 #8139 by SolutionNow
Today I was able to try your suggestions at a client where we have the problem of the notification window. At least in this case the notification window said the problem is that self-signed certificates aren't trusted. I tried with Trusted Issuers and adding the URL to the TrustedEndpointUrls and AcceptAnyCertificate but the confirmation window appeared in any case.

It seems the best solution would be to divide our program in two programs: the current one with a user interface for testing and configuration, and a pure windows service for production. So if you could produce the documentation necessary to run our program as a Windows service without a user interface that would be greatly appreciated.

Thank you again

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

More
09 Jan 2020 14:16 #8127 by support
Thank you for more details.

What you wrote does not change fundamentally change my recommendations from the first reply, so please stay with them. But there are additional points which I can add now:

Your application is somewhat special in the fact that is somehow runs with UI, and sometimes without. The reason why QuickOPC shows the dialog is because there is WinForms used in your project; if it were a pure Windows service, WinForms assemblies wouldn't be in the project, and QuickOPC wouldn't show the window. I suggets that you study the following parts of the documentation as well:

opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ited%20User%20Interaction.html

Of course, if there was no way for QuickOPC to interact with the user, and everything else stayed the same, the result would be that the OPC UA connection would fail - but immediately, not after 30 seconds. But disabling the user interaction is still recommended if you somehow know that it is not possible. It can be done, but there is no example for it in the documentation. I can put it together for you. But because the primary problem to resolve is that your code needs to actually trust the server, I'd like to wait until you achieve this first goal (ideally by using Trusted Issuers, but as an insecure fallback, AcceptAnyCertificate or TrustedEndpointUrls can be used). After that is confirmed, we can return to the secondary issue - and that is, preventing the user interaction.

Regards
Best regards

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

More
09 Jan 2020 09:33 #8125 by SolutionNow
At the moment I am unable to read the documentation you provided about the Trusted Issue store and try to use them to implement a solution, I will do this only next week. I can clarify the points you felt were unclear however:

There are parts of your post that are not clear. Please clarify:
1. You wrote "set the property OpcLabs.EasyOpc.UA.UAEndpointDescriptor.CertificateAcceptancePolicy = true;". This makes no sense as it is not syntactically valid. Please correct.
4. Setting AcceptAnyCertificate to 'true' should work (although it's insecure). Please send me the piece of code that you have used to do it, for me to review it.


My apologies, I quickly copied this yesterday. Our program is a Windows Forms app which essentially has only a single form, and these two lines of code are called in the Form_Load event of that form:
EasyUAClient.SharedParameters.EngineParameters.CertificateAcceptancePolicy.AcceptAnyCertificate = true;
 
foreach (int resourceID in enterpriseSolutionDataSet.opcUA_ResourceOPCNode.Distinct().Select(r => r.ResourceID)) --Loop to connect to all OPC machines
{
        EasyUAClient.SharedParameters.EngineParameters.CertificateAcceptancePolicy.TrustEndpointUrlString(enterpriseSolutionDataSet.opcUA_ResourceOPCNode.First(r => r.ResourceID == resourceID).ServerUri);
}

2. I do not understand what you mean by "stays in the background". Did you want to say that it has a window, but is overlapped by other windows on the desktop? Or that it runs in a desktop-less session, so nothing is being displayed at all?
5. You wrote that "We have a program that uses your library that is launched by windows service. ". This is not fully clear. Is your program the Windows service itself? Or, is there some other Windows service that, in turn, launches your program?


As I said, the Windows service launches our program, and this service opens it in a desktop-less session, nothing is displayed.

3. If nothing is displayed by the application, how do you know that the notification window is being displayed somewhere? What are the actual symptoms?


Naturally there is no visual confirmation in this case that the window is being displayed. But if we launch our program directly it does open in the desktop we see the notification window presented. Naturally this window is not opened with all machines we use our software to communicate with, but the notification window always appears when:
  • our program is opened in the desktop environment
  • and attempts to communicate with specific machines (machines that were probably configured incorrectly)
Even when our program is opened in the desktop environment, if we do not give the ok to the notification window within 30 seconds, our program will not be able to communicate with the machine and it saves no data, and this is logical.

The way we confirm that the program is not functioning correctly is that our program saves nothing to the database, which it would otherwise do every few seconds. In other words, if we attempt to communicate with a machine that doesn't cause the notification window to be presented in the desktop environment the program works correctly also in a desktop-less environment. But if we communicate with a machine that does present the notification window, it does not work correctly in the desktop-less environment.

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

More
08 Jan 2020 17:21 - 08 Jan 2020 17:22 #8123 by support
Hello.

First of all, it should be said that security-wise, for both the application with UI and without it, the proper solution of this is to place the server's certificate into the Trusted Issuers store. See:
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...%20Instance%20Certificate.html
- opclabs.doc-that.com/files/onlinedocs/QuickOpc/Latest/User%2...ic%20Certificate%20Stores.html
- kb.opclabs.com/UA_Configuration_Tool_Overview

When the server's certificate is found in Trusted Issuers, no user interaction takes place. Any other solution should be considered less secure or insecure, but of course you are free to use it if you decide to.

The Forum topic you linked to deals with a specific kind of certificate validation error, and is not related to your issue.

There are parts of your post that are not clear. Please clarify:
1. You wrote "set the property OpcLabs.EasyOpc.UA.UAEndpointDescriptor.CertificateAcceptancePolicy = true;". This makes no sense as it is not syntactically valid. Please correct.
2. I do not understand what you mean by "stays in the background". Did you want to say that it has a window, but is overlapped by other windows on the desktop? Or that it runs in a desktop-less session, so nothing is being displayed at all?
3. If nothing is displayed by the application, how do you know that the notification window is being displayed somewhere? What are the actual symptoms?
4. Setting AcceptAnyCertificate to 'true' should work (although it's insecure). Please send me the piece of code that you have used to do it, for me to review it.
5. You wrote that "We have a program that uses your library that is launched by windows service. ". This is not fully clear. Is your program the Windows service itself? Or, is there some other Windows service that, in turn, launches your program?

Best regards
Last edit: 08 Jan 2020 17:22 by support.

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

More
08 Jan 2020 16:49 #8122 by SolutionNow
Hello,

We have a program that uses your library that is launched by windows service. Being launched by a background service, the program also stays in the background. This creates a problem when at times a dialog box is opened asking for confirmation within 30 seconds of the OPC certificate like this:


Being that program is always in the background is impossible to confirm the certificate. One solution I found here was to set the property OpcLabs.EasyOpc.UA.UAEndpointDescriptor.CertificateAcceptancePolicy = true; But this does not seem to solve the problem. I saw a similar discussion here in the forum but no final conclusion was posted if the property worked correctly or not.

Do you have an update on the matter or maybe you can tell me an alternative?

Thank you

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

Moderators: support
Time to create page: 0.448 seconds

      

 Recommend this on Google