If you use OPC UA, you are likely at least somewhat familiar with OPC UA certificates. OPC UA client and server applications typically have Application Instance Certificates to provide application-level security. They are used for establishing a secure connection using Asymmetric Cryptography.
OPC UA certificates include a digital signature by the generator of the certificate. This digital signature can be self-signed or can be signed by a Certificate Authority (CA). Both types of certificates provide the same level of security and can be used in Asymmetric Cryptography. The major difference between CA signed and self-signed certificates in an OPC UA installation is the effort required to deploy and maintain the certificates. The choice of when to use a CA issued certificate versus a self-signed certificate depends on the installation and site requirements.
Many of our products leverage the OPC UA Configuration tool from the OPC Foundation to create and trust certificates and certificate authorities (CA). This tool actually installs with our OPC Data Client toolkit but is also available from the OPC Foundation. But how do we navigate this tool and the use of OPC UA certificates as a whole?
In this blog post, we will cover both methods of UA certificate signing, as well as the tool mentioned above for easily managing UA certificates for your OPC UA applications.
For most of us, it's useful to begin a discussion about OPC UA security certificates with a review of some important terminology. With OPC UA, a Certificate is basically an electronic "ID" that can be held by an OPC UA application. This "ID" includes information that identifies the holder, the issuer, and a unique key that is used to verify digital signatures created with the associated private key. The syntax of these certificates conforms to the X.509 specification and, as a result, these certificates are also called “X.509 Certificates”.
A Certificate Authority, or CA, allows you to control the creation and management of UA certificates. The certificate authority verifies that information placed in the Application Instance Certificate is correct and adds a digital signature to the certificate that is used to verify that the information has not been changed. Each CA has its own certificate which is used to create the digital signatures. A CA is also responsible for maintaining Certificate Revocation Lists (CRLs). A certificate revocation list is a list of certificates which have been revoked by a CA and should NOT be accepted by an Application Instance.
A self-signed Certificate is a certificate which has no Certificate Authority. These certificates can be created by anyone and can be used in situations where the administrators of UA applications are able to verify the claims by reviewing the contents themselves. A system that uses only self-signed certificates would not have a Certificate Authority or a Certificate Revocation List. OPC UA servers will typically auto-generate a self-signed certificate when they first start.
Asymmetric Cryptography is a process for cryptography which makes use of two keys – a Private Key and a Public Key. An OPC UA application will have a list of trusted Public Keys that represent the applications it trusts. This list of trusted Public Keys is stored either in the Windows Registry or a file folder. It will also have a Private Key that corresponds to its Application Instance Certificate. The OPC UA application can use a Public Key, from its list, to validate that the signature on a received connection request was generated by the corresponding Private Key. An application can also use the Public Key of the target application to encrypt data, which can only be decrypted using the Private Key of the target application (for a detailed breakdown of the types of cryptography, see this Exploring OPC UA post).
A Private Key is a secret number known only to the holder of a Certificate. This secret allows the holder to create digital signatures and decrypt data. If this secret is revealed to unauthorized parties then the associated certificate can no longer be trusted or used. It is replaced or, in the case of a CA generated certificate, it is revoked.
A Trust List is a list of certificates which are trusted by an application instance. When security is enabled, UA applications reject connections from peers whose certificates are not in the trusted list or if the certificate is issued by a CA that is not in the Trust List.
A Certificate Store is a place where Certificates and Private Keys can be stored on a file system. All Windows systems provide a registry-based store called the Windows Certificate Store. All UA systems can also support a directory containing the Certificates stored in a file which is also called an OpenSSL Certificate Store. In all cases, the Certificate Store needs to be secured, in that only administrators are allowed to write new entries. The security should follow the ‘least privileged’ principle, in that read or write access is only allowed to those who really need the data. This means that an administrator, for example, can store a Private Key but is not allowed to read them, and conversely an UA application can read such Private Keys, but cannot write them.
In some systems, a GlobalDiscoveryServer with Certificate Management may be deployed. The GlobalDiscoveryServer will either push certificates to clients and servers or allow servers and clients to pull certificates. The GlobalDiscoveryServer certificate management can manage all certificate deployments including Trust Lists, CAs and CRLs.
Now that we have a basic understanding of some the terms used when discussing OPC UA certificate management, we can look at the UA Configuration Tool mentioned earlier. For further information on OPC UA certificate management in general, please refer to the resources list below.
- OPC UA Specification Online Reference Section 6.1 Security
- OPC UA Specification Online Reference Section 8 Certificate Management
- OPC Foundation UA Github - UA Configuration Tool
In the video below, I walk through the creation of a Certificate Authority and Certificate via the OPC UA Configuration application, and the process of setting an OPC UA server or client (in this case, TOP Server) to use this certificate as its application certificate, including usage of the certificate in a test client.
Understanding how OPC UA certificates and certificate authorities work together to secure your process data is an important step when working with any OPC UA system. Subscribe to our blog for more useful technical topics and, as always, if you have any questions about managing OPC UA certificates with any of our products, please do not hesitate to reach out to our support team.
