How To: Handle certificates for the IDE and the PLC
The certificates for encryption in CODESYS Development System or for communication with the PLC can be self-signed or CA-signed. The certification level which is used depends on the security demands. You can create certificates with special tools or in the CODESYS environment.
CA-signed certificates
CA-signed certificates must be created by a trusted external Certification Authority (CA) or by a CA located at the operator's facility. To obtain a CA-signed certificate, you can send a self-generated certificate to a CA via a Certificate Signing Request (CSR) and then reinstall it on your computer or on the PLC.
Extensions for CAs
The CA uses the data from the Certificate Signing Request (CSR) to create the X.509 certificate for the PLC. When signing the CSR, the transfer of the following x509v3 extensions from the CSR is required:
Key Usage, Extended Key Usage, Subject Alternative Name, each with the Critical flag
Self-signed certificates
You can create self-signed certificates yourself with your own private key. They are not signed by a CA. When you create self-signed certificates in the CODESYS environment, you get help from dialogs and encryption wizards.
Tip
A self-signed certificate is useful for testing purposes. It can also serve as a temporary solution until a certificate signed by a CA is available.
Storing certificates in the Windows Certificate Store
Certificate management on the local Windows computer
Valid certificates for the encryption of a CODESYS project and for the exchange between the PLC and CODESYS Development System must be stored in the local Windows Certificate Store (certmgr) on your computer.
Tip
To install a certificate file from the local file system in the Windows Certificate Store, double-click the file in the file directory. Then the appropriate import wizard will help you.
For more information, see the following: Certificates of the PLC
The Security Screen provides an interface for certificate handling for the project as well as for the certificates required for communication with the PLC. In the case of communication between CODESYS and the PLC, the Security Screen provides an alternative to the corresponding commands in the PLC Shell of the device editor.
Certificate management on the PLC is the responsibility of the system operator.
What can be encrypted or signed with certificates
In the CODESYS Package Designer add-on | |
Via the Project Settings dialog | |
Using the functions of the | |
When saving as a compiled library file | |
Application code, boot application, download source code, online change | Immediate support for creating a certificate is provided in this case by an encryption wizard in the Properties dialog of the application. |
Immediate support for creating a certificate for encrypted communication with the controller is provided when you first connect to a protected controller. This certificate is initially only valid temporarily. | |
You will get instructions for setting up certificate-encrypted communication starting with version V1.35.0.0 of CODESYS Automation Server support in the Quick Setup dialog. | |
In the Security Screen, on the Devices tab, or via the For a certificate to be considered secure by the browser, it must be signed by a trusted Certificate Authority (CA). | |
Immediate support at first startup if the runtime system requires encrypted communication. | |
In the Security Screen When signing the CSR, the transfer of the following x509v3 extensions from the CSR is required:
Each with the | |
In the Visualization Element Repository dialog |
Certificates of the PLC
Confidentiality
When handling PLC certificates, the role of the user must be differentiated. The system operator needs to make sure that only a user in the role of system administrator can configure and renew certificates in the PLC certificate store. Only a system administrator may also modify the certificate revocation list on the PLC.
Only the system administrator is allowed to create, renew, or change certificates in the certificate revocation list. Access to the PLC certificate store is critical to security.
Storing PLC certificates in the Windows Certificate Store
The configuration of the PLC certificate store defines the use cases for which the PLC expects valid certificates. The certificates required for this must be installed on your computer in the local Windows Certificate Store.
CODESYS makes it easier to create and manage the necessary PLC certificates using encryption wizards and the Security Screenview, Devices tab. Alternatively, you could also use the PLC Shell commands of the device editor. At both locations, you can view the certificate store of the currently connected PLC and create certificates. Both locations also provide an overview of all "use cases" on the PLC for which a certificate is required. They show whether a certificate already exists. Examples of use cases: Encrypted communication, OPC UA Server.
In each use case, CODESYS first checks whether the required certificates are available as trusted certificates in the local Windows Certificate Store.
Self-signed certificates
If a valid certificate has not yet been installed locally on the PLC for an application, then you can generate a self-signed certificate on the Security Screen or via the PLC Shell on the controller so that you can continue working with it immediately. The self-signed certificate will first be created in the My Certificates category. Then you can move it to the Trusted Certificates category so that the PLC will trust it in the future. For example, certificates are classified as untrusted due to a blacklist, or they are in quarantine for explicit verification because the PLC itself was unable to immediately check them. After the check is completed, you can move certificates to the Trusted Certificates category. You can also delete certificates from the PLC.
For more information, see the following: Generating Self-Signed Certificates
CA certificates
To achieve a higher level of security, you should replace a self-signed certificate with a CA-signed certificate. If you do not yet have a CA-signed certificate, then you can request one from a CA office (Certificate Signing Request, CSR). To do this, export the relevant PLC certificate file from the Security Screen or via the PLC Shell to the local file system. After the signed CA certificate has been returned, import it back into the PLC certificate store and the local Windows Certificate Store.
Direct creation of a CSR is possible via the PLC Shell and in CODESYS Security Agent V1.4.0.0 and higher also from the Security Screen (Devices tab).
Note that the CA-signed certificate has applied the following entries from the CSR: Key Usage, Extended Key Usage, Subject Alternative Name, each with the Critical flag.
For more information, see the following:
Automatically scanning certificates
Multiple certificates for the same use case
If multiple certificates are available on the PLC for one use case, then the system uses the following ordered steps to determine which certificate to use:
Using the certificate which was created directly by the user. (Not currently taken into account!)
Filtering of existing certificates by:
Subject (user of the certificate)
Key usage
Extended key usage
Valid timestamp
Dividing of detected, valid certificates as "signed" and "self-signed"
Filtering of signed certificates, and then the self-signed certificates by the following criteria:
Longest validity period
Strongest key
Renewal of certificates
The system operator needs to make sure that a certificate is renewed in time. For more information, see the following: Renewing a Certificate
Certificate revocation list
The certificate revocation list can currently only be changed via the PLC Shell. Only the system administrator of the system operator should be able to change this revocation list.
Tip
For a reference of the functions of the Security Screen, see the following: Security Screen
For a reference of the PLC shell functions, see the following: PLC Shell
Certificate chains
One or more intermediate CA certificates exist between the root CA and the final certificate of the OPC UA Server or Client. This certificate middle layer can be easily revoked and replaced if necessary, without having to change the root CA.
The support of certificate chains is an important measure to increase user-friendliness and simplify the configuration.
In addition to the actual X.509 certificate used, certificate chains also contain the respective intermediate and root CA certificates. These additional certificates are required in order to validate the entire chain back to the trusted root CAs. An X.509 certificate is a unique digital certificate which identifies a specific entity (for example, a user, device, or software).
In addition to the actual X.509 certificate used, certificate chains also contain the respective intermediate and root CA certificates. These additional certificates are required in order to validate the entire chain back to the trusted root CAs. An X.509 certificate is a unique digital certificate which identifies a specific entity (for example, a user, device, or software).
The CA intermediate certificates do not need to be transferred to the PLC. This results in less work in the configuration.
It is sufficient that trusted root certificates (from a root CA) are configured on the PLC.
If a chain changes, for example because an intermediate certificate has expired, then it is not necessary to reconfigure the intermediate certificate on the validating PLC.