Example: Secured OPC UA Communication 

On the 'Security' page of the 'OPC UA' PLANT tree node, you can specify settings regarding certificates and authentication which must be performed successfully in order to establish a secure connection between OPC UA clients and the OPC UA server. Furthermore, you can define which encryption algorithms the OPC UA server will provide to its clients to secure transmitted data.

After modifying these settings and writing them to the controller (as part of the PLCnext Engineer project), the controller (i.e., OPC UA server) generates the self-signed certificate (if needed) when switching its state from Stop to Run and applies it.

 

Certificate Configures the certificate management on the OPC UA server.
  • 'File on controller': a certificate file (including a private key) is stored in the IdentityStore on the controller device. This can be a CA-signed or a self-signed certificate (see term definitions at the end of this topic). The location on the controller is fixed and cannot be modified.

    The transfer of the certificate into the controller's IdentityStore can be done via the Web Based Management (WBM) interface of the controller or using the tool SCP Secure Copy (the transfer is not possible using PLCnext Engineer).

    Refer to the controller manual of your PLCnext Technology device for details. Refer to the table row 'TrustStores' below for an explanation of the term "IdentityStore".

  • 'Self-signed by controller': the server generates and uses the self-signed certificate, generated by the server and signed with its own private key. Using the self-signed certificate causes greater efforts when establishing a network with many application instances because the certificate must be distributed manually to the involved instances.

    After selecting 'Self-signed by controller', the 'Subject' options become visible with which you specify subject(s) of the certificate. Modifying these subject settings result in a newly generated self-signed certificate after the next project download. Refer to the table row "Type of subject" below for details.

  • 'Provided by OPC UA GDS': The OPC UA server embedded in the PLCnext Technology device is ready to be automatically provided with certificates according to the Certificate Push Management defined by the OPC UA standard (V 1.04, Part 12). This includes the initial certificates as well as all follow-up certificates (updates).

    The certificates are expected to be automatically provided by a Global Discovery Server (GDS) which implements the push mechanism. The Global Discovery Server is expected to connect to the OPC UA server in the PLCnext Technology device as a "special" OPC UA client.

    The Global Discovery Server is not part of PLCnext Engineer. Any suitable tool customary on the market can be used. It must be configured accordingly, in order to supply the OPC UA server on the PLCnext Technology device as well as all OPC UA clients (i.e., all relevant devices within your network/security domain) with certificates. Note that the Global Discovery Server can also be located in a different security domain (subnetwork).

    After having selected 'Provided by OPC UA GDS', you have to define the names for the TrustStore and the IdentityStore of the OPC UA server. The names are freely definable. You can see and inspect the content of these stores at the Web Based Management (WBM) of the controller. The OPC UA server uses them to store data there which it received from the Global Discovery Server (GDS). Into the named IdentityStore it stores the certificate and key which it is instructed by the GDS to authenticate itself against clients. Into the TrustStore it stores trusted and issuer certificates as it receives them from the GDS to verify client certificates with.

    After selecting 'Provided by OPC UA GDS', the 'Subject' options become also visible with which you specify subject(s) of the certificate. Depending on the Global Discovery Server involved, these subject settings can be integrated in the certificates that will be delivered to the OPC UA server. Refer to the table row "Type of subject" below for details.
Trust Stores These fields are only visible if 'Server certificate' is set to 'Provided by OPC UA GDS' (see row above).
You have to define the names of the TrustStore and the Identity Store which the OPC UA server shall use to store data it receives from the Global Discovery Server (GDS). Enter the freely definable names into the text fields. You can inspect the current content of these stores via the Web Based Management (WBM) interface of the PLCnext Technology device.
  • 'Identity Store name': Defines the name of the IdentityStore of the OPC UA server on the PLCnext Technology device where the OPC UA server shall store its own application instance certificate and key as it is instructed to use by the Global Discovery Server. With the information stored in the IdentityStore, the OPC UA server authenticates itself against clients.

    Background information: IdentityStoreBackground information: IdentityStore

    An Identity Store is a special persistent memory area (identified by the IdentityStore name) which contains (partially strictly confidential) data, a PLCnext Technology device can use to authenticate itself to communication partners. The OPC UA server obtains this data from the Global Discovery Server.

    This data includes an asymmetric key pair (a public and a private key). The key pair is accompanied by a corresponding public key certificate (acc. to the X.509 standard) and optionally issuer certificates up to a Trusted Anchor.

    For authentication, the PLCnext Technology device uses its asymmetric key pair. The communication partner either considers the public key as trustable because it knows its identity, or the PLCnext Technology device transmits additionally its certificate (which states its identity) and the communication partner verifies this certificate, too. In a hierarchical certification structure, the PLCnext Technology device also sends the issuer certificates stored in its IdentityStore in order to enable the communication partner to validate the entire certification path.

    A PLCnext Technology device may contain several IdentityStores. This way, it can take on different identities (for example, if it is included in several security domains) or different services running on the same device can be distinguished each by its own identity (for example an OPC UA server and a web server). The OPC UA server embedded in the PLCnext Technology device currently supports one IdentityStore at a time.

    The counter part of an IdentityStore in the PLCnext Technology device is the TrustStore (see next item).

  • 'TrustStore name': Defines the name of the TrustStore of the OPC UA server on the PLCnext Technology device into which the OPC UA server stores the data it receives from a Global Discovery Server (GDS) to authenticate clients with. Using the information in the TrustStore, the OPC UA server can verify the identity of connecting OPC UA clients by validating the authenticity of the certificates they present.

    Background information: TrustStoreBackground information: TrustStore

    A TrustStore is a special persistent memory area (identified by the TrustStore name) which contains criteria for verifying the certificates with which the communication partners of a PLCnext Technology device authenticate theirselves. In other words: the content of the TrustStore enables the verification of the authenticity of a certificate presented by a potential communication partner. Regarding the OPC UA server, these are OPC UA clients. The OPC UA server obtains this data from the Global Discovery Server.

    These verification criteria are mainly trusted certificates. Furthermore, issuer certificates (created by Sub-CAs) can be deposited there which can be used for the verification of an entire hierarchical certification structure. Optionally, also certificate revocation information can be stored here or verification rules for hierarchical certification structures or certificate content (such as "check validity periods?", "check revocation?", "check subject name?").

    NOTE: As long as the TrustStore is empty, the OPC UA server trusts all clients.

    A PLCnext Technology device may contain several TrustStores. The OPC UA server embedded in the PLCnext Technology device currently supports one TrustStore.

    The counterpart of a TrustStore in the PLCnext Technology device is the IdentityStore (see above).

For both the TrustStore and the IdentityStore, the following applies:
  • The contained data are stored in the PLCnext Technology file system and can optionally be protected by hardware measures. By default, manufacturer-defined TrustStores and IdentityStores can be implemented.
    Examples: a default TrustStore which contains data for validating the authenticity of the Proficloud server when establishing a connection to the Proficloud, or an IdentityStore for the authentication at the HTTPS server or the Remoting server of the device.
  • TrustStores and IdentityStores on the PLCnext Technology device can be explored via the Web Based Management (WBM) interface.
  • In the current implementation, three TrustStores and three IdentityStores are ready for use by the OPC UA server. The OPC UA server currently supports one TrustStore and one IdentityStore at a time. Which one is used depends on the OPC UA server configuration.

    IdentityStores:

    1. One IdentityStore with fixed name for the self-signed certificate. This store is used when selecting the configuration option 'Self-signed by controller'.
    2. One IdentityStore with fixed name for the certificate file. This store is used when selecting the configuration option 'File on controller'.
    3. One IdentityStore with a name defined via PLCnext Engineer for the certificate pushed by the GDS. This store is used when selecting the configuration option 'Provided by OPC UA GDS'.

    TrustStores:

    1. One TrustStore with fixed name for use with the certificate file. This store is used when selecting the configuration option 'File on controller' or 'Self-signed by controller'.
    2. One TrustStore with a name defined via PLCnext Engineer for information pushed by the GDS. This store is used when selecting the configuration option 'Provided by OPC UA GDS'.

      In this case, the following applies: if not yet defined (e.g., by WBM), you can simply create a new TrustStore or IdentityStore by typing any name into the inputs fields. This way, a corresponding store with this name will be created on the device when the OPC UA server executes the project. Once created, the store will still be empty but listed in the WBM.

    Note: As long as the TrustStore is empty, the OPC UA server trusts all clients.
  • The content of both the TrustStore and the IdentityStore can be modified via the WBM interface. This way, you can manually "prefill" the TrustStore in order to enable the OPC UA server to trust the Global Discovery Server which will provide the OPC UA server with further certificates. You can furthermore prefill the IdentityStore with a server certificate in order to enable the server to authenticate itself as trusted member of your security domain, for example, at the Global Discovery Server.
  • Configure the Global Discovery Server involved accordingly to trust the OPC UA server (in order to establish a connection between OPC UA server and GDS). Then set up the GDS in a way that it cyclically writes the required security data into the TrustStore and the IdentityStore of the OPC UA server.
Note: The OPC UA standard uses different terms. The standard mentions a TrustList the content of which is very similar to the content of a TrustStore of the PLCnext Technology device. The standard specifies a CertificateGroup which is very similar to the information within an IdentityStore of the PLCnext Technology device.
Type of subject These fields are only visible if 'Server certificate' is set to 'Self-signed by controller' or 'Provided by OPC UA GDS'.
Note: In case of 'Provided by OPC UA GDS' it depends on the implementation of the Global Discovery Server involved whether the subject settings made here are considered or not.

A subject specifies the owner of a certificate. A subject can be accompanied by alternative names. Within certificates according to the X.509 standard these alternative names are recorded within a so-called "subjAltName"-Extension within the certificate.

Using these input fields, you can specify alternative names the OPC UA server shall include in the self-signed certificate it generates or in the certificate signing request it generates for a Global Discovery Server.
You can specify up to five alternative names for the subject. Each alternative name shall describe a DNS name or IP address the OPC UA server is reachable at. The OPC UA server automatically also includes the DNS name specified in the basic settings as an alternative name regardless of the settings here.
This way, you can enable up to four communication paths (provided that this is supported by your network architecture, for example, using a router, existing port forwarding (firewall in router to OPC UA server) and implemented local DynDNS).
When establishing the connection, OPC UA clients verify whether the address (DNS name or IP address) from the URL they wanted to connect to is contained in the server certificate.
If several possibilities exist for connecting the OPC UA server from outside or inside the domain, each possible address part of a URL must be contained in the certificate. Otherwise, the authentication fails.
Any specified DNS name or IP address (depending on the selection in 'Type of subject') is written into the self-signed certificate. If 'not set' is selected in a subject field, it is ignored by the server when generating the certificate. When specifying 'not set' for all subjects, no alternative name will be included in the self-signed certificate except for the DNS name from the Basic Settings which is always included.
Note: If clients use short URLs (because they are located in the same domain as the OPC UA server), list these short names here as alternative names.
Security Policies Defines the encryption algorithm(s) (Cipher Suite), the OPC UA server offers to its clients. The encryption algorithm is applied to and secures the data transfer between OPC UA server and client.
Select 'Yes' in the relating drop-down list to make the respective algorithm available for clients. If set to 'No', the encryption algorithm cannot be selected in the OPC UA client settings.
From top to bottom, the encryption and signature strength increases:
  • 'Enable Basic 128 RSA15 algorithm'
    This Basic 128 RSA15 algorithm is deprecated and is therefore set to 'No' by default. Only use this setting if the OPC UA client does not support a higher encryption.
  • 'Enable Basic 256 algorithm'
    This Basic 256 algorithm is deprecated and is therefore set to 'No' by default. Only use this setting if the OPC UA client does not support a higher encryption.
  • 'Enable Basic 256 SHA256 algorithm'

 

 

 

• Published/reviewed: 2024-12-16 • Revision 016 •