OPC UA Security

Security

Security trust must be set up correctly in order for clients to successfully connect to the Server. The process consists of copying the Server’s public application certificate, from the Application Certificate store, to the client’s Certificate Store and copying the client’s public application certificate to the Server’s Trusted Peer store. This specifies the trust between the two applications. This must be done for each client connecting to the Server. The type and use of the certificates is explained in the next manual section.

PKI Certificates

OPC UA relies on the Public Key Infrastructure (PKI) to establish trust between servers and clients.

In PKI, communication is only allowed with trusted partners, and is to be avoided otherwise. The means by which a partner's trust is established are certificates and in case of UA the "application instance certificate". An application instance certificate is unique. It is assigned once to an installed instance of an application. An application needs a list of trusted certificates to be able to decide whether to accept or deny a certificate. This list of trusted certificates is kept in a place called the "Certificate Store". Only directory based certificate stores are supported by the Server.

In general OPC UA applications use certificates to store the public keys needed for asymmetric cryptography operations. All security protocols use X509 version 3 certificates encoded using the DER format and should have a “.der” file extension. Certificates used by OPC UA applications shall also conform to RFC 3280 which defines a profile for X509 certificates when they are used as part of an Internet based application.

Public key certificates of client applications, users, and certificate authorities should be copied into the proper location within the Server’s certificate store. Refer to the Configuration section of this document for details of the store.

Upon initial startup of the Server, if an application certificate does not exist for the Server, a self-signed one will automatically be created and copied to the certificate store in the location specified for the Application Certificate. The Server’s public key certificate, the DER file, should be copied to the certificate store of all OPC UA client applications.

Optionally, application and user certificates created by a Certificate Authority may be used instead of self-signed certificates. These only need to be copied to the server's correct pki store location.

If the Server’s Application Certificate expires, a new self-signed one can be created by stopping the OPC UA service, deleting the application certificates from the Application Certificate store, the restarting the OPC UA service.

The Server’s Application Certificate is unique to the ACM install on a particular server. If the ACM install is moved to a different server, a new certificate will have to be created and copied to all OPC UA client stores.

If a secondary ACM system is installed as part of a fail-over scheme, the Application Certificates from all ACM installs will have to be copied to each client’s trusted store and client certificates copied to each server’s trusted store.

Sessions

The Server supports the following Security Policies for client sessions. These policies define what encryption method is used for secure communication between OPC UA client and server. Select the type of policy that is supported by both client and the Server. The policy “None” is only supported if the option “Accept Non-Secure Sessions” is selected on the properties tab.

The OPC UA client must specify the security policy to use when it connects a session to the Server.

Clients can browse the available security policy endpoints as described in the Client Connection section of this manual.

Policy	Message Mode	Security Level
None	None	0
Basic256Sha256	Sign	6
Basic256Sha256	Sign and Encrypt	106
Aes128_Sha256_RsaOaep	Sign	8
Aes128_Sha256_RsaOaep	Sign and Encrypt	108
Aes256_Sha256_RsaPss	Sign	10
Aes256_Sha256_RsaPss	Sign and Encrypt	110

Client Connection

The OPC UA Server accepts client sessions using either tcp or https protocol. The client specifies which protocol to use when it connects to the server. The following endpoint URLs are used by the Server where ‘localhost’ can be the IP address or network name of the server. If the client and Server are running on the same computer, you can use ‘localhost’ in the URL. The default ports are shown but can be edited in the configuration. Use these URLs when manually configuring a connection in the client.

opc.tcp://localhost:5337/asiOPC_UA
https://localhost:5338/asiOPC_UA

During start up, the Server will log messages into the ACM log viewer detailing the URLs that are in effect for that instance of ACM.

Optionally, the Server can register with an OPC UA Local Discovery Service (LDS) so the connections can be browsed across the network. To register with the LDS, select the “Register With Local Discovery Service” option on the properties tab. A free LDS can be downloaded from the OPC UA Foundation and is not included in the ACM install.

If using an LDS, the Server's application certificate will need to be copied to the LDS's trusted certificate store.

If not using an LDS, the URL opc.tcp://localhost:5337 can be used by a client as a discovery URL to browse the Server’s endpoints.

For clients to access data from the ACM system, the ACM service asiData must be running. If the Server is running but asiData is not when a client connects, the Server will return a status of “Bad Server Halted” to the client.

If asiData is stopped while clients are connected, all monitored items will updated with a “Bad Communication Error” status. The Server status will be updated to “Bad Server Halted”. If asiData is restarted, the Server will automatically re-establish the connection within thirty seconds, and begin publishing data updates to clients.

User Authentication

After a client successfully connects a session as described in the “Client Connection” section, the user creating the session must also be validated. The Server supports the following user authentication types:

Anonymous – the user creating the session connects anonymously. Anonymous users cannot write values to nodes in the address space unless the option is enabled in the configuration.
User Name / Password – the user creating the session is validated against Windows. If the user name password combination cannot be validated either in the Domain or on the local machine, the session is rejected. Optionally, a Window’s User Group can be specified that the user must be a member of to be validated successfully.
Certificate – the user creating the session is validated against user certificates in the Server’s PKI store. A valid X509 public key DER certificate for the user must be present in the Trusted Users store.
The settings for user authentication are on the Users tab of the OPC UA configuration.