Hi

We were able to fix the issue by recreating the own certificate.

Thank you.

Michael

Hi 

Thank you for your answer. 

The problem persists after recreating the own certificate. Is there a way to delete the application manifest file so that it will be recreated when recreating the own certificate?

Thank you.

Michael

Michael,

I think the question is way too hypothetical to bother with it at this point. The way the certificate is re-generated by QuickOPC is that the OPC UA application URI - as known to the application - is put into the new certificate. So unless there is some way of weird failure, after the re-generation this particular problem *will* go away.

Regards
 

Hi

Thank you for your answer. If we regenerate the own certificate and the problem persists, is it possible to edit the certificate and change the URI?

Michael

Hello.

I cannot tell with certainty what caused this. The NuGet version (5.80 or later) you are using is fine, it is actually the version which has the change that should reduce the number of such occurrences - but only into the future.

From the data, it looks like that something must have changed:

+ Application URI from the effective application manifest: uri:EBO-OPCClientCFG:UT03SVAW0002
+ Own certificate subject URL name from certificate sub-id "": uri:UT03SVAW0002:EBOOPCClientCFG:1.0.116.0

The two URIs are different. The URI can be given from your code, but if it is not, then QuickOPC generates one. And the new one (uri:EBO-OPCClientCFG:UT03SVAW0002) is more "stable", i.e. it should not change as long as the machine name and application name stay the same. The old one appears to be generated by the older algorithm, because it includes all the version numbers, which causes it to change with each new version - and that is what we have prevented in 5.80 and onwards.

So at this point I would just instruct the user to regenerate the certiicate as in my previuos post. 

Best regards

Hi,

Thank you for your answer.

Yes, we have a way in our software to invoke our "Administer OPC UA Application" dialog. The user have not changed the version of our app.
Currently our app is using Nuget version 5.80.278. When you say "We had to make a change in how the default UA Application URIs are generated to improve things going forward" , is the change done in a version newer than 5.80.278? 

If so, we shall upgrade to the newer version and create a new version for our customer.

Regards,

Michael

 

Hello.

I think you have a way in your software to invoke our "Administer OPC UA Application" dialog. Please have the user to invoke it, and in the dialog, switch to the Application Certificates tab, press the "Create/recreate own certificate(s)" button, close the dialog, and then reestablish the trust in the Kepware (i.e. let it trust the new client certificate).

This can happen if the user have upgraded to a new version of your app that it using a new version of QuickOPC. We had to make a change in how the default UA Application URIs are generated to improve things going forward, at the cost of one-time inconvenience at the upgrade time. 

If it was not after an upgrade, then I cannot easily tell what has caused it, but nevertheless, the procedure described should resolve it.

Best regards
 

Hi,

I have a customer that is trying to connect and browse OPC UA items. The server is Kepware UA. He is getting the following error:

Exceptions
Type: OpcLabs.EasyOpc.UA.Engine.UAEngineException
Data: 
HelpLink: 
HResult: -2146233088 (0x80131500)
InnerException:
    OpcLabs.EasyOpc.UA.Engine.UAEngineException: UA SDK error (Opc.UA.ServiceResult=0x80170000) in 'static Session.Create'. OPC UA service result - {BadCertificateUriInvalid}. The URI specified in the ApplicationDescription does not match the URI in the certificate. BadCertificateUriInvalid

See the attached error file. Any idea how to fix? Browsing with UA Expert is possible.

 

Thank you.

Michael