As industrial systems grow and connectivity becomes a crucial part of these systems, security becomes an integral part of industrial connectivity. The OPC UA protocol standard created by OPC Foundation includes a security facet to provide an encryption and make sure the data is available to only authorized applications. Digital certificates are used for identification and encryption purposes within the OPC UA standard. Let’s look at what these certificates are and how they are utilized.
A certificate can be considered as an electronic ID of an 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 can be self-signed or CA (Certificate Authority) signed. The choice of when to use a CA-issued certificate versus a self-signed certificate depends on the installation and site requirements.
A self-signed certificate does not have a Certificate Authority. These certificates can be created by anyone and used in situations where the administrators of OPC UA applications can verify the claims by reviewing the contents themselves.
A CA-signed certificate has a signature generated by the private key associated with the certificate of the CA. In systems with multiple servers and clients, the installation of public keys in trust lists can very quickly become cumbersome. In these instances, the use of a company-specific CA can greatly simplify installation/configuration issues. The CA can also provide additional benefits such as management of certificate expiration and Certificate Revocation Lists (CRL).
OPC UA certificates are used for encrypting, decrypting, and signing the data as well as the identification of OPC UA server and client applications. The applications use certificates to identify each other and proceed establishing a secure channel, and then the data is encrypted. The certificates are utilized in an asymmetric encryption process, which is the mechanism used by asymmetric cryptography for encrypting data with the public key of an entity and for decrypting data with the associated private key.
Asymmetric cryptography, also known as "public-key cryptography," is an algorithm that uses a pair of keys: A private key that is kept secret and a public key that is generally made available. In this method, two applications use public keys to encrypt data and private keys to decrypt and sign data. In an asymmetric key agreement algorithm, both applications send their own public key to the other application.
When application A wants to send data to application B with confidentiality, application A uses the public key of application B to encrypt the outgoing data and application B uses its own private key to decrypt the incoming data.
When application A requires message integrity or to provide authentication for data sent to application B, application A uses its private key to sign data, and application B verifies the signature using the public key of application A.
ThingWorx Kepware Server is an application that can be used as both as an OPC UA server and as an OPC UA client. With the installation of the application, the Kepware OPC UA Configuration Manager utility is provided for certificate management and endpoint management for OPC UA server interfaces. ThingWorx Kepware Server has its own Trust Store where certificates are imported, exported, trusted, and untrusted. The OPC UA Configuration Manager utility allows a user to manage trusted or rejected OPC UA servers and client applications, in addition to managing instance certificates of ThingWorx Kepware Server.
With the installation, self-signed certificates are provided for OPC UA server and client features. These certificates are generated automatically using OpenSSL library and come with a validation period of three years. The OPC UA Configuration Manager utility allows several operations on instance certificates. Users can view the certificates, export the certificates to copy/transfer and make them available for other applications, reissue the certificates, and import their own certificates. Public key and private key should be provided together to be able to import a certificate.
To create your own certificate, the first thing to do is identify what type of certificates are needed. If there is a company-specific CA, it’s best to utilize it or consider having one to benefit from the advantages of using CA-signed certificates. A self-signed certificate can be generated using certificate generation tools such as OpenSSL’s command line utility. These certificates should follow X.509 specification and should contain unique identifier information. Once the certificates are generated, they can be imported into an OPC UA Configuration Manager utility to start using in OPC UA communication.
Digital certificates play a key role in satisfying the security requirements of OPC UA and the prevention of data and systems from being intercepted by unintended parties. Users should be aware of these certificates’ uses and properties. A strategy should be established beforehand to maintain the certificates, such as replacing certificates prior to their expiration date. With a proactive certificate management strategy, users can ensure that their OPC UA connections are as secure as possible while at the same time providing safe and easy access to critical system data for operations and digital transformation.