How to use certificates for OPC UA security

How to use certificates for OPC UA security

This article provides an overview of how to use X.509 certificates in order to enable OPC UA security. It links to further how-tos that explicitly describe the necessary steps to create certificates and add them to the configuration of either the OPC UA Driver or the OPC UA Process Gateway.
Furthermore, the two ways of certificate management and their difference are presented.

How to create and setup certificate handling in OPC UA

The following articles provide step-by-step guides on how to create and configure certificates for OPC UA. 
  1. Self-signed certificate handling
    1. How to setup the zenon OPC UA Process Gateway with a self-signed certificate
    2. How to setup the zenon OPC UA Driver with a self-signed certificate
  2. CA-signed certificate handling
    1. How to setup an own Root Certificate Authority (CA)
    2. How to setup the zenon OPC UA Process Gateway with a CA-signed certificate
    3. How to setup the zenon OPC UA Driver with a CA-signed certificate

General information about certificate management

OPC UA (similar to protocols based on SSL/TLS such as e.g. https) makes use of certificates based on the X.509 standard. Those certificates mainly contain an identification of the system and its application (e.g. hostname and application URN) and a public key. To confirm their validity, they are additionally signed by a private key.
Depending on the type of this signature, we distinguish:
  1. Self-signed certificates
  2. CA-signed certificates
When used correctly, there is no trade-off in terms of security (i.e. neither of them is "more secure" than the other one). The difference is only the way the certificates are handled and distributed.

Self-signed certificates

A self-signed certificate is a certificate that is signed by its own private key (i.e. the private key matching the public key that is part of the certificate itself).
It is therefore only trusted "by itself" and not by any external authority.
Each system that wants to communicate with a counterpart providing a self-signed certificate therefore has to explicitly define whether the certificate shall be trusted or not.
This usually requires that certificate files have to be copied between the client and server systems.

In a zenon OPC UA installation, this means the following:
  1. The certificate file of the OPC UA server (e.g. the zenon OPC UA Process Gateway) has to be copied to and configured in the OPC UA client that wants to communicate with it
  2. The certificate file of the OPC UA client has to be copied to and configured in the OPC UA server that wants to allow the communication with it
Idea
This setup makes sense for small installations, e.g. one client talking to one server.
In a larger installation, using CA-signed certificates may be preferred due to a reduced managment overhead.

CA-signed certificates

In contrast to a self-signed certificate, a CA-signed certificate is a certificate that is signed by the private key of a Certificate Authority (CA).
It is therefore implicitly trusted, if the CA is trusted.
Each system that wants to communicate with a counterpart providing a CA-signed certificate therefore only needs to trust the CA.
This usually requires that only the certificate file of the CA has to be copied to all involved client and server systems.
Alert
Please note, that the zenon OPC UA Driver always requires the certificate file of the server it shall talk to.
In addition to its own certificate, a CA has to provide an up-to-date and valid Certificate Revocation List (CRL). CRLs are usually issued with a much smaller period of validity than the CA certificate itself (e.g. 30 days vs. 5 years) and have to be distributed to all involved systems (similar to the CA certificate file itself).

In a zenon OPC UA installation, this means the following:
  1. The certificate file of the CA has to be copied to and configured in all systems (both, OPC UA server and OPC UA client(s))
  2. A current and valid CRL of the CA has to be copied to and configured in all systems (both, OPC UA server and OPC UA client(s))
  3. When using the zenon OPC UA Driver:
    The certificate file of the OPC UA server (e.g. the zenon OPC UA Process Gateway) has to be copied to and configured in the OPC UA Driver that wants to communicate with it


Idea
This setup is usually chosen in larger installations where a server allows communication with more than one client, as it reduces the overall management overhead.
In larger organisation, the IT department may already provide the required infrastructure of a CA in order to manage and distribute certificates.

Chain of CAs

The certificate of the CA itself also has to be signed. Therefore, also the CA certificate can be either a self-signed one (we then call the CA a Root CA) or a CA-signed one.
In the latter case this means, we have got in total 3 certificates: The one for the OPC UA system (signed by CA1), the certificate of CA1 (signed by CA0) and the certificate of CA0 (signed by itself).
When using such a chain of CAs, each system requires the certificate files and the current CRL for all involved CA of the chain in order to work correctly.