OPC UA security basics: modes, policies and certificate trust

Three layers, three questions

OPC UA security is easier to reason about once you separate its layers. Each answers a different question:

• Secure channel: is the connection between these two applications authenticated and, if required, encrypted? This is controlled by the message security mode and the security policy.
• Session authentication: who is the user or application behind the session? This is the user identity token.
• Authorization: which nodes may this identity read, write or call? This is configured in the server.

Message security modes

Many servers ship with None enabled for convenience. On any network that carries real equipment, disable it.

Security policies

The security policy fixes the cryptographic algorithms. Older policies based on SHA-1, namely Basic128Rsa15 and Basic256, are deprecated in current OPC UA specifications and should not be used for new work. Basic256Sha256 is widely supported and remains a common baseline, while newer policies such as Aes128_Sha256_RsaOaep and Aes256_Sha256_RsaPss are preferable when both ends support them. Match the strongest policy that every client and server in the system can handle, and write the choice down.

Application instance certificates

Each OPC UA client and server application has an X.509 application instance certificate. When a secure channel is opened, each side checks the other’s certificate against its trust list. The typical first-connection experience is therefore a refusal: the server places the unknown client certificate in a rejected store, and an administrator moves it to the trusted store after checking that it really belongs to the expected client. The client does the same for the server’s certificate.

The certificate has to match the application it represents:

• The application URI in the certificate must equal the application URI of the application.
• The host name or IP address in the certificate should match how the server is reached.
• The validity period must include the current time, which makes correct clocks a security requirement (see time synchronization).

When one of these fails, clients report status codes such as BadCertificateUntrusted, BadCertificateUriInvalid, BadCertificateHostNameInvalid or BadCertificateTimeInvalid. The names usually point straight at the cause. Prefer certificates issued by a certificate authority you control over trusting many individual self-signed ones, and plan renewal before expiry, because an expired certificate stops communication abruptly.

User authentication

OPC UA supports four kinds of user identity token: anonymous, user name and password, X.509 user certificate and issued token. Practical guidance:

• Do not leave anonymous access enabled where writes are possible.
• Send passwords only over a SignAndEncrypt channel with a current policy.
• Use named accounts with the least rights needed, so that logs show who did what.

A practical checklist

1. Disable security mode None and the deprecated policies on every server.
2. Give each application its own certificate with the correct application URI and host name.
3. Keep a trust-list process: who approves a certificate, how it is recorded, how it is revoked.
4. Restrict the server port (4840 is the default for opc.tcp) to the clients that need it with firewall rules.
5. Synchronize clocks on every participant.
6. Apply least-privilege access on nodes and review it when roles change.
7. Log connection attempts and certificate rejections, and watch them.

For where OPC UA fits against other protocols, read OPC UA vs MQTT and the guide to companion specifications. For the wider security framework, see the practical introduction to IEC 62443.