From a developer point of view, it is a best practice for your OPC UA Application to automatically provide a self-signed ApplicationInstanceCertificate on installation. In addition, the OPC UA Application is able to easily replace the self-signed ApplicationInstanceCertificate with a CA issued ApplicationInstanceCertificate or have the self-signed certificate signed by a CA. The configuration of a TrustList should also be easily accomplished. Typically, TrustLists for Public Keys of ApplicationInstances are kept in a separate list than those of a CA. Also, an OPC UA Application has to be able to handle Certificate Revocation Lists (CRL). These are lists of Public Keys that are associated with a given CA that have been revoked. This allows a CA to remove a Certificate that it had signed from circulation. CRLs are provided by a CA and usually distributed in some automatic manner; see OPC 10000-12 for additional details. OPC 10000-12 also describes other ObjectTypes that can be used to expose this configuration and manage the all aspect of the security infrastructure.

Developers should also keep in mind that depending on the SecurityPolicies that an OPC UA Application supports, the Application could require multiple Certificates and TrustLists. This is required if both ECC and RSA endpoints are exposed.

From a security point of view, it is essential that the Certificate stores used to store Private Keys.are protected and secured only allowing read/write access by an appropriate administrator and /or by the OPC UA Application. TrustLists, CRLs, and trusted CA lists are secured allowing only write access by an appropriate administrator and in the case of pull configuration by the application. Read access can be granted to other valid users, but the list of users allowed read access would be a site decision.

From an Installation point of view, it is a best practice that a standard tool to generate an ApplicationInstanceCertificate is provided. This tool could be one provided by an OPC UA SDK vendor or by the OPC Foundation. The standard tool ensures that the ApplicationInstanceCertificates that are generated include all of the required fields and settings. A particular OPC UA Application should be able to accept and install any valid ApplicationInstanceCertificates generated by external tools. The choice of the actual tool is site specific. Figure 13 provides an overview of some of the key points of Certificate handling.

Figure 13 – Certificate handling

The following is a summary of these key points when a CA based security system is deployed:

• ApplicationInstance – An OPC UA Application installed on a single machine is called an ApplicationInstance. Each instance has its own ApplicationInstanceCertificate which it uses to identify itself when connecting to other OPC UA Applications (the Public Key and Private Key). Each ApplicationInstance has a globally unique URI which identifies it. The OPC UA Application will also check TrustLists and CRL’s to determine if access should be granted. The OPC UA Application will communicate using a SecureChannel established using Asymmetric Cryptography with other applications.
• Administrator – The person or persons that administer the Certificate handling associated with a UA system and manage the security settings for ApplicationInstances. This includes setting the contents of TrustLists and managing any activities performed by a CA.
• Operator – An Operator is person who uses the ApplicationInstance. More than one Operator can exist for any given OPC UA Application. An Operator can have User Credentials which are used to determine access rights and to track activities within the ApplicationInstance.
• User Credential – A User Credential is a generic term for an electronic ID which identifies an Operator/User. It can be passed to a Server after the ApplicationInstanceCertificate is used to create a SecureChannel. It can be used to determine access rights and to track activities (auditing).
• Certificate Authority (CA) – A Certificate Authority (CA) is an administrator or organization which is responsible for creating and managing Certificates (it is usually a partially automated software product). The Certificate Authority verifies that information placed in the ApplicationInstanceCertificate is correct and adds a Digital Signature to the Certificate that is used to verify that the information has not been changed. Each CA has its own Certificate which is used to create the Digital Signatures. A CA is also responsible for maintaining CRLs. In most cases it is a software package that an administrator periodically reviews or accesses, usually when the software package generates an alarm or notification that some review action is required.
• Certificate – A Certificate is an electronic ID that can be held by an OPC UA Application. The ID includes information that identifies the holder, the issuer, and a unique key that is used to verify Digital Signatures created with the associated Private Key. The syntax of these Certificates conforms to the X.509 specification and as a result these Certificates are also called “X.509 Certificates”.
• Self-Signed Certificate – A self-signed Certificate is a Certificate which has no Certificate Authority. These Certificates can be created by anyone and can be used in situations where the administrators of OPC UA Applications are able to verify the claims by reviewing the contents themselves. A system that uses only self-signed Certificates would not have CA or CRL.
• Private Key – A Private Key is a secret number known only to the holder of a Certificate. This secret allows the holder to create Digital Signatures and decrypt data. If this secret is revealed to unauthorized parties then the associated Certificate can no longer be trusted or used. It is replaced or in the case of a CA generated Certificate it is revoked.
• TrustList – When security is enabled, OPC UA Applications reject connections from peers whose Certificates are not in the trusted list or if the Certificate is issued by a CA that is not in the TrustList.
• Certificate Store – A Certificate Store is a place where Certificates and Private Keys can be stored on a file system. All Windows systems provide a registry based store called the Windows Certificate Store. All UA systems can also support a directory containing the Certificates stored in a file which is also called an OpenSSL Certificate Store. In all cases the Certificate Store needs to be secured, in that only administrators are allowed to write new entries. The security should follow the 'least privileged' principle, in that read or write access is only allowed to those who really need the data. This means that an administrator for example can store a Private Key but is not allowed to read them, and conversely an UA application can read such Private Keys, but cannot write them.
• Revocation List – A Revocation List is a list of Certificates which have been revoked by a CA and are not accepted by an ApplicationInstance.