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.

Self-signed certificate to apply

More
14 Apr 2023 04:38 #11693 by support
Hello,
yes, it is clear now, and yes, the cause you described is the right cause.

You have to understand that this is a support for QuickOPC. That is how every forum post is read and understood. Unless you specify that the specific error or problem came from a part that is different from the part that uses QuickOPC, it is definitely gong to cause misunderstanding.

In addition, if you have a problem with a certificate that you generated yourself (not QuickOPC-generated certificate), and it is a problem reported on the server side, then it is not a problem for this forum, which is for QuickOPC support only.

Regards

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

More
13 Apr 2023 19:48 #11692 by samirhaj
Yes, that is correct, the message thrown from OpcUa server not by QuickOpc. What I said is that when I ran my OpcUa client application, in the console was a message and I found exact the same message in the OpcUa server that we have from OPC Foundation. (We also have the source code of this OpcUa server). I searched in the source code and found exact the same message that I got in the console of my client application. The message and the part of the code I pasted in my previous post was from the source code of the server. How the message was transferred from server to the client, that is something I do not know as well!

I think what message said was that server couldn't find the Application URI in the client certificate (because I didn't put application URI in the SubjectAltName of the client certificate that I have created. Actually, the term "URI" in the SubjectAltName of my "own" long-life client certificate was missing). Does the whole things sound more clear now?

Best regards.

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

More
13 Apr 2023 14:10 #11691 by support
I am afraid that you are somehow mixing the output from the client (QuickOPC), and your server. As far as I can tell, the message you reported ("The Application URI could not be read ...") is not emitted by our library. We do have such message inside (not in our own code - it is in the code from OPC Foundation), but the full text is slightly different, and moreover, the method where it appears is only called with a parameter that disables it. If you are insist on the fact that this message is coming from the QuickOPC part, I will need a reproducible scenario (project + steps to do) to investigate further.

For requirements about ApplicationURIs, your reference should be the OPC UA specifications. You can choose them by your own, but not quite freely. Out of my head, I can think of two "hard" requirements:
- All ApplicationURIs in the system must be unique (no two UA applications can share the same ApplicationURI)
- ApplicationURI in the Server certificate must be the same as URI of namespace 1 in the server's NamespaceTable, and also the same as the first entry in the ServerTable of the server. (Application URI in the Client certificate does not have similar restriction).

Regards

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

More
12 Apr 2023 14:20 #11685 by samirhaj
No, I am using an earlier version as our company still using a version of EasyOpcUA of 5.54 and 5.55. It's a big company so everything takes time till some purchase takes place :).

Best regards.

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

More
12 Apr 2023 12:54 #11684 by support
Are you on QuickOPC version 2022.2?

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

More
11 Apr 2023 20:18 #11681 by samirhaj
Ok, I see .. Thanks for your prompt reply.

I think I understood why it didn't happen earlier. What I just observed is that the QuickOpc auto-generated certificate was thrown in the OPC Foundation (Machine Default and UA Applications) folder and my "own" certificates was removed when I run the application without answering to the pop-up message that I mentioned. And from there on it runs with not such message after. I have not looked at the console before so I guess the message was there before as well until the certificate was replaced with QuickOpc auto-generated one. I suspect this happens because I didn't answer "Yes" to the message when it asked "The Application URI could not be read from the certificate. Use certificate anyway? [Y/n]:" ... Do you agree?

And you are right, I found a line of code (C#) of the OpcUa server which says;
string uriFromCertificate = Utils.GetApplicationUriFromCertificate(certificate);
if (string.IsNullOrEmpty(uriFromCertificate))
{
string str = "The Application URI could not be read from the certificate. Use certificate anyway?";
}

So as you mentioned when SubjectAltName is not present or it's empty this message is thrown by the server. But when I double click on my own certificate it contains a SubjectAltName.

I see that the Application URI should go to the "SubjectAltname" as you said. I have now couple of questions;

- From where can I get the Aplication URI to put it as SubjectAltname?
- If I answer Yes to the message that says "Use certificate anyway?" will the problem be fixed even if I do not put Application URI in the SubjectAltName?
- QuickOpc auto-generated certificate has a SubjectAltName and my certificate has some other SubjectAltName but it is not empty or null. Why it does not complain with the same message on QuickOpc certificate but it does complain on my certificate?
- If I use the same SubjectAltName that is in the QuickOpc auto-generated certificate for my own certificate's SubjectAltName (similar to what I did with SubjectName), will this problem be solved?


Best regards.

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

More
11 Apr 2023 19:42 #11680 by support
The message tells you that the SubjectAltName extension in the certificate is not present or contains an empty string. It should contain the Application URI. That is required by the OPC UA spec.

Not having the ApplicationURI in our "own" client certificate should not be a problem on the client side per se, but such certificate may very well be rejected by the other party - the OPC UA server.

I do not know why it has not appeared earlier.

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

More
11 Apr 2023 17:19 #11679 by samirhaj
Thanks for your answer.

Everything seems fine but after generation of the certificates and putting them in the right place with the same subject name as auto-generated certificate, except a message that didn't appear right after I put the new certificates, but it started to appear now after a few days. I see the message on console when I run my application with the new certificates. The message is "The Application URI could not be read from the certificate. Use certificate anyway? [Y/n]:"
It does not seem like that it stops OpcUa communication. I have not answered Yes in the console and even if just click the console it continues running with the OpcUa communication that is working.

What is this message about? Should I pay attention to that or just answer Yes to the message and go ahead? And my wonder is that why is started to appear after some days and didn't appear right away after new certs was applied?

Best regards.

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

More
03 Apr 2023 10:47 - 03 Apr 2023 10:49 #11651 by support
Hello,

no released version of QuickOPC (2022.2 is the latest currently) supports private key passwords. This feature will be available in version 2023.1. You need to save the PFX without the password.

If multiple UA applications are on the same computer are are configured to share the same certificate store(s), they will share them. Each application has its own certificate in these stores. The certificates differ by their subject name by which the applications can find them. If the trusted peers and trusted issuers stores are shared, then all UA applications using these stores trust the UA applications presented by the certificates in these stores.

Regards
Last edit: 03 Apr 2023 10:49 by support.

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

More
03 Apr 2023 09:32 #11650 by samirhaj
Ok, Thanks for the clarifications.

In an earlier reply to the same discussion, you mentioned to place the .DER part of the certificate in the certificateStore and the private key part in the format of PFX in the "private" folder of the store. You also mentioned that earlier that the older version of QuickOPC (which I am using as well) does not support the password protected private key. So if I put my PFX private key (which I have generated externally and it is password-protected) in the store, will it work with QuickOPC ?

You have clarified very well regarding how the client and server certificates should work, but in my case I have both QuickOPC client and my OPC UA server always running on the same PC. How will that work regarding the placing of the certificates since I have one Certificatestore?


Best regards.

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

Moderators: support
Time to create page: 0.062 seconds