Certificates 

What are certificates used for?

Certificates can be used for the following:

• Securing communication connections between participants in your ICS. Participants can be, for example:
  • Devices used to build automation infrastructures and systems (such as PLCnext Technology controllers, switches, etc.).
  • Server and client applications (such as HMI application, OPC UA etc.).
  • Engineering or configuration tools connecting to the devices to be configured (such as PLCnext Engineer etc.). During a logon to a device, the identity of both the engineering software instance used to logon and the device must be verified and they must match. This can be done by means of certificates.
    Example: When logging on to a PLCnext Technology controller from the software PLCnext Engineer, both parties must authenticate themselves using a certificate. A secured connection is only established, if the certificates are valid.

  Refer to the topic Secure Communication for details.

• Verifying the integrity and origin/authorship of data, such as a provided library, or the authenticity of software/firmware.
  When creating the data (for example, releasing the library), a signature certificate (file) as well as the relating issuer certificates and the corresponding private key (signature key) are required. The private key is used for generating the signature in the inventory of the data to be published. As a result, this inventory signature then contains the signature certificate including the relating issuer certificates and can be used to prove the integrity of the library and the authorship of the data releaser (library supplier in our example). 

What is a certificate?

A certificate is an electronic, digitally signed and forgery-proofed identity document (data structure).

A certificate...

• is specifically created and only valid for the particular owner.
  The owner of a certificate is referred to as subject. This could be, for example, a server or a client application instance.
  The creator of a certificate is referred to as issuer.
• describes the capabilities the subject has.
  For example, the certificate can only be used for authentication purposes, or a subject may become an issuer and act as CA.
• contains (quotes) the public key of the subject which exclusively belongs to the private key of the subject.
• is signed by the issuer with a signature. For creating the signature, the issuer has used its private key. The signature attests that the public key belongs to the subject.
  See the section "CA-signed certificates vs. self-signed certificates" below for details.
• does not contain the private key of the subject.

Authentication using certificates

• A subject (application) can authenticate its identity to other applications by means of its certificate in combination with its private key.
• The recipient of the certificate verifies the signature of the certificate (and thus the identity of its owner) with the public key of the issuer.
• The verification is done as challenge response authentication procedure. For example, the subject is asked to sign a random number with its private key. The signature is then verified with the public key.

Following the mutual verification of applications, a secure communication channel between the authenticated applications can be established.

Certificates do not contain encrypted content but plain text. Due to their signature, they do not need to be protected. Therefore, they can be distributed (to involved applications/administrators), for example, by email.

CA-signed certificates vs. self-signed certificates

A Certificate Authority (CA) is an administrator, organization or application that issues certificates, i.e, that creates certificates for other subjects and signs them using the private key of the CA. Subject (owner) and issuer (creator) in this certificate are not identical. The issuing CA writes the public key of the subject for which the certificate is going to be created into the certificate, instead of its own public key when "self-signing".

A self-signed certificate results, if an application creates its own certificate and signs it with its own private key. In a self-signed certificate, the subject (owner) and issuer (creator) are identical. For securing the communication between a small number of applications, the use of self-signed certificates may be practicable. Since there is no common trust basis in such a scenario, each application involved must be manually configured for each relevant self-signed certificate.
To secure the communication in large distributed networks with many applications, certificates issued by a Certificate Authority (CA) are recommended. This is because using the CA certificate(s) as a common trust anchor makes management much more scalable. Also hierarchical certification structures are possible with one or several issuers and sub-issuer levels.

Certificate Signing Request (CSR)

A Certificate Authority (CA) generates and signs a certificate only on request. This request is called Certificate Signing Request (CSR). With the CSR, the CA receives detailed information on the subject that requests the certificate (subject/owner attributes) as well as the subject's public key in order to include these data in the certificate.

Certification hierarchy, certification path, and trusted anchor

When a CA issues a certificate for a particular subject it has to define the future capabilities of the subject. Possibly, the certificate can only be used for authentication purposes, or (by granting further capabilities) a subject may become an issuer and is also able to issue certificates for other subjects. This way, a hierarchical certification structure can be created.

In a hierarchical certification structure, the CA is considered as root node. The CA certificate (root certificate) is called Trusted Anchor. In the next lower level, further issuers (sub-CAs) can follow, each of them with the right to issue certificates. Their own certificates are called issuer certificates. Further sublevels with subsub-CAs are possible. The certificates on application level (e.g., controller and PLCnext Engineer, or OPC UA server and clients) are called application certificates.

In a hierarchical certification structure, a certificate (for example the device certificate of a PLCnext Technology controller, or the application certificate of an OPC UA client) can only be verified by authenticating the entire certification path from the particular certificate up to the Trusted Anchor (root certificate).

Example: PLCnext Technology controller and PLCnext Engineer

For the communication between PLCnext Technology controller and PLCnext Engineer, this is done by

• installing the entire certification path in the PLCnext Technology controller starting with the controller certificate via all issuer certificates involved up to and including the Trusted Anchor (root certificate).
  and
• providing the certificate for validating the Trusted Anchor in PLCnext Engineer.
  Note: Installing only the Trusted Anchor avoids unnecessary subsequent installations in PLCnext Engineer when modifying the certification hierarchy of the device certificate (for example, by inserting or replacing any issuer certificate (generated by a sub-CA).

Certificate Revocation List (CRL)

A Certificate Revocation List (CRL) is a list which describes the invalidity of certificates. A CRL specifies certificates that must not be accepted by application instances or devices. A certificate can be revoked if the relating private key (which is the property of the certificate subject) has been compromised or if the certificate contains content that is no longer valid (e.g. an outdated application instance URI after migrating the application to another computer).

CRLs can be created by any issuers (CA or sub-CA) which are endowed with the rights for issuing CRLs ("Sign CRL"). To revoke a certificate, the CA adds the respective serial number of the certificate (and potentially more) to the CRL. To secure the CRL, it is also signed by the CA using the private key of the CA and it contains a time stamp. This way, applications can verify the authenticity, integrity and validity of a CRL before evaluating its content.

Because usually authentication only happens during connection establishment, an application instance only evaluates the CRL each time when authenticating a certificate.

Consequently, existing connections are not disconnected if a certificate, which was used during connection establishment is revoked later. Such connections must be disconnected manually, for example, after a private key has been compromised or stolen. The disconnection may also be done by restarting the affected devices or application instances.

Example illustration

A CA has issued certificates for a server and a client application on request. This represents a two-level certification hierarchy.

Mutual authentication: To authenticate their identities, each application verifies the certificate of the other application using the public key of the other application. Following the successful authentication, a secure communication channel can be established.

The CA has additionally issued a CRL. The application can use this CRL during authentication to ensure that a certificate that to be authenticated is not revoked. Communication is only established if the involved certificate is not listed in the CRL.

Secure certificate management

Trusted networks may have a large number of certificates in use. To maintain smooth and secure communication, each of these certificates must be checked for the following aspects.

• Are all certificates valid, i.e. compliant with the directive? If not, this certificate should be checked and revoked if necessary, for example, by listing it on a Certificate Revocation List (CRL).
• Has the expiration date been exceeded for a certificate? If yes, this certificate must be extended or replaced.
• Have certificates been revoked/blocked? See Certificate Revocation List (CRL) above.
• Are there legitimate certificate signing requests from participants in the network? If so, new certificates must be issued by the CA. See Certificate Signing Request (CSR)
• Does an endpoint (application/device) report a certificate error?

Expired, forgotten or invalid certificates in most cases lead to security problems, communication or even production downtime. Therefore, a secure certificate management is essential. As certificates contain public keys, such management is also referred to as Public Key Infrastructure (PKI).

If possible, use an automated certificate management system (or PKI) that covers the following tasks or contains the following components:

• Certificates search tool: The automatic search in the network should produce a clear log of all the certificates found. All details of each certificate should be listed, such as subject (owner) and expiration date etc.
• Adding (client) certificates to the trust list of the endpoints (devices or applications) involved. This should be able to be done automatically if possible, possibly with subsequent manual confirmation. If possible, running processes or services should be able to continue running.
• Ability to schedule: all tasks should be regular and at appropriate time intervals (e.g., several times per week).
• Define clear personnel responsibilities and unambiguous authorizations for certificate/PKI management.
• Administrators and users of the management system must be trained according to their roles.
• The certificate/PKI management system should have a notification function that informs about all events and necessary action steps. This includes detected (soon to be) expired certificates, certificate errors in endpoints, pending signing requests etc.
• Approve Certificate Signing Request (CSR) as soon as possible.
• Ensure that no outdated keys or other obsolete technologies are used when issuing certificates.
• Permit/enable the automatic extension of the validity period provided that the performed threat risk assessment allows it.
• Fix certificate errors on endpoints as soon as possible.
• Maintain a Certificate Revocation List (CRL) and evaluate it continuously.