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 Trust Lists. 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 secure channel. This will require that the Application trust the Certificate provided by the CertificateManager even if it is not in the Application’s TrustList. If there is an interactive user the Application should warn the user before proceeding. If there is no interactive user the Application should ensure the domain in the URL matches one of the domains in the Certificate.

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 registration with rogue CertificateManagers.

After establishing a secure channel with the CertificateManager, the Application shall provide user credentials which allow it to register new applications and request new Certificates. The credentials may be provided by prompting a user or they may be one time use credentials delivered via some out of band mechanism such as a web site during the installation process.

For embedded systems it can be impractical to enter user credentials. As an alternative, a unique ApplicationInstance Certificate can be provided during manufacture and the Certificate or a unique identifier for the Certificate should be provided to the device installer. The installer would then register the unique identifier or Certificate with the CertificateManager which would allow the device to request a new Certificate by creating a Secure Channel with the manufacturer’s Certificate.

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

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 a “setup state” that makes it possible for remote Clients to update the security configuration via the ServerConfiguration Object (see 7.10.2). When a Server is in the “setup state” it should limit the available functionality.

Once a Server has been configured it automatically leaves the “setup state”. This step is necessary to ensure that security is not compromised.

A possible workflow for implementing the “setup state” is:

1. A flag in the configuration file that defaults to ON;
2. Always allow Clients to connect securely if the TrustList is empty;
3. Connect to the Server after toggling a physical switch on the device which enables access for a short period.

1. Provide a new Certificate and Trust List;
2. Set the configuration flag to OFF;

Subsequent updates to TrustLists or Certificates can be allowed if the Client has a trusted Certificate and valid administrator credentials.

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.

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 Trust List. 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 there 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.