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
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.
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.
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.
Best regards.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
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.
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.
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.
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
Please Log in or Create an account to join the conversation.
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.