Hello, in this WAGO tutorial we show which requirements custom certificates must meet for OPC UA communication, and how to import your own security certificates into CODESYS 3.5. In general, this is the continuation of the previous tutorial on certificates generated by CODESYS, and again we are using two PFC200s – one as a server and one as a client. We are simply continuing the existing CODESYS programme; we have only deleted the certificates previously created by CODESYS and want to replace them with our own. Therefore, we will no longer go into the basic settings here – everything related to that can be found in the tutorial: “Creating OPC UA Security Certificates with CODESYS 3.5”. On the server, we let an integer variable count upwards and we want to send these values to the client via an encrypted OPC UA connection. At the moment, no connection is possible because we have not yet imported any certificates, although a security policy has already been configured in the device security settings. We could change the security policy directly here without going into the Web-Based Management; in fact, on some controllers such as the BC100 this is the only place where that can be done. In the security screen, neither the server nor the client has any OPC UA certificates available. There are several ways to purchase or generate certificates. Here, we demonstrate how to create custom certificates using the software tool XCA, because it allows us to clearly show which requirements a certificate must fulfil. Because there are no special requirements for the root CA in CODESYS, we have already created a new database and the root CA is ready. We export this from XCA and upload it to the server into the Trusted Certificates folder. This means the server now knows the root CA and will trust any client certificate signed by it. Next, we start creating the server certificate. We select the root CA and choose New Certificate. In the Source tab, our root CA is already set as the signing certificate. At the bottom we select the template TLS server and adopt all of its settings. In the Subject tab we assign, among other details, a common name. This is where many users stumble for the first time, because the name must follow this exact format: OPC UAServer @ followed by the hostname. You can find the hostname either in CODESYS under the communication settings or in the controller’s Web‑Based Management. Simply copy and paste it. Then we fill in the remaining details. At the bottom we generate the key for our certificate. In the Extensions tab we set the certificate’s validity, for example two years, and specify that it should expire at 00:00. The important part now is the Subject Alternative Name. CODESYS has specific requirements regarding this field. When we click Edit, we enter the controller’s IP address first. Then we need to consider how this IP address will be verified. In the previous tutorial we configured in the controller’s security settings that all active IP addresses should be considered. However, if we mark the IP entry as critical – which is strongly recommended from a security perspective – the certificate would be rejected because it is valid for exactly one IP address and not for all. We have several options to handle this: we could leave the critical checkbox unchecked, although that would introduce an unnecessary security gap or we specify the IP address used in the certificate directly in the controller’s security settings instead of “All”, or we add the localhost IP address (127.0.0.1) in the certificate as well. This last method is also used by the certificates generated by CODESYS. Next, we enter the DNS name, that is, the controller’s hostname. And then we must specify the URI. CODESYS has certain requirements for the URI, and here we have an example. At first glance the URI looks somewhat cryptic, but it is actually quite straightforward to construct. It begins with: URI:urn: followed by the host or device name, then the manufacturer, and finally the product name. You can find the exact product name in the Web‑Based Management under Information in the Device Status menu. When we copy and paste it here, it may still look different from the example. That is because it must be in HTML format. In HTML format, spaces are represented as %20, among other conversions. In our case we only need to replace the spaces with %20 to obtain the correct format. However, because other characters may also need to be encoded, it is better to convert the device description automatically. You can do this, for example, in Microsoft PowerShell using the command: System URI - Escape Data String Finally, we must specify that this is an OPC UA certificate and that it is the server certificate. A good alternative for obtaining the correct URI is to simply generate a certificate with CODESYS and copy the URI from there. Unfortunately, we cannot paste the URI into this window directly. Therefore, we confirm the entries so far with Apply and then add a comma after the hostname. Now we can easily paste the URI. When we reopen the Edit window, our URI has been inserted correctly. We tick the critical checkbox and confirm with Apply. In the Key Usage tab both critical checkboxes must be selected, and it is advisable to additionally select Non Repudiation under Key Usage. If we now switch to the Advanced tab, we can see a summary of our settings, and we have configured everything necessary. We confirm with OK. We create the client certificate in the same way, but this time using the Client template. Again, we assign an internal name similar to the server certificate, but the Common Name must follow this format. Everything else is as already described for the server certificate. The client URI is constructed a bit more easily: URI:urn: followed by the hostname, then a colon, and then runtime.datasource.CODESYS. Here is a summary of the required certificate entries. This example can also be found in the video description. With that, both required certificates are created and we can export them. For the export we choose the file format PFX as chain, so the certificate and key are stored together in one file. Back in CODESYS, we first log in to both controllers. On the client, this line must now appear: CmpOPCUAClient. If it is not yet displayed, the OPC UA communication must be started once so that the controller recognises that it is acting as a client. In the security screen, below the Refresh button, is the button for uploading certificates from the PC to the controllers. First we select the Own Certificates folder, then we upload the respective certificate. Depending on the CODESYS version, it may happen that even correctly created certificates are not recognised - so that the field in front remains empty. In that case you are likely using an older version of the CODESYS add‑ons CODESYS Communication and CODESYS Security Agent. You can check this via the CODESYS Installer: CODESYS Communication requires at least version 4.7.0.0, and CODESYS Security Agent requires at least version 1.4.0.0. Once both certificates have been uploaded and recognised, they appear in the quarantine folder of the opposite controller, and we simply drag and drop them into the Trusted Certificates folder. There is one common stumbling block left: the Certificate Revocation List or CRL. This is the list of revoked certificates. In the CODESYS default settings it is configured that this list must exist. There are two options: either you create a CRL (which can also be done with XCA) and import it, or – since in our case this list is empty – you disable the function on the server in the security settings. Our OPC UA communication is now working again, and the integer variable on the client is incrementing, this time encrypted using our self‑created certificates. This brings us to the end of the tutorial on the requirements for custom OPC UA certificates and how to import your own security certificates into CODESYS 3.5. Feel free to leave us a thumbs up if this video helped you, subscribe to the channel, and contact the WAGO Support Centre if you have any further questions.