Professional OPC
Development Tools

logos

Online Forums

Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.

Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.

Do not use the Contact page for technical issues.

CryptographicException when connecting to Opc UA server

More
16 Jun 2021 07:10 - 16 Jun 2021 07:12 #9754 by support
We have been able to identify at least one possible cause of this issue, and suggest a solution. Please see: kb.opclabs.com/Error_%22The_specified_network_password_is_not_correct.%22 .
Last edit: 16 Jun 2021 07:12 by support.

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

More
26 Apr 2021 12:12 #9626 by Cavallari
Hello,

since the application works fine on the target machine (the most important thing ... :) ) , and , on the development machine, the debugger can be started with elevated privileges as workaround, as written before the issue is not critical to us.

Again, thank you very much for your support.

Jacopo

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

More
26 Apr 2021 10:02 #9625 by support
Thank you for information.

As I wrote, there were other incidents of the same error message. And they seem to be are always isolated to a specific machine - which appears to be "no different" in any significant aspect from those that do not show the problem.

We could not yet get to the bottom of it, because we never got to reproduce it. The code on the affected machine appears to be doing the same thing as elsewhere, except that it gets this error when it tries to access the certificate. So I suspect that some hidden configuration on the computer, or perhaps a specific Windows update (a patch - or a missing patch) can be responsible for it. I am afraid that no further progress is possible without having a reproducible scenario starting from a clean OS install, or a VM image of a machine that has the problem.

Best regards
The following user(s) said Thank You: Cavallari

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

More
23 Apr 2021 07:43 #9622 by Cavallari
Hello,

I confirm that the for now problem is present only on the Windows 10 development machine (machine A). On this machine, an OPC DA/UA server developed using Advosol server libraries (both DA and UA) is installed.

This Opc server application is also installed on a second development machine (machine B) running Windows 7 x64, but the Opc UA client library is working fine when connecting either to the local instance of the Opc UA server and other instances of the same Opc server on different machines. On this machine, the client application is different from the one on machine A, but it shares the same source code used for Opc-UA connection management with it (and QuickOpc library version as well).

Yesterday, I tested the client application that is having problems on machine A on the target machine (machine C) that is running Windows 10 x64 build 1809 - simply by copying the executable and related assemblies - and configured it to connect to the Opc UA server running on machine A (the Opc server mentioned above is not installed on machine C), and the connection works fine. I also checked the certificates in the C:\ProgramData\OPC Foundation folders , and they have been correctly created.

At the moment the problem persists only on the development machine, but this is not a critical problem, since it is possible to start VS2019 with administrative rights in order to debug the application.

Thanks again for your support, do not hesitate to write us in case you need additional information useful for solving the issue.

Best regards,

Jacopo

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

More
22 Apr 2021 15:52 #9621 by support
Hello,
thanks for more info.

The OPC Core Components are for OPC "Classic", so I doubted whether they could have influence. But I installed them too, and still no repro.

The errors in Windows log truly appear to be related and/or the cause of the problem - so thanks for that! Unfortunately it does not tell me enough details, or how to fix them.

Please help me understand - so, you have this problem on your development machine, and perhaps on some other(?), but generally you also have computers that do not show the problem, is that correct?

Many OPC UA applications (but not all) use the same mechanism (and even reuse the same physical folders). That leads me to one more question: Do you have other OPC UA Applications on the same machine? If so, what are they and do they work ?

Thank you

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

More
21 Apr 2021 13:19 #9620 by Cavallari
Hello,

thank you for support, but unfortunately we cannot provide the image of the development VM since it's too difficult for us to remove all the confidential information.. :(

I tried to apply updates for Windows 10 and now the version has been upgraded to 20H2, but the problem still persists. I guess it's not related to a specific version of Windows 10, but maybe to windows 10 itself.

A couple of additional "clues" that - hopefully - can help you to investigate the issue:
- I found that the Opc Core Components Redistributable (x64) version 3.0.107.24 package is installed on the machine (it is necessary for our simulation server). I tried a repair operation on the installer, but it did not help. Maybe this is a difference between your test environment and ours?
- I noticed that every time the client application perform an Opc UA operation, some errors are logged to the windows. They are all related to errors in opening/saving cryptographic keys. You can find the export of the logs attached (I included the en-US language to the export as well).

File Attachment:

File Name: Cypto-NCrypt.zip
File Size:4 KB


Thanks again for your support,

Best regards.
Attachments:

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

More
21 Apr 2021 09:32 #9619 by support
Hello.

I checked the Windows 10 versions we are using. There is a mix. Some computers are on version1903 (mainly the test computers), some on 2004 or higher (mainly development computers), and so on. I could not find any that was on version 1909.

So I started a new round of tests - downloaded ISO of that version from Microsoft, made a fresh OS install. I then attempted to reproduce the problem, but again without success. I used different approaches (always start first with elevated privileges, or not at all, etc.), always returning to the snapshot of the fresh OS install. I used application from the QuickOPC installation (such as the OPC UA Demo App), which should in principle be no different in this behavior from your apps.

I noticed you have a VM too. Is it in some virtualization software, or in the cloud? If it is in the virtualization software, can't you strip it off of any confidential/unwanted information, and make the image available to us? I will get you a discount on next version upgrade or upgrade assurance extension if you were willing to help us to such extent.

Best regards

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

More
20 Apr 2021 08:41 #9618 by Cavallari
Thank you very much for your quick response.

In order to start again from a "clean" situation, I deleted the whole root folder C:\ProgramData\OPC Foundation, and run again my test application, once with no privileges and once again (after deleting the certificates folder) with elevated privileges.
Each time the application is started, the folder is properly recreated (I suppose giving it default access rights according to the user that created the folder itself) together with the relevant certificate, but the application can connect only when started with elevated privileges.

Then, I performed another test, by creating a "standard" (not belonging to the Administrators group, but only to the Users group) local user, and starting the application by specifying this user, this time without deleting the certificates folder, but the behavior is the same...

In addition, I tested the application on a different machine having Windows 7 x64 (and belonging to an AD domain) and run it for the first time with a standard (domain) user, and it worked (relevant certificate is correctly created in the certs folder at the first run).
Moreover, I tested on the Windows 10 machine another application that I developed before (using package 5.56.1073 to be precise) and that was properly running on the Windows 7 x64 machine, getting a different kind of exception (OPC-UA service result - Could not create a certificate via a proxy) even if the application is run with administrative privileges (in both cases, no certificate is created in the certificates folder(s)).

Maybe the issue could be related to OS vesion?

Thanks again for support.

Jacopo

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

More
19 Apr 2021 15:23 #9617 by support
Hello,

thank you for the detailed report. You are not the first one with "The specified network password is not correct." error. We were unable so far to reproduce the problem on our side, and without a repro it is very difficult to resolve it.

Here is, however, comments to your findings, which might help you understand a bit:

- "... the exception is thrown regardless of the endpoint that is specified for the connection": We know that this exception is related to accessing the client-application certificate; and this certificate is needed during the connection process. This explains why it happens during the connection, but does not depend on the target endpoint.

- It is expected the the first time the application is run, elevated privileges are needed in order to store the generated certificate. This is OK. However, the subsequent attempts should use the already-generated certificate in the store, without a need for having elevated privileges - and this is where it fails.

- "tried 5.56.1073 fully licensed....": As a note, the problem is not related to licensing at all.

- "if this second application is run with elevated privileges, an exception with the message “OPC-UA service result - Self Signed Certificate is not trusted” is thrown.". This is actually a "success", because it means that the connection process has proceeded past the "The specified network password is not correct.", and what remains is a certificate trust issue between the client and the server, which can be resolved separately.

So far, we had success advising users to clear their certificate stores, but apparently, in your case, that only helps if you continue running with elevated privileges.

Can you check the permissions on the directories of the certificate stores, to see if they can be read by the user that is running the apps, without elevation?

The only other action I can think of on our side is to redo the attempts to reproduce the problem. I will do so, and report here. Give me some time.

Best regards

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

More
19 Apr 2021 13:54 #9616 by Cavallari
CryptographicException when connecting to Opc UA server
Dear support service,
we’re experiencing problems in connecting to an Opc UA server through OpcLabs.QuickOpc 5.60.107.
As soon as our application tries to perform an operation (browse/read) on the Opc server, a CryptographicException with the following message is thrown:
UA SDK error (System.Security.Cryptography.CryptographicException) in 'ApplicationInstance.CheckApplicationInstanceCertificate'. The specified network password is not correct.
+ The error occurred while creating or checking the (client) application instance certificate. Check event log entries for errors and warnings.
+ The certificate generator path was "C:\Users\Cevolani\source\repos\ConsoleApp1\bin\Debug\Opc.Ua.CertificateGenerator.exe".
+ This is an engine-level error.
+ The client method called (or event/callback invoked) was 'ReadMultiple'.

Searching on the forum, I found that the problem could be related to client-side certificates:

www.opclabs.com/forum/ua-com-product-lifecycle-licensing/260...-do-we-access-the-easyuaclient

so I followed the instructions described in the post, but without success.
The strange thing is that the exception is thrown regardless of the endpoint that is specified for the connection (I tried both an existing and an invalid server), so I suspect that the exception is thrown before the connection attempt.
Starting from a “clean” situation (no certificate for the client application is present in the “C:\ProgramData\OPC Foundation\CertificateStores\” folder or in any of its subfolder), when I start the application, a certificate (that, considering its name, is related to the client application) is created in the “MachineDefault\certs”, “MachineDefault\private” and “UA Applications\certs” folders, but the exception is thrown. The file has the same name in all the three folders.

Starting again from a “clean” situation, but running the client application with administrative rights, the certificates are re-generated, and the application succeeds in connecting and reading from the Opc Sever, but, after this, if I start again the application without administrative rights, the exception is still throw.

Our test environment is the following:
  • Virtual machine with Windows 10 x64 Build 1909. No domain configured (machine is in the default workgroup), the local user running the application is a local administrator, but usually the application is executed without elevated privileges.
  • Microsoft Visual Studio 2019
  • C# Console application (Framework 4.7.2) using OpcLabs.QuickOpc 5.60.107 NuGet package, in demo version. I also tried 5.56.1073 fully licensed: the result is the same (exception is thrown), but no certificate is created in the CertificateStores folder. If this second application is run with elevated privileges, an exception with the message “OPC-UA service result - Self Signed Certificate is not trusted” is thrown.

Here follows the sample code that generates the exception:
EasyUAClient.SharedParameters.EngineParameters.ApplicationParameters.ApplicationManifest.ApplicationName = "OpcUAClientTestApp";
EasyUAClient.SharedParameters.EngineParameters.CertificateAcceptancePolicy.AcceptAnyCertificate = true;
 
this.ClientUA = new EasyUAClient()
{
    Isolated = true,
};
 
this.ClientUA.IsolatedParameters.SessionParameters.SessionConnectTimeout = 3000;
this.ClientUA.IsolatedParameters.SessionParameters.UserIdentity = OpcLabs.BaseLib.IdentityModel.User.UserIdentity.CreateAnonymousIdentity();
this.ClientUA.IsolatedParameters.SessionParameters.EndpointSelectionPolicy.CustomPolicySpecifier = "None:None:Binary";
 
try
{
    UAEndpointDescriptor endpointDescriptor = new UAEndpointDescriptor(this.Endpoint);
 
    this.ClientUA.Read(endpointDescriptor, $"PLC1.Application.GlobalRetentive.G_FirstConfigDone");
 
    LogDebug("Read() succeeded");
}
catch (Exception e)
{
    LogException(e);
}

Please let us know if you need additional information.

Thanks in advance for support,
Jacopo

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

Moderators: support
Time to create page: 0.071 seconds