The OPC UA Servicesdefine 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 Applicationsshall follow.

All OPC UA Applicationsrequire an Application Instance Certificatewhich 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 name of the Certificate Authoritythat issued the Certificate;
  • The issue and expiry date for the Certificate;
  • The public key issued to the application by the Certificate Authority(CA);
  • A digital signature created by the Certificate Authority(CA).

In addition, each Application Instance Certificatehas 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 assign a new Application Instance Certificateand private key to the application.

This Certificatemay be generated automatically when the application is installed. In this situation the private key assigned to the Certificateshall be used to create the Certificatesignature. Certificatescreated in this way are called self-signed Certificates.

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


Figure 19– Obtaining and installing an Application Instance Certificate

Figure 19above illustrates the interactions between the application, the Administratorand the Certificate Authority. The Applicationis as OPC UA Applicationinstalled on a single machine. The Administratoris the person responsible for managing the machine and the OPC UA Application. The Certificate Authorityis an entity that can issue digital Certificatesthat meet the requirements of the organization deploying the OPC UA Application.

If the Administratordecides that a self-signed Certificatemeets the security requirements for the organization, then the Administratormay skip Steps 3 through 5. Application vendors shall ensure that a Certificateis available after the installation process. Every OPC UA Applicationshall allow the Administratorsto replace Application Instance Certificateswith Certificatesthat meet their requirements.

When the Administratorrequests a new Certificatefrom a Certificate Authority, the Certificate Authoritymay require that the Administrator provide proof of authorization to request Certificatesfor the organization that will own the Certificate. The exact mechanism used to provide this proof depends on the Certificate Authority.

Vendors may choose to automate the process of acquiring Certificatesfrom an authority. If this is the case, the Administratorwould still go through the steps illustrated in Figure 19, however, the installation program for the application would do them automatically and only prompt the Administratorto provide information about the application instance being installed.

Applicationsshall never communicate with another application that they do not trust. An Applicationdecides if another application is trusted by checking whether the Application Instance Certificatefor the other application is trusted. A Certificateis only trusted if its chain can be validated.

Applications shall rely on lists of Certificatesprovided by the Administratorto determine trust. There are two separate lists: a list of trusted Certificatesand a list of issuer Certificates (i.e. CAs). The list of trusted Certificatesmay contain a Certificateissued to another Applicationor it may be a Certificatebelonging to a CA. The list of issuer Certificatescontains CA Certificatesneeded for chain validation that are not in the list of trusted Certificates.

When building a chain each Certificatein 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 Applicationwith 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 Certificatesin the chain. These Certificatesmay 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 Certificateis trusted if the Certificateor at least one of the Certificatesin the chain are in the list of trusted Certificatesfor the Applicationand the chain is valid.

Table 106specifies the steps used to validate a Certificatein the order that they shall be followed. These steps are repeated for each Certificatein 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 Servicethat was invoked. The Serviceaudit event in its message text shall include the audit EventIdof the AuditCertificateEventType(for more details, see 6.5). Processing halts if an error occurs, unless it is non-critical and it has been suppressed.

ApplicationInstanceCertificatesshall not be used in a Clientor Serveruntil they have been evaluated and marked as trusted. This can happen automatically by a PKI trust chain or in an offline manner where the Certificateis marked as trusted by an administrator after evaluation.

Table 106– Certificate validation steps




Certificate Structure

Bad_CertificateInvalid Bad_SecurityChecksFailed


The Certificatestructure is verified.

This error may not be suppressed.

If this check fails on the Serverside, the error Bad_SecurityChecksFailed shall be reported back to the Client.

Build Certificate Chain




The trust chain for the Certificateis created.

An error during the chain creation may not be suppressed.

If this check fails on the Serverside, the error Bad_SecurityChecksFailed shall be reported back to the Client.





A Certificatewith an invalid signature shall always be rejected.

A Certificatesignature is invalid if the Issuer Certificateis unknown. A self-signed Certificateis its own issuer.

If this check fails on the Serverside, the error Bad_SecurityChecksFailed shall be reported back to the Client.

Security Policy Check




A Certificatesignature shall comply with the CertificateSignatureAlgorithm, MinAsymmetricKeyLength and MaxAsymmetricKeyLength requirements for the used SecurityPolicydefined in OPC 10000-7.

If this check fails on the Serverside, the error Bad_SecurityChecksFailed shall be reported back to the Client.

This error may be suppressed.

Trust List Check




If the Application Instance Certificate is not trusted and none of the CA Certificatesin the chain is trusted, the result of the Certificatevalidation shall be Bad_CertificateUntrusted.

If this check fails on the Serverside, the error Bad_SecurityChecksFailed shall be reported back to the Client.

Validity Period




The current time shall be after the start of the validity period and before the end.

This error may be suppressed.

Host Name



The HostName in the URL used to connect to the Servershall be the same as one of the HostNames specified in the Certificate.

This check is skipped for CA Certificates.

This check is skipped for Serverside validation.

This error may be suppressed.




Application and Software Certificatescontain an application or product URI that shall match the URI specified in the ApplicationDescriptionprovided with the Certificate.

This check is skipped for CA Certificates.

This error may not be suppressed.

The gatewayServerUriis used to validate an Application Certificatewhen connecting to a Gateway Server (see 7.2).

Certificate Usage




Each Certificatehas 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 Certificateindicates that the usage is mandatory.

Find Revocation List

Bad_CertificateRevocationUnknown Bad_CertificateIssuerRevocationUnknown


Each CA Certificatemay 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 Administratordisables revocation checks for a CA Certificate.

This error may be suppressed.

Bad_SecurityChecksFailed should be reported back to the Client.

Revocation Check




The Certificatehas been revoked and may not be used.

This error may not be suppressed.

If this check fails on the Serverside, the error Bad_SecurityChecksFailed shall be reported back to the Client.

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


Figure 20– Determining if an Application Instance Certificate is trusted

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.

Once an OPC UA Clienthas established a SecureChannelwith a Serverit can create an OPC UA Session.

The steps involved in establishing a Sessionare shown in Figure 22.


Figure 22– Establishing a Session

Figure 22illustrates 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 Clientor Serverdoes not have online access to the CA, then they shall validate the Application Instance Certificatesusing 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 Serverwhich access rights the user has. The identity provider depends on the user identity token. It could be a Certificate Authority, an Authorization Serviceor a proprietary database of some sort.

The Clientand Servershall prove possession of their Application Instance Certificatesby signing the Certificateswith a nonce appended. The exact mechanism used to create the proof of possession signatures is described in 5.6.2. Similarly, the Clientshall 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 Clienthas established a Sessionwith a Serverit can change the user identity associated with the Sessionby calling the ActivateSessionservice.

The steps involved in impersonating a user are shown in Figure 23.


Figure 23– Impersonating a User

ApplicationInstanceCertificatesor UserIdentityTokensmay expire, get invalid or may be rejected on Clientor Serverside.

ApplicationInstanceCertificatesverification shall be executed every time the SecurityTokenis renewed for a SecureChannel. OPC UA Applicationsmay do additional verifications between SecurityTokenrenews e.g. if the trust list is updated from a GDS.

If the SecureChanneldoes not use ApplicationInstanceCertificates, the OPC UA Applicationshould execute ApplicationInstanceCertificatechecks for the Sessionat a rate used for SecureChannelrenewals.

The recovery mechanisms for ApplicationInstanceCertificatereplacement 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 UserIdentityTokensis still valid or if the authorization for a UserIdentityTokenswas changed.