I am currently trying to implement the certificate based authentication with the .NET SDK. I want to use a certificate stored in a directory.
For test purposes I created a certificate with the Getting Started Client (see first screenshot).
After restarting the application (as asked by the demo), I try connecting to the CPP Server (has certificate based logon enabled). When trying to do so, I get the error code "BadIdentityTokenRejected".
In the certificates tab in the UA CPP Server config, I don't see any new client certificate.
How can I get the Getting Started Client to connect to an OPC UA server with a newly created certificate?
we would agree that the description/excamples do not realy show what is required for "User Authentication" with user certificate token to be used properly (instead of using user/pwd token, which is more easy to understand).
First the principle:
1) we have "application instance certificate" to identify trusted application for building up the secure communication channel
2) we have "user certificate" to identify a certain individual, that is assigned to a certain role (admin, observer, operator, ...), for building up the session and accessing NodeIDs that belong to this role.
Both certificates have totally different purpose and live in totally different stores. For the second is not only enough being "trusted", but additionally must be "assigned" to a role (user/role management in the server).
Second the User Certificate:
1) the advantage of user cert token over user/pwd token is, that you/person can identify yourself without typing in a pwd (the cert is all in one).
2) the idea is, that the user (on clientside) in posession of his personal certificate (e.g. on his Yubikey, smart card, dongle), and the server is configured with a list of tokens (user certificates, and or user/pwd, and other tokens) , that are assigned to "roles", hence access to certain NodeIDs/Information in the server.
3) the server must "know" the user (trusted) and must "find" the assigned role this user belongs to (user/role management on serverside).
4) the identification criteria of a user/pwd token is the "username", the identification criteria of a user cert token is "what"?, the thumb-print (bad idea would chage when cert expires), the content e.g. "subject" field containing some unique string (equivalent to username).
Third to your question (BadIdentityTokenRejected):
The Geting Started Client must point to a proper user certificate, to be used when activating the session (which happens after having created the secured channel, with a typically totally different certificate), and the server must "know" and have "assigned" this user cert (the content of subject field) to a specific role.
thank you for clarification. I did not know about the differentiation between application instance and user certificate.
In the example, what kind of certificate am I assigning? The user certificate or the application instance certificate? I am assuming it's the user certificate. How can I assign the missing certificate (and how to generate it?) in order to get the example working?
Many thanks
Josef
Last edited by josef.fleischmann on 08 Nov 2024, 15:45, edited 1 time in total.
thank you for clarification. I did not know about the differentiation between application instance and user certificate.
In the example, what kind of certificate am I assigning? The user certificate or the application instance certificate? I am assuming it's the user certificate. How can I assign the missing certificate (and how to generate it?) in order to get the example working?
the client example has a path to a certificate that should be used to identify the user during create session. Most probably you are accidently using the application instance cert.
You can use any cert that is trusted in the user-cert-store on the server-side and assigned to a role on the server-side. But taking the application instance cert and reusing again for user authentication (and assigning it to an e.g. administratore role in the server) is probably not good idea, because everybody who has access to the client application can authenticate himself as being an administrator.
You can create the cert with every tool that can create x509 (this would typically be done by some IT department) and this user cert must firstly being trusted and assigned to role in the server. Thereafter you can start your client, establsich secure connection (using the instance cert) and when activating the session utilize the user certificate.
The idea behind is that the server will have trusted some user-CA and this user CA has created/signed mutliple user-certs, and your client is using the user-cert (which represents you), and which is assigned to a role in the server's user management.
although it might not be a good idea to use the same certificate for both the application as well as the user, it should work, shouldn't it? I am trying to get a minimal example running to check, if the .NET SDK is able to connect to our OPC UA Servers with a certificate. Once this is done, I will build the proper certificates for production use.
We recently bought the licence for the .NET SDK. Right now, the certificate based authentication is blocking the further development of our product. I am looking for support on this issue. Could you please provide me with a step by step guide to get the "Getting Started Client" to connect with a file based certificate to the "UaCPPServer", which has "Accept all certificates" enable. Alternatively, how can I schedule a support call?
no, it will not work "out of the box", it will be trusted for application authetication, but even when technically being just an x509, user authentication, is different trust relation, in different trust store, and requires rolle assignement in the server. So it will not work "out of the box", plus we agree that is not good idea to reuse same certificate again.
The "Accept All" is no good idea either, not for application instances (and for users is not supported anyways), and should only be used in commissioning or in closed network scenarios, and only in combination with "proper" user authentication (anonymous user switched off completely). As shown in the description of CppSDK it will "ignore all errors" when validating the certificate, and hence is very dangerous setting (in fact switching off application authentication).
