Trusting server certificates

Secured OPC UA connections (Sign and SignAndEncrypt) are built on mutual certificate trust: UANode must trust the server's certificate, and the server must trust UANode's. Until both sides trust each other, a secured connection is refused — that refusal is the security model working, not a bug.

When to trust a certificate

• You expected to connect to that server — you (or your team) operate it, or its operator told you to connect.
• Ideally, the certificate's fingerprint matches the one the server operator published. The fingerprint is shown in the trust prompt and in the certificate manager.

When you connect to a secured server UANode does not yet trust, it asks right in the connect flow — trusting there is the normal path. The certificate manager is the power-user view for everything else: inspecting fingerprints, un-rejecting, cleanup, and exports.

When to reject one

• Anything unexpected. A certificate you cannot explain may be a misconfigured server — or someone impersonating it.
• Be strictest with endpoints reachable from the internet: a wrong certificate there can mean a man-in-the-middle reading or altering your process data.
• A certificate that changed without an announced renewal deserves a question to the server operator before you trust it again.

Making the server trust UANode

Trust is mutual: many servers refuse a secured client they do not know. Export UANode's own certificate from the certificate manager and install it in the server's trust list (in UaExpert-style servers this is usually a "trusted clients" folder or a one-click accept on the server console).

Connections with security None skip all of this — no certificates are checked, and nothing is encrypted. Fine for the demo server or a lab; not for production data.