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 organisation that administers or owns the application;
  • The name of the application;
  • The URI of the application instance;
  • The name of the Certificate Authority that 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 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 assign a new Application Instance Certificate and private key to 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.

If the administrator responsible for the application decides that a self-signed Certificate does not meet the security requirements of the organisation, 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

The figure above illustrates the interactions between the application, the Administrator and the Certificate Authority. The Application is as 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 organisation deploying the OPC UA Application.

If the Administrator decides that a self-signed Certificate meets the security requirements for the organisation, 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 organisation 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 Certificates from an authority. 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. Applications shall rely on lists of Certificates provided by the Administrator to determine trust. There are two separate lists: a list of trusted Applications and a list of trusted Certificate Authorities (CAs). If an application is not directly trusted (i.e. its Certificate is not in the list of trusted applications) then the application shall build a chain of Certificates back to a trusted CA.

When building a chain each Certificate in the chain shall be validated. 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).

Building a trust chain 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 a CA Certificate cannot be found.

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




Certificate Structure

Bad_CertificateInvalid Bad_SecurityChecksFailed


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




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.





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




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




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




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 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.




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.1).

Certificate Usage




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


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.

Revocation Check




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 a 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 above 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 trust list 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 trust list 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 security token 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 above 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, a Kerberos ticket granting service, a WS-Trust Server 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.


Figure 23 – Impersonating a User