if you create the self-signed application instance certificate "outside" the SDK yourself (with OpenSSL, or whatever tool) and you miss any of the little things related to it's content (e.g. OPC UA requires certain fields to be set in a certain way, usage, extended usage, common name, URI) and on startup the SDK will recognize wrong certificate content of it's own certificate (e.g. does not match to the configuration, does not match to the specification, does not match the private key), the application will refuse to startup.
So you can not (at least not so easily) exchange the own certificate (key pair). For that reason we have (in contrast to many other SDK) created a feature/function that autocreates the certificate (initially) for you. Because the certificate's private key is "private", it should reside in protected storage/folder, and never be shown anybody. Only the public key is to be given outside. In order to create the (initial) key pair, your application should have elevated admin rights when being executed with "/install" argument (typically done by the msi-setup that you create around your final application, being the last post install step).
See deployment chapter in documentation:
https://documentation.unified-automation.com/uasdknet/4.0.0/html/L1Deployment.html
Thereafter, if your client has proper certificate key pair and the server has proper certificate key pair, you can start working on "both-sided" trust of the public-key vice versa. If both sides have trusted the public key of the opposite, the certificates will be validated, including coming from the correct host/IP and having the correct URI (to detect man in the middle). Thereafter the secure connection will work like a charm.