In some systems, a GlobalDiscoveryServerwith Certificate Management may be deployed. The GlobalDiscoverServerwill either push certificates to Clientsand Serversor allow Serversand Clientsto pull certificates. The GlobalDiscoveryServercertificate management can manage all certificate deployments; this includes TrustLists, CAs and CRLs.

From a developer point of view, it is a best practice, if your OPC UA Applicationsupports Certificates, that it automatically provides a self-signed ApplicationInstanceCertificateon installation. In addition, the OPC UA Applicationis able to easily replace the self-signed ApplicationInstanceCertificatewith a CA issued ApplicationInstanceCertificate or have the self-signed certificate signed by a CA. The configuration of a TrustListshould also be easily accomplished. Typically, TrustListsfor Public Keysof ApplicationInstances are kept in a separate list than those of a CA. Also, an OPC UA Applicationshould be able to handle Certificate Revocation Lists (CRL). These are lists of Public Keysthat are associated with a given CA that have been revoked. This allows a CA to remove a Certificatethat it had signed from circulation. CRLs are provided by a CA and usually distributed in some automatic manner; see OPC 10000-12for additional details.

From a security point of view, it is essential that the Certificatestores used to store Private Keysare 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 may 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 ApplicationInstanceCertificateis provided. This tool could be one provided by an OPC UA SDK vendor or by the OPC Foundation. The standard tool ensures that the ApplicationInstanceCertificatesthat are generated include all of the required fields and settings. A particular OPC UA Applicationshould be able to accept and install any valid ApplicationInstanceCertificatesgenerated by external tools. The choice of the actual tool is site specific. Figure 9 provides an overview of some of the key points of Certificate handling.


Figure 11– Certificate handling

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

ApplicationInstance– An OPC UA Applicationinstalled on a single machine is called an ApplicationInstance. Each instance has its own ApplicationInstanceCertificatewhich it uses to identify itself when connecting to other OPC UA Applications(the Public Keyand Private Key). Each ApplicationInstance has a globally unique URI which identifies it. The OPC UA Applicationwill also check TrustListsand CRL’s to determine if access should be granted. The OPC UA Applicationwill communicate using a secure channel established using Asymmetric Cryptographywith other applications.

Administrator – The person or persons that administer the Certificatehandling associated with a UA system and manage the security settings for ApplicationInstances. This includes setting the contents of TrustListsand managing any activities performed by a CA.

Operator –An Operator is person who uses the ApplicationInstance. More than one Operator may exist for any given OPC UA Application. An Operator may 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 may be passed to a Server after the ApplicationInstanceCertificateis used to create a secure channel. 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 Authorityverifies that information placed in the ApplicationInstanceCertificateis correct and adds a Digital Signatureto the Certificatethat is used to verify that the information has not been changed. Each CA has its own Certificatewhich 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 Certificateis 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 Certificatesconforms to the X.509 specification and as a result these Certificatesare also called “X.509 Certificates”.

Self-Signed Certificate– A self-signed Certificateis a Certificatewhich has no Certificate Authority. These Certificatescan be created by anyone and can be used in situations where the administrators of UA Applications are able to verify the claims by reviewing the contents themselves. A system that uses only self-signed Certificateswould not have CA or CRL.

Private Key– A Private Keyis a secret number known only to the holder of a Certificate. This secret allows the holder to create Digital Signaturesand decrypt data. If this secret is revealed to unauthorized parties then the associated Certificatecan no longer be trusted or used. It is replaced or in the case of a CA generated Certificateit is revoked.

TrustList– When security is enabled, UA Applications reject connections from peers whose Certificatesare not in the trusted list or if the Certificateis issued by a CA that is not in the TrustList.

Certificate Store– A Certificate Store is a place where Certificatesand Private Keyscan 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 Certificatesstored 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 Keybut 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 Certificateswhich have been revoked by a CA and are not accepted by an ApplicationInstance.