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.

Profiles

The VTScada OPC UA Client driver is designed to support the profile described by the URI http://opcfoundation.org/UA-Profile/Client/Minimum UA Client Profile. However, your device may vary. There are 4 profiles of OPC UA, as follows:

Standard UA Server Profile
(May be supported by VTScada. Requires verification)

Software servers installed on computers.

  • Kepware (Tested successfully)
  • Matrikon (Tested successfully)
  • Schneider EcoStruxure (Tested successfully)
  • Autosol Communication Manage (ACM) (Specialty version, tested successfully)
  • Triangle Microworks (Tested successfully)
  • Mission Controls OPC cloud server (Tested successfully)

Embedded UA Server Profile
(May be supported by VTScada. Requires verification)

Embedded in PLC components.

This is a less capable profile than Standard, notably without the Datachange Facet, which allows the server to use deadbanding. This is a key function to limiting the amount of data returned from field devices and therefore some manufacturers include the Datachange Facet to their version of the Embedded profile.

  • ABB AC800M PLC has an OPC UA module and states embedded (Not tested).

Micro Embedded Device Server Profile
(May be supported by VTScada. Requires verification)

Embedded in PLC components. Less capable than Embedded.

  • Schneider M580 PLC (Tested successfully)
  • Codesys PLC (Tested successfully)
  • Mitsubishi Melsec PLCs FX OPC card (Not tested)
  • Siemens S7 1500 PLC (Specialty version. Tested successfully)
  • Prosoft (Tested and unsuccessful. There are issues with security certificate incompatibility)
  • Emerson RX3i (Tested successfully. Do not confuse with the GE RX3i)
  • Red Lion DA10D (Specialty version. Tested successfully)

Nano Embedded Device Server Profile (Not supported by VTScada)

Embedded in PLC components. Less capable than Micro Embedded. Excludes security and subscription services

If you have a VTScada application running with OPC UA you can check the profile of the device by opening the driver properties folder, selecting the Diagnostics tab and clicking the Details button.

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.

The configuration option, "Allow unsecured connections", permits the driver to use a connection endpoint with a security policy of #None where no messages are signed or encrypted (integrity and confidentiality).
Where encryption or cryptographic signing of communication is desired (recommended), a trusted certificate is required at both the OPC UA server and the VTScada OPC UA Client driver to verify identity.

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.

VTScada has no mechanism to renew certificates automatically. 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.

VTScada Server Fail-over

Every VTScada server will (must) have its own certificate. On the backup VTScada servers, the hostname in the Subject field will be similar to CN=backup.example.com. Configure the certificates on both the primary and backup VTScada servers to use the same use the same "Friendly Name" for their certificates. This will allow two different client certificates to be used on the primary and backup machines. This name should be the same on all client machines (VTScada backup servers) because it is not in the certificate. The Friendly Name is then used in the OPC UA Client driver configuration so that the single name can identify the required certificate on each machine.

Note that the certificate Friendly Names can be created when generating the first certificate on a client machine. Others are created using the Windows certificate manager utility.

 

You will also have to trust the backup client certificate on the OPC UA server and trust the server certificate on the VTScada client / backup server.