OPC-UA Certificate Management

What is OPC-UA?

OPC-UA – for Open Platform Communications Unified Architecture – is an open-source industrial automation communication protocol. The protocol is developed and maintained by the OPC Foundation and was primarily designed to secure and standardize data flows between machines and information systems.

Certificate Management

‍

The concept of a certificate might seem abstract, but you encounter it daily when browsing the internet.

Certificates are identifiable in browsers by that little padlock in the web address bar. A certificate is essentially a digital seal of approval issued by a trusted third party known as a Certificate Authority (CA). More specifically, it's a digital file containing information issued by a third-party authority indicating that the website is secured by an encrypted connection.

They ensure that the site you are browsing is authentic and that no one can intercept the data exchanged.

‍

Certificate-Related Abbreviations

• SSL - Secure Sockets Layer
• CSR - Certificate Signing Request
• TLS - Transport Layer Security
• PEM - Privacy-Enhanced Mail
• DER - Distinguished Encoding Rules
• SHA - Secure Hash Algorithm

How does an SSL certificate work?

‍

You use this type of certificate to assert your organization's identity and to mutually authenticate clients and your web server to establish a secure, encrypted connection, which involves:

• The exchange of cipher suites and parameters to determine the cryptographic functions supported by both parties,
• The authentication of one or both parties in the exchange,
• Key exchange and symmetric session key generation.  

It is through this secure connection that users can transmit their information to your site without man-in-the-middle (MitM) and other attacks being able to intercept or decrypt the data.

OPC-UA application certificates

‍

‍

OPC UA applications require certificates to ensure the security of client-server exchanges. These certificates are of type X.509 v3 and contain a list of defined data elements.

Asymmetric cryptography uses two keys: a private key and a public key. 

Certificates include a digital signature. This digital signature can be self-signed (the signature is generated by the private key associated with the X.509 v3 certificate) or can be signed by a certificate authority (the signature is generated by the private key associated with the CA's X.509 v3 certificate). Both types of certificates offer the same level of security. Signatures can be generated using various algorithms, which offer different levels of security (128-bit, 256-bit, 512-bit, etc.). 

An OPC-UA application has a list of trusted public keys that represent the applications it trusts. This list is stored in a folder or in the Windows certificate store.

An OPC-UA application will also have a private key that corresponds to its certificate. The application can use a public key from its list to validate that the signature of a received connection request was generated by the corresponding private key. An application can also use the target application's public key to encrypt data, which can only be decrypted using the target application's private key.

There are different ways to manage certificates in an OPC-UA infrastructure.

‍

1. No certificates

‍

You do not use certificates, and in this case, exchanges between OPC-UA clients and servers are not protected. Exchanges are not encrypted and can be intercepted, meaning your system could be the target of man-in-the-middle (MitM) attacks.

Managing the security of your OPC-UA infrastructure without certificates is not recommended.

‍

2. Self-signed certificates (manually generated)

‍

‍

In this case, you generate your own certificates.

You must manually export, copy, and install the public keys associated with the client to the server with which it will communicate. And vice versa for each element of the OPC-UA infrastructure. This must be repeated for each client and server. 

A certificate has a lifespan and must be replaced by an updated certificate before its expiration.

Example of generating a self-signed certificate using a bash command with openSSL:

openssl genrsa -out default_pk.pem 2048
openssl req -new -key default_pk.pem -out cert.csr -subj "/C=US/ST=NY/L=NY/O=Organization/OU=OrganizationUnit/CN={YOUR_IP}"
openssl x509 -req -days 3650 -extfile extensions.cnf -in cert.csr -signkey default_pk.pem -out public.pem
openssl x509 -in public.pem -inform PEM -out public.der -outform DER

3. Certificates generated by a Certificate Authority (CA)

‍

‍

The main difference between a certificate signed by a Certificate Authority and a self-signed certificate is the effort required to deploy and maintain the certificates. 

In systems with multiple servers and clients, managing self-signed certificates can quickly become tedious. In such cases, using an enterprise-specific Certificate Authority can greatly simplify certificate management. 

The Certificate Authority can also provide additional benefits such as managing certificate expiration and Certificate Revocation Lists (CRLs).

You will need to generate a certificate signed by the Certificate Authority for all clients and servers installed in your system. When a certificate expires, you will only need to replace the expired certificate.

Example of CA generation using a bash command with openSSL:

openssl req -new -sha256 -nodes -newkey rsa:4096 -keyout CA.key -out CA.csr

openssl x509 -req -sha256 -extfile x509.ext -extensions ca -in CA.csr -signkey CA.key -days 1095 -out CA.pem

with for example x509.ext:

[ ca ]
# X509 extensions for a ca
keyUsage = critical, cRLSign, keyCertSign
basicConstraints = CA:TRUE, pathlen:0
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always

‍

Conclusion

‍

In recent years, the OPC-UA protocol has clearly distinguished itself in the race of industrial communication protocols, as it boasts compelling advantages:

• An open standard
• Platform agnostic
• As described in this post, security is built-in as standard, whether for authentication or during data exchanges
• Already natively implemented in many industrial PLCs
• Flexible and scalable thanks to its numerous implementations, whether in C/C++ but also in Java, .NET, NodeJS, or Python
• Its Publisher/subscriber concept, which enables event-driven communication

The module Connect of SCorp-io uses the OPC-UA protocol and incorporates all security features integrated into the standard protocol. Our next article will explain step-by-step how to secure an OPC-UA communication between a programmable logic controller (PLC) and the module using certificates. Connect.

‍