Custom x509 certificates with OPC Publisher
More and more companies start adopting OPC UA in their OT environments and beyond. Microsoft is part of the OPC Foundation and offers open source components to kick-start the Industrial IoT journey. One of the most popular components is the OPC Publisher module for IoT Edge.
In this blog post I will demonstrate, how to secure the communication between OPC Publisher (v2.7.x and later) as a client and OPC UA servers with custom (CA issued) x509 certificates. This is useful because your OPC UA server and client only need to trust your Root certificate as opposed to trusting every single client or server separately by importing their self signed certificates into the trusted store.
First of all I would really encourage you to read this document on OPC UA security/discovery because it provides a great intro into the topic.
Let’s get started! I prepared a script to generate certificates which can be used with OPC Publisher and OPC UA servers in my GitHub repo. The original script was written by the IoT Edge Team to help get started with x509 certs in IoT Edge context. I adapted it to include OPC UA specifics.
After you performed the steps in the README you will end up having this certificate chain:
This document describes what attributes an OPC UA compliant application instance certificate should have. Let’s have a look at the generated certificate for the OPC Publisher (I used edge_opc_publisher for CN).
The DC field in the Subject represents the hostname of the gateway which hosts IoT Edge and is optional (as some of the other fields too) but I do want to demonstrate how OPC Publisher handles this particular field.
The picture above shows the subjectAltName with the applicationUri and the hostname as required by the spec. Here is how we can configure OPC Publisher in IoT Edge deployment manifest to use our certificate:
For OPC Publisher to pick our certificate we need to follow these rules:
- The names of the .der and .pfx files (generated by the script) MUST be identical. Those files go into pki/own/certs and pki/own/private folders respectively.
- DC value in certificate’s Subject (if you specify it, remember it is optional) needs to match the actual hostname of the gateway.
- Environment variable ApplicationCertificateSubjectName needs to match certificate’s Subject string. The value of the DC field (if you specified it in the Subject) in this environment variable should be localhost. OPC Publisher replaces it with the gateway hostname automatically at runtime. Otherwise you would need one deployment per OPC Publisher instance.
- Environment variable ApplicationName needs to have the same value as the CN field in certificate’s Subject.
- Root and Intermediate CA certificates in .der format need to go into the pki/trusted/certs folder.
Here is the output of the tree command (mapped into OPC Publisher container) to make it more clear:
Now OPC Publisher is ready to connect to your OPC UA server using the specified certificate. You will most probably discover that your OPC UA server rejects the connection. This is due to the fact that it does not trust the Root and the Intermediate certificates yet. So go ahead and copy them over to your OPC UA server. Unfortunately the folder where those certificates need to be placed may vary between different server implementations. Most will allow you to use a UI to do this.
After you successfully trusted the Root and Intermediate certs, your OPC UA server will accept connections from all clients presenting a certificate signed by one of them.
