Mittwoch, 17. Juli 2019

KEPServerEX 6.7 Changes: OPC UA Certificates

Posted by Jeff Bates

KEPServerEX version 6.7 was released on June 27 with new device connectivity for the Torque Tool driver, updates to the Configuration API, and new OPC UA security features. You can now watch the recording of the release webinar for more information. 

If you read my previous blog post, you'll know that security is a major focus for version 6.7. In this post, I'll provide more detail on another important update we've made: changes to OPC UA certificate management within KEPServerEX. As we did with the last post, we'll start with some basics, but let me just say up front that it is important to institute certificate management practices at your organization to improve security and avoid interruptions in communications and costly downtime. But again, let's start with the basics. 

What is a certificate, and why is it important?

Certificates are critical to secure, encrypted communications. In general, certificates are used to authenticate the identity of an entity and to deliver a public key that can be used for encryption. To give a concrete example, certificates are used in Transport Layer Security (TLS) communications, which is used to secure the HTTPS protocol (the basis of secure communication on the internet). At the outset of a TLS exchange (typically called a "TLS handshake"), the web server responds to a client's request with its certificate, and the client can then validate it. The client uses the public key contained in the certificate to open secure communications. That is a bit of a simplified view, but suffice it to say certificates are critical to many types of secure communications. 

How are certificates used in an OPC UA connection?

A basic OPC UA connection requires a mutual exchange of certificates, called Application Instance Certificates. In order to establish a connection, there needs to be mutual trust between client and server. This means the client has to trust the server's certificate, and the server needs to trust the client's certificate. 

Every OPC UA application has a certificate store. That store houses both the application's own Instance Certificate, as well as certificates that are trusted by that application. Putting a certificate in the "Trusted" directory is the mechanism for trusting a certificate. To make this a little more concrete, consider the OPC UA Configuration Manager in KEPServerEX. The "Trusted Clients" and "Trusted Servers" sections allow users to interact with the trusted directories within KEPServerEX, and the "Instance Certificates" tab houses Instance Certificates for both the KEPServerEX OPC UA Server and OPC UA Client Driver. 


While a basic OPC UA connection is made by simply putting the server's Instance Certificate in the client's trusted directory and putting the client's Instance Certificate in the server's trusted directory, it is important to note that Instance Certificates are self-signed. Self-signed certificates have a number of disadvantages from a security perspective. We therefore recommend that users utilize a certificate signed by a Certificate Authority (CA) to establish trust when establishing a OPC UA connection. This could either be an internal or public CA. 

What changes are included in KEPServerEX version 6.7?

Prior to version 6.7, the self-signed Instance Certificates included in KEPServerEX were valid for ten years. This made it more likely that users would utilize the self-signed Certificate in production environments, versus using a CA-signed certificate. Because we are committed to security and the Shared Responsibility Model, we want to do everything we can to encourage robust security practices, including using a CA-signed certificate instead of a self-signed certificate and renewing certificates regularly. 

With that in mind, the Instance Certificates delivered with KEPServerEX are now valid for three years. This is enough time for a proof-of-concept, so we anticipate and encourage users to use Instance Certificate-based connections in those deployments. When it comes to a production environment, we encourage users to utilize a CA-signed certificate and adhere to certificate best practices, which includes renewing certificates on a regular basis. 

If, for whatever reason, you do use KEPServerEX self-signed Certificates in a production environment (which we do not recommend), it is critical that you have a plan to update your certificate before it expires. Failing to do so will interrupt OPC UA communications. 

As with my last post, we hope that you can see how these changes with OPC UA certificates represent a continued commitment to the security of our customers' environments. We encourage you to learn more about all of the features included in the 6.7 release. 
Learn More About KEPServerEX 6.7