Configuring Signing Service

The following section describes the Signing Service high level workflow on a Supervisor (or non- Supervisor station that is designated as a station to which signing requests may be submitted).
Prerequisites:
  • Niagara 4.13 and later module versions: signingService-rt, signingService-ux, and signingService-wb
  • The “certSigningService” Tridium feature is included in your license.
  • A valid CA certificate is a prerequisite for any signing operation with the Signing Service. You may choose to import an existing corporate CA certificate into the stations User Key Store (which requires both the public certificate and private key). This may be a self-signed corporate CA or an intermediate CA certificate signed by an external authority. Alternatively, you may use the Workbench Certificate Manager tool to generate a new CA. For more information about the Certificate Management tool, see “Platform Certificate Management (platCrypto-CertManagerService)” in the Niagara Platform Guide.
  • If you are using the FOX transport to onboard components on remote Niagara stations, each remote station intending to use the Signing Service must have an active Niagara Network connection to the Supervisor station that hosts the service.
Perform the following steps:
  1. Import the CA certificate into the Supervisor via the Platform’s Certificate Management view, or via the station at slot:/Services/PlatformServices/CertManagerService.
  2. Add a Signing Service and a child Signing Profile to the Services folder. If you use the Signing Service in the Typical Configuration folder of the palette, it will already come with two profiles.
    Image
  3. On the profile, select the alias of the imported CA, enter its unique password or global certificate password, and define any certificate parameters required.
    The fixed parameters allow certificate expiration and key purpose to be enforced. Other optional parameters in the palette allow enforcement of key size and key type, and certificate parameters such as the Distinguished Name fields.

    The Typical Configuration folder in the palette contains a good example on how to configure the Signing Service:

    • A clientProfile exists, which you can use for components that require a signing client SSL certificate for authentication purposes.
    • The Common Name Template parameter generates a dynamic Common Name (CN) value specific to the requesting component when the CSR is generated. You have several options to configure a CN value from multiple different sources, such as the station name, host name, or the value of a resolved user-defined format expression.
      Image
    • The DN Certificate Parameter allows you to further define the Distinguished Name values in a comma-separated list of pairs in the format: ‘key=value’. You may choose to delete the Common Name Template parameter and add a hard-coded CN value within the DN parameter.

    The Typical Configuration folder also includes a serverProfile example for components that may supply a server SSL certificate. A Common Name Template is provided, along with a subjectAlternativeName (SAN) extension parameter. A SAN extension is commonly used to list the domain names / IP addresses for the host in the context of a server application.

    Image

    You can edit this extension and add one to many different user-defined SAN values. In addition, your SAN parameters use one of the following Format token strings that will be substituted dynamically when the CSR is generated:

    %commonName% The value of the certificate’s Common Name as supplied by another parameter in the request.
    %hostnameOrIpAddress% The host name of the device on which the requesting component’s station is running, or the IP address if a non-localhost host name is not available. When falling back to the IP address, the SAN entry will be set to have an ‘IP Address’ Identity Type.
    %hostname% The host name of the device on which the requesting component’s station is running.
    0.0.0.0 The IP address of the host on which the requesting component’s station is running. The SAN entry must have the ‘IP Address’ Identity Type.
    %ipAddress% The IP address of the host on which the requesting component’s station is running. Works in conjunction with the ‘DNS Name’ Identity Type.

    Other certificate parameters and extension types are supported and available in the palette.

     NOTE: Certificate Parameters may be dropped onto the requesting component, such as the Individual Signing Cert Config and the Combined Signing Cert Config components, not just the Signing Profile. If the same parameter type is added to both, the requester and the profile, the profile parameter value is the one that is applied. The exception to this rule is that different SAN extension values supplied are to be merged.