All OPC UA Applicationsshall establish a SecureChannelbefore creating a Session. This SecureChannelrequires that both applications have access to Certificatesthat can be used to encrypt and sign Messagesexchange. The Application Instance Certificatesinstalled by following the process described in 6.1.2may be used for this purpose.

The steps involved in establishing a SecureChannelare shown in Figure 21.


Figure 21– Establishing a SecureChannel

Figure 21assumes Clientand Serverhave online access to a CertificateAuthority (CA). If online access is not available and if the administrator has installed the CA public key on the local machine, then the Clientand Servershall still validate the application Certificatesusing that key. The figure shows only one CA, however, there is no requirement that the Clientand Server Certificatesbe issued by the same authority. A self-signed Application Instance Certificatedoes not need to be verified with a CA. Any Certificateshall be rejected if it is not in a trust list provided by the administrator.

Both the Clientand Servershall have a list of Certificatesthat they have been configured to trust (sometimes called the CertificateTrust List or CTL). These trusted Certificatesmay be Certificatesfor Certificate Authoritiesor they may be OPC UA Application Instance Certificates. OPC UA Applicationsshall be configured to reject connections with applications that do not have a trusted Certificate.

Certificatescan be compromised, which means they should no longer be trusted. Administrators can revoke a Certificateby removing it from the trust list for all applications or the CA can add the Certificateto the CertificateRevocation List (CRL) for the Issuer Certificate. Administrators may save a local copy of the CRL for each Issuer Certificatewhen online access is not available.

A Clientdoes not need to call GetEndpointseach time it connects to the Server. This information should change rarely and the Clientcan cache it locally. If the Serverrejects the OpenSecureChannelrequest the Clientshould call GetEndpointsand make sure the Serverconfiguration has not changed.

There are two security risks which a Clientshall be aware of when using the GetEndpoints Service. The first could come from a rogue Discovery Serverthat tries to direct the Clientto a rogue Server. For this reason the Clientshall verify that the ServerCertificatein the EndpointDescriptionis a trusted Certificatebefore it calls CreateSession.

The second security risk comes from a third party that alters the contents of the EndpointDescriptionsas they are transferred over the network back to the Client. The Clientprotects itself against this by comparing the list of EndpointDescriptions returned from theGetEndpoints Servicewith list returned in the CreateSession response.

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

In many cases, the Certificatesused to establish the SecureChannelwill be the Application Instance Certificates. However, some Communication Stacks might not support Certificatesthat are specific to a single application. Instead, they expect all communication to be secured with a Certificatespecific to a user or the entire machine. For this reason, OPC UA Applicationswill need to exchange their Application Instance Certificateswhen creating a Session.