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.

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.

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.

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.

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.