OPC UA Support & Security

The VTScada OPC UA Client driver supports the OPC Foundation’s specification #1.04. The features and capabilities of OPC UA are described by the specification in a number of “profiles”. An endpoint (client or server) states which profiles it supports to indicate the features and capabilities it has.

The VTScada OPC UA Client driver supports the profile described by the URI http://opcfoundation.org/UA-Profile/Client/Minimum UA Client Profile.

OPC UA Protocol Support

OPC UA has a layered protocol architecture. The most relevant parts are the protocol encoding and the transport protocol.

OPC UA Encoding Protocols

OPC UA has 3 protocol encoding variants:

  • OPC UA Binary. This is the encoding supported by the VTScada OPC UA Client Driver and is the most commonly supported and most compact one.
  • OPC UA XML. Currently unsupported by VTScada.
  • OPC UA JSON. Currently unsupported by VTScada.

OPC UA Transport Protocols

Communication with a server can be achieved using one of four transport protocols:

  • OPC UA TCP. This is the transport protocol supported by the VTScada OPC UA Client Driver.
  • SOAP/HTTP. This was not widely supported by the industry and deprecated since specification level 1.03.
  • OPC UA HTTPS. Currently unsupported by VTScada.
  • WebSockets. Currently unsupported by VTScada.

OPC UA Security

There are 2 layers of security. One layer secures the communication between server and client and the other authenticates the user to the server.

Transport Protocol Security.

This ensures privacy and integrity of the communications between server and client. It is achieved through a Public Key Infrastructure (PKI) using X.509 certificates in a similar manner to HTTPS.

The difference is that for HTTPS, a client (such as a web browser) receives an X.509 certificate from the server to which it is trying to connect and decides whether this is trustworthy. If it is, communication between server and client is encrypted and proceeds without user intervention. If the certificate is not deemed trustworthy, the user is warned and communication is halted. So long as trusted certificates are issued appropriately, this works well.

In OPC UA both client and server exchange X.509 certificates (they each have their own) and communication only proceeds if each end trusts the other. Trust is established if the certificate is derived from one that is already trusted (like HTTPS) or an administrator explicitly tells the server or client that the certificate from the other end is to be trusted.

Enforcing certificate trust ensures that the OPC UA Client Driver will only connect to the server you specify, and that the server will only accept connections from “trusted” clients.

The VTScada OPC UA Client Driver supports the following transport security policies:

Additionally, the following deprecated policies are also supported, although these should be avoided as they use the SHA-1 hashing algorithm, which was broken in 2017. Support for these is provided for compatibility with older servers that do not support newer algorithms.

Session Security

While transport level security protects the communication, session security authenticates a user, authorizes the user to be able to perform some actions, and denies the ability to perform others.

There are 3 types of session security, all of which are supported by VTScada.

  • Anonymous.
    An anonymous user need provide no credentials. The capabilities the server grants the user will likely be limited to monitoring non-sensitive data.
  • Username / Password.
    This is the traditional method of authentication, with a username and password being supplied that grants the user whatever rights are configured by the server. This is appropriate for all uses, from process monitoring and control to interactive applications generating reports or the like. It is portable across client machines, therefore (as long as the transport security permits), you can use a username and password from any client computer.
  • X.509 Certificate.
    The user is issued with an X.509 certificate. To be authenticated to the server, the client sends the certificate and is authenticated only if the server trusts the certificate. This is distinct from transport layer security in that the encryption keys associated with the certificate are only used to prove ownership of the certificate, not perform encryption. This restricts user access to computers that have the user certificate installed on them or, (if the client software permits it) can be read from an attached device such as a smart card reader.

Default Security Settings

The default setting of the VTScada OPC UA Client Driver enforces transport-level security and requires that appropriate X.509 certificates are supplied.

It is possible to use an unsecured communication mode, where certificates are not required, no authentication of server identity is performed and communication is not encrypted or digitally signed. Use options within the Diagnostics tab of the OPC UA Client Driver configuration dialog to do so. This is a temporary setting only and (by intent) will revert to requiring certificates and secure communication when the driver is reloaded. (For example, on application restart.) The VTScada OPC UA Client Driver will select the most secure mode supported by the server for transport layer security.

X.509 Certificates

For all secured communication, the OPC UA server and OPC UA Client Driver require appropriate X.509 (v3) certificates.

VTScada has the capability to generate self-signed certificates for use by the OPC UA Client Driver in the absence of another certificate generation mechanism. This provides an easy way to generate certificates when no Certificate Authority (CA) generated certificates are required.

Certificate Trust

A certificate must be “trusted” to be used. The trust can be achieved in 2 ways:

  • Implicit trust via the certificate issuer.
  • Explicit trust via manual user action.

If the certificate is issued by a trusted CA (i.e. the issuing CA has a root certificate in the appropriate “Trusted Publishers” store), then the certificate is implicitly trusted.

If the certificate is not issued by a trusted publisher, or is self-signed, then a manual user action is required to trust the certificate. Users undertaking such actions should verify, by inspecting the certificate thumbprint, that the certificate is the expected one as issued by the remote party, whether server or client.

Client Certificates

The OPC UA Client Driver must be provided with at least one X.509 certificate. This is used for identification and authentication of the OPC UA Client Driver to the OPC UA server, for transport layer security.

The server must trust this certificate. The server implementation determines how trust is established, but generally the server will allow an administrative user to instruct the server to trust it.

For self-signed OPC UA Client Driver certificates, the administrative user normally has to trust the certificate itself. For CA signed certificates, the administrative user normally has to trust a root certificate, from which the transport certificate is derived.

Depending on the user authentication mode, a second X.509 certificate may be required that is used in place of the traditional username/password authentication. Again, an OPC UA server supporting this user authentication method will be able to authorize access using that certificate.

A client certificate may also be used to supply an “application URI” for the OPC UA Client Driver when creating a session on the server. If your OPC UA server requires a specific application URI to be provided, you must incorporate this into the client’s X.509 certificate as a URL entry in the certificate Subject Alternative Name extension.

Server Certificates

An OPC UA server provides the OPC UA Client Driver with a certificate to prove its authenticity. For the OPC UA Client Driver to trust the server and establish a session with the server, the server’s certificate must be trusted by the OPC UA Client Driver.

This is achieved using the driver’s configuration folder. Conversely, a server certificate can have its trust by the OPC UA Client Driver removed should the need arise.

Server certificates MUST contain the host name as provided in the Endpoint URL specified in the driver’s configuration folder. This may be part of the Distinguished Name of the certificate or be in the Subject Alternative Names extension as a DNS record.

Certificate expiry and renewal

All certificates have an expiry date, and when they expire, certificates are no longer usable and communications with the OPC UA server will fail.

The OPC UA Client Driver will create ad-hoc alarms for each certificate in use, beginning 30 days before their expiry. The alarms will be set to normal when the certificates have been replaced.

There are no mechanisms with VTScada to automatically renew certificates. Self-signed certificates can be renewed by creating another and selecting it in the appropriate grid. Externally-provided certificates must be imported and then selected in the appropriate grid. It is up to you to ensure that all certificates in the VTScada system are renewed as required, including (for example) those for the primary and backup I/O server. New certificates will be used on the next connection attempt. You must also take action at the OPC UA server to trust new client and user certificates.

Server certificates require particular care when renewing (on the server) as when they are first sent to the VTScada OPC UA Client they will be untrusted and will require manual action to trust the new certificate. A secondary I/O server will only receive the server certificate when a connection is made to the server, so either a fail-over and manual trust will be required. Alternatively, the server certificate (if the server sends the same certificate to all clients) can be copied to the appropriate place on the secondary I/O server and trusted before a connection is made.