The OPC UA Services define a number of mechanisms to meet the security requirements outlined in OPC 10000-2. This clause describes a number of important security-related procedures that OPC UA Applications shall follow.

All OPC UA Applications require an Application Instance Certificate which shall contain the following information:

• The network name or address of the computer where the application runs;
• The name of the organization that administers or owns the application;
• The name of the application;
• The URI of the application instance;
• The validFrom and validTo date for the Certificate.

Application Instance Certificates issued by a Certificate Authority (CA) shall contain the following additional information:

• The name of the Certificate Authority that issued the Certificate;
• The public key issued to the application by the Certificate Authority;
• A digital signature created by the Certificate Authority.

NoteSelf-signed Certificates contain this information but in this case the information is set to itself.

In addition, each Application Instance Certificate has a private key which should be stored in a location that can only be accessed by the application. If this private key is compromised, the administrator shall force the creation of a new Application Instance Certificate and private key by the application.

This Certificate may be generated automatically when the application is installed. In this situation the private key assigned to the Certificate shall be used to create the Certificate signature. Certificates created in this way are called self-signed Certificates.

Manual management and replacement before expiry of self-signed Certificates may be appropriate for a few Clients connected to one Server. In complex communication scenarios a central management of Certificates based on a Certificate Authority is recommended. This includes initial roll-out and automatic updates by a CertificateManager defined in OPC 10000-12.

If the administrator responsible for the application decides that a self-signed Certificate does not meet the security requirements of the organization, then the administrator should install a Certificate issued by a Certification Authority. The steps involved in requesting an Application Instance Certificate from a Certificate Authority are shown in Figure 19.

Figure 19 – Obtaining and installing an Application Instance Certificate

Figure 19 above illustrates the interactions between the application, the Administrator and the Certificate Authority. The application is a OPC UA Application installed on a single machine. The Administrator is the person responsible for managing the machine and the OPC UA Application. The Certificate Authority is an entity that can issue digital Certificates that meet the requirements of the organization deploying the OPC UA Application.

OPC UA defines interfaces and workflows to register OPC UA Applications with a central discovery service and to execute the interaction necessary with a CertificateManager to issue the initial Certificate Authority signed Certificate, The CertificateManager interface includes features to get a TrustList and also Certificate updates from a central place. The Global Discovery Server (GDS) and CertificateManager functionality is defined in OPC 10000-12.

If the Administrator decides that a self-signed Certificate meets the security requirements for the organization, then the Administrator may skip Steps 3 through 5. Application vendors shall ensure that a Certificate is available after the installation process. Every OPC UA Application shall allow the Administrators to replace Application Instance Certificates with Certificates that meet their requirements.

When the Administrator requests a new Certificate from a Certificate Authority, the Certificate Authority may require that the Administrator provide proof of authorization to request Certificates for the organization that will own the Certificate. The exact mechanism used to provide this proof depends on the Certificate Authority.

Vendors should automate the process of acquiring Certificates from an authority using the CertificateManager defined in OPC 10000-12. If this is the case, the Administrator would still go through the steps illustrated in Figure 19, however, the installation program for the application would do them automatically and only prompt the Administrator to provide information about the application instance being installed.

Applications shall never communicate with another application that they do not trust. An Application decides if another application is trusted by checking whether the Application Instance Certificate for the other application is trusted. A Certificate is only trusted if its chain can be validated.

Applications shall rely on lists of Certificates provided by the Administrator to determine trust. There are two separate lists: a list of trusted Certificates and a list of issuer Certificates (i.e. CAs). The list of trusted Certificates may contain a Certificate issued to another Application or it may be a Certificate belonging to a CA. The list of issuer Certificates contains CA Certificates needed for chain validation that are not in the list of trusted Certificates.

When building a chain each Certificate in the chain shall be validated back to a CA with a self-signed Certificate (a.k.a. a root CA). If any validation error occurs then the trust check fails. Some validation errors are non-critical which means they can be suppressed by a user of an Application with the appropriate privileges. Suppressed validation errors are always reported via auditing (i.e. an appropriate Audit event is raised).

Determining trust requires access to all Certificates in the chain. These Certificates may be stored locally or they may be provided with the application Certificate. Processing fails with Bad_SecurityChecksFailed if an element in the chain cannot be found. A Certificate is trusted if the Certificate or at least one of the Certificates in the chain are in the list of trusted Certificates for the Application and the chain is valid.

Table 106 specifies the steps used to validate a Certificate in the order that they shall be followed. These steps are repeated for each Certificate in the chain. Each validation step has a unique error status and audit event type that shall be reported if the check fails. The audit event is in addition to any audit event that was generated for the particular Service that was invoked. The Service audit event in its message text shall include the audit EventId of the AuditCertificateEventType (for more details, see 6.5). Processing halts if an error occurs, unless it is non-critical and it has been suppressed.

ApplicationInstanceCertificates shall not be used in a Client or Server until they have been evaluated and marked as trusted. This can happen automatically by a PKI trust chain or in an offline manner where the Certificate is marked as trusted by an administrator after evaluation.

Table 106 – Certificate validation steps

Step	Error/AuditEvent	Description
Certificate Structure	Bad_CertificateInvalid Bad_SecurityChecksFailed AuditCertificateInvalidEventType	The Certificate structure is verified. This error may not be suppressed. If this check fails on the Server side, the error Bad_SecurityChecksFailed shall be reported back to the Client.
Build Certificate Chain	Bad_CertificateChainIncomplete Bad_SecurityChecksFailed AuditCertificateInvalidEventType	The trust chain for the Certificate is created. An error during the chain creation may not be suppressed. If this check fails on the Server side, the error Bad_SecurityChecksFailed shall be reported back to the Client.
Signature	Bad_CertificateInvalid Bad_SecurityChecksFailed AuditCertificateInvalidEventType	A Certificate with an invalid signature shall always be rejected. A Certificate signature is invalid if the Issuer Certificate is unknown. A self-signed Certificate is its own issuer. If this check fails on the Server side, the error Bad_SecurityChecksFailed shall be reported back to the Client.
Security Policy Check	Bad_CertificatePolicyCheckFailed Bad_SecurityChecksFailed AuditCertificateInvalidEventType	A Certificate signature shall comply with the CertificateSignatureAlgorithm, MinAsymmetricKeyLength and MaxAsymmetricKeyLength requirements for the used SecurityPolicy defined in OPC 10000-7. If this check fails on the Server side, the error Bad_SecurityChecksFailed shall be reported back to the Client. This error may be suppressed.
Trust List Check	Bad_CertificateUntrusted Bad_SecurityChecksFailed AuditCertificateUntrustedEventType	If the Application Instance Certificate is not trusted and none of the CA Certificates in the chain is trusted, the result of the Certificate validation shall be Bad_CertificateUntrusted. If this check fails on the Server side, the error Bad_SecurityChecksFailed shall be reported back to the Client.
Validity Period	Bad_CertificateTimeInvalid Bad_CertificateIssuerTimeInvalid AuditCertificateExpiredEventType	The current time shall be after the start of the validity period and before the end. This error may be suppressed.
Host Name	Bad_CertificateHostNameInvalid AuditCertificateDataMismatchEventType	The HostName in the URL used to connect to the Server shall be the same as one of the HostNames specified in the Certificate. This check is skipped for CA Certificates. This check is skipped for Server side validation. This error may be suppressed.
URI	Bad_CertificateUriInvalid AuditCertificateDataMismatchEventType	Application and Software Certificates contain an application or product URI that shall match the URI specified in the ApplicationDescription provided with the Certificate. This check is skipped for CA Certificates. This error may not be suppressed. The gatewayServerUri is used to validate an Application Certificate when connecting to a Gateway Server (see 7.2).
Certificate Usage	Bad_CertificateUseNotAllowed Bad_CertificateIssuerUseNotAllowed AuditCertificateMismatchEventType	Each Certificate has a set of uses for the Certificate (see OPC 10000-6). These uses shall match use requested for the Certificate (i.e. Application, Software or CA). This error may be suppressed unless the Certificate indicates that the usage is mandatory.
Find Revocation List	Bad_CertificateRevocationUnknown Bad_CertificateIssuerRevocationUnknown AuditCertificateRevokedEventType	Each CA Certificate may have a revocation list. This check fails if this list is not available (i.e. a network interruption prevents the application from accessing the list). No error is reported if the Administrator disables revocation checks for a CA Certificate. This error may be suppressed. Bad_SecurityChecksFailed should be reported back to the Client.
Revocation Check	Bad_CertificateRevoked Bad_CertificateIssuerRevoked AuditCertificateRevokedEventType	The Certificate has been revoked and may not be used. This error may not be suppressed. If this check fails on the Server side, the error Bad_SecurityChecksFailed shall be reported back to the Client.

Certificates are usually placed in a central location called a CertificateStore. Figure 20 illustrates the interactions between the Application, the Administrator and the CertificateStore. The CertificateStore could be on the local machine or in some central server. The exact mechanisms used to access the CertificateStore depend on the application and PKI environment set up by the Administrator.

Figure 20 – Determining if an Application Instance Certificate is trusted

All OPC UA Applications shall establish a SecureChannel before creating a Session. This SecureChannel requires that both applications have access to Certificates that can be used to encrypt and sign Messages exchange. The Application Instance Certificates installed by following the process described in 6.1.2 may be used for this purpose.

The steps involved in establishing a SecureChannel are shown in Figure 21.

Figure 21 – Establishing a SecureChannel

Figure 21 assumes Client and Server have online access to a CertificateA uthority (CA). If online access is not available and if the administrator has installed the CA public key on the local machine, then the Client and Server shall still validate the application Certificates using that key. The figure shows only one CA, however, there is no requirement that the Client and Server Certificates be issued by the same authority. A self-signed Application Instance Certificate does not need to be verified with a CA. Any Certificate shall be rejected if it is not in a TrustList provided by the administrator.

Both the Client and Server shall have a list of Certificates that they have been configured to trust (sometimes called the Certificate Trust List or CTL). These trusted Certificates may be Certificates for Certificate Authorities or they may be OPC UA Application Instance Certificates. OPC UA Applications shall be configured to reject connections with applications that do not have a trusted Certificate.

Certificates can be compromised, which means they should no longer be trusted. Administrators can revoke a Certificate by removing it from the TrustList for all applications or the CA can add the Certificate to the Certificate Revocation List (CRL) for the Issuer Certificate. Administrators may save a local copy of the CRL for each Issuer Certificate when online access is not available.

A Client does not need to call GetEndpoints each time it connects to the Server. This information should change rarely and the Client can cache it locally. If the Server rejects the OpenSecureChannel request the Client should call GetEndpoints and make sure the Server configuration has not changed.

There are two security risks which a Client shall be aware of when using the GetEndpoints Service. The first could come from a rogue Discovery Server that tries to direct the Client to a rogue Server. For this reason the Client shall verify that the ServerCertificate in the EndpointDescription is a trusted Certificate before it calls CreateSession.

The second security risk comes from a third party that alters the contents of the EndpointDescriptions as they are transferred over the network back to the Client. The Client protects itself against this by comparing the list of EndpointDescriptions returned from the GetEndpoints Service with list returned in the CreateSession response.

The exact mechanisms for using the SecurityToken to sign and encrypt Messages exchanged over the SecureChannel are described in OPC 10000-6. The process for renewing tokens is also described in detail in OPC 10000-6.

In many cases, the Certificates used to establish the SecureChannel will be the Application Instance Certificates. However, some Communication Stacks might not support Certificates that are specific to a single application. Instead, they expect all communication to be secured with a Certificate specific to a user or the entire machine. For this reason, OPC UA Applications will need to exchange their Application Instance Certificates when creating a Session.

Once an OPC UA Client has established a SecureChannel with a Server it can create an OPC UA Session.

The steps involved in establishing a Session are shown in Figure 22.

Figure 22 – Establishing a Session

Figure 22 illustrates the interactions between a Client, a Server, a Certificate Authority (CA) and an identity provider. The CA is responsible for issuing the Application Instance Certificates. If the Client or Server does not have online access to the CA, then they shall validate the Application Instance Certificates using the CA public key that the administrator shall install on the local machine.

The identity provider may be a central database that can verify that user token provided by the Client. This identity provider may also tell the Server which access rights the user has. The identity provider depends on the user identity token. It could be a Certificate Authority, an Authorization Service or a proprietary database of some sort.

The Client and Server shall prove possession of their Application Instance Certificates by signing the Certificates with a nonce appended. The exact mechanism used to create the proof of possession signatures is described in 5.6.2. Similarly, the Client shall prove possession by either providing a secret like a password in the user identity token or by creating a signature with the secret associated with a user identity token like x.509 v3.

Once an OPC UA Client has established a Session with a Server it can change the user identity associated with the Session by calling the ActivateSession service.

The steps involved in impersonating a user are shown in Figure 23. The access of the Server to the identity provider is Server-internal and it may be just an access to an internal user database.

Figure 23 – Impersonating a User

ApplicationInstanceCertificates or UserIdentityTokens may expire, get invalid or may be rejected on Client or Server side.

ApplicationInstanceCertificates verification shall be executed every time the SecurityToken is renewed for a SecureChannel. OPC UA Applications may do additional verifications between SecurityToken renews e.g. if the TrustList is updated from a GDS.

If the SecureChannel does not use ApplicationInstanceCertificates, the OPC UA Application should execute ApplicationInstanceCertificate checks for the Session at a rate used for SecureChannel renewals.

The recovery mechanisms for ApplicationInstanceCertificate replacement scenarios are described in 6.7.

OPC UA Application should have internal notification mechanisms to get informed about removal of user identities or should frequently check if the UserIdentityTokens is still valid or if the authorization for a UserIdentityTokens was changed.