Applications that use PullManagement (see 7.3) to setup their configuration need to know the location of the CertificateManager which they can use to request Certificates and download TrustLists. This location may be auto-discovered via mDNS by looking for Servers with the GDS capability (see Annex D) or by providing a URL via and out of band mechanism such as e-mail or a web page.
Once the location is known the Application can connect to the CertificateManager and establish a SecureChannel. The Application may choose to connect even if it has not been pre-configured to trust the CertificateManager, however, Applications should not provide any secret information to a CertificateManager that is not trusted.
After establishing a SecureChannel with the CertificateManager, the Application needs demonstrate that it has permission to request Certificates and TrustLists. This permission may be granted if the CertificateManager is pre-configured with CAs and/or Certificates used by Applications on the network (see OPC 10000-21).
Permissions can also be granted if the Application provides user credentials that give it ApplicationAdmin rights (see 7.2). If the CertificateManager is not pre-configured to be trusted by the Application then the Application shall not provide any secrets, such as passwords, to the CertificateManager. It may use UserIdentityTokens, such as X509IdentityTokens, that do not require a secret to be sent to a potentially malicious CertificateManager.
If an Application prompts the user to enter the credentials to use it shall not persist these credentials for use in the future.
A CertificateManager may accept a CertificateRequest from unknown Applications that provide anonymous credentials if there is a process for manual review by a CertificateManager administrator. The Certificate is not issued until the CertificateRequest is approved.
Once an Application has received its first Certificate then the Certificate can be used in lieu of user credentials when the Application needs to renew its Certificate or update its TrustList.
Servers that use PushManagement (see 7.4) to initialize their configuration shall have a default Certificate assigned before the PushManagement process can start.
In addition, Servers shall go into an application setup state (for example, see OPC 10000-21) that makes it possible for remote Clients to update the security configuration via the ServerConfiguration Object (see 7.10.3). When a Server is in the application setup state it shall limit the available functionality. The value of the ServerState Property shall be NoConfiguration.
It is good practice for a Client to always check the ServerState after creating a Session. If the ServerState is NoConfiguration then the Client should check the InApplicationSetup Property on the ServerConfiguration Object to confirm that the Server is in the application setup state.
In some cases, cached user credentials will no longer work because of Server has been reset. Clients can determine that the Server is in the Application Setup state by reconnecting using Anonymous user credentials and checking the ServerState Property.
Once a Server has been configured it automatically leaves the application setup state. This step is necessary to ensure that security is not compromised.
A possible workflow for implementing the Application Setup state is:
- A flag in the configuration file that defaults to ON;
- Always allow Clients to connect securely and assign the SecurityAdmin Role to Anonymous user if the TrustList is empty;
- Connect to the Server after toggling a physical switch on the device which enables access for a short period.
- Add Client ApplicationUri to SecurityAdmin Role, remove Anonymous from SecurityAdmin Role;
- Provide a new Certificate and TrustList;
- Set the configuration flag to OFF.
Subsequent updates to TrustLists or Certificates can be allowed if the Client has a trusted Certificate and has access to the SecurityAdmin Role. During the setup state the Client shall configure the SecurityAdmin Role. If the Client fails to do this Server shall stay in application setup state.
In some cases, the Application distributor or installer will know the CA used to sign the Certificate used by the CertificateManager and can add this CA to the Application’s TrustList during installation. If practical, this approach provides the best protection against accidental configuration by malicious Clients.
If the device is automatically discovered by the CertificateManager the CertificateManager needs some way to ensure that the device belongs on the network. The manufacturer can provide a unique ApplicationInstance Certificate during manufacture and provide the serial numbers to the device installer. The installer would then register the serial number or Certificate with the CertificateManager. When the CertificateManager discovers the device it would check that the Certificate is for one of the pre-authorized devices and continue with automatic onboarding of the device. OPC 10000-21 formally defines mechanisms for onboarding new devices when they are connected to the network.
If a Private Key is stored on a regular file system it shall be protected from unauthorized access. This is best done by setting operating system permissions on the private key file that deny read/write access to anyone who is not using an account authorized to run the Application.
In some cases, additional protection can be added by protecting the Private Key with a password. Saving Private Key passwords in files should be avoided. This mode may also work in conjunction with “smart cards” that use hardware to protect the Private Key.
In addition to the Private Key, Applications shall be protected from unauthorized updates to their TrustList. This can also be done by setting operating system permissions on the directory where the TrustList is stored that deny write access to anyone who is not using an account authorized to administer the Application.
Finally, Applications may depend on one or more configuration files and/or databases which tell them where their TrustList and Private Key can be found. The source of any security related configuration information shall be protected from unauthorized updates. The exact mechanism used to implement these protections depends on the source of the information.