Creating a root CA certificate

A company’s root CA certificate is a self-signed certificate. Companies that serve as their own CA use its private key to sign their intermediate, server, client and code-signing certificates. The root CA certificate resides in the Workbench Certificate Management User Key Store with both its public and private keys. You export it with only its public key so that you can import it into each platform/station’s User Trust Store.

1. Access the Workbench Certificate Management view by clicking Tools > Certificate Management.
   The Certificate Management view opens to the User Key Store.
   
   

   As of Niagara 4.13, the default tridium certificate was replaced by the default certificate, which has enhanced features and cannot be deleted. The installation of a new Niagara version will not by default include a tridium certificate, but upgrading a system may have both, the tridium and the default certificate.

2. Confirm that you opened the Workbench User Key Store and click the New button at the bottom of the view.
   Note: If you opened the platform/station Certificate Management view by mistake, you can still create a root CA certificate, but it will not be available to sign the other certificates.
   The Generate Self Signed Certificate window opens.
   
   

   All certificates begin as self-signed certificates. Only the root CA certificate remains self-signed because it sits at the top of the certificate chain.

3. Fill in the form and click OK.

   • Use Alias to identify this as a root certificate.

   • Use the Distinguished Name (CN) edit mode to fill in the following information:

     • The Common Name(CN) becomes the Subject (also known as the Distinguished Name). For a root CA certificate, the Common Name(CN) may be the same as the Alias.

     • Organization should be the name of the company.

     • Although Locality and State/Province are not required and are arbitrary, leaving them blank generates a warning message.

     • The two-character Country Code is required and must be a known value, such as: US, IN, CA, FR, DE, ES, etc. (refer to the ISO CODE column at countrycode.org).

   • Based on the Not Before and Not After dates, certificate validity defaults to a year. A longer period is not recommended and not tolerated by some browsers. Changing to a new certificate annually or even within a year makes it more likely that your certificate contains the latest cryptographic standards, and reduces the number of old, neglected certificates that can be stolen and re-used for phishing and drive-by malware attacks.

   • Key Size defaults to 2048. A larger key improves security and does not significantly affect communication time. The only impact it has is to lengthen the time it takes to create the certificate initially.

   • For Certificate Usage, select CA.

   • The HTML5 Generate Certificate window allows you to add extensions, which specify information such as alternative subject names and usage restrictions to certificates.

     • Key Usage: defines the purpose (for example, encipherment, signature, certificate signing) of the key contained in the certificate. You can use it to restrict the usage of a certificate’s key only to permitted operations. For example, a key that should only be used for key management should have the keyEncipherment bit set.

     • Subject Alternative Name: allows identities to be bound to the subject of the certificate. Defined options include an Internet electronic mail address, a DNS name, an IP address, and a Uniform Resource Identifier (URI).

     • Extended Key Usage: indicates one or more purposes for which the certificate may be used in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates. You can create a custom key usage extension that must be an OID with numbers separated by decimals (for example, 1.2.3).

   The Private Key Password window opens.
4. Enter and confirm a strong password, and click OK.
   The system informs you that the certificate has been submitted. Soon the certificate appears behind the Info message in the User Key Store table.
5. To continue, click OK.
   The root CA certificate now exists with both its keys in the Workbench User Key Store. From this location you can use it to sign other certificates (intermediate, server, client and code-signing).

   Note: The exclamation icon () indicates that the certificate is not signed by a Certificate Authority. For a server, client, or code signing certificate, it means that the certificate will not be trusted by other parties. For a root CA, which itself is the source of trust, this is normal and expected.

   For this certificate to authenticate the certificates it signs, you now need to export it with only its public key and import it into the User Trust Store of each client computer and platform/station.

6. Select the new root CA certificate and click Export.
   The Certificate Export window opens.
   
   

   CAUTION: Do not click the check box to Export the private key.The only time you click this check box is when you are backing up the certificate to another location for safe keeping.
7. To create the root CA certificate that will reside in each client’s User Trust Store, click OK.
   The Certificate Export window opens with the file ready to export as a .pem file.
   
   

   Notice the Current Path. This is where the system stores the exported certificate.

8. Navigate to a rootcert folder or location on a thumb drive, and click Save.
   The system reports that it exported the certificate successfully.
9. To complete the export, click OK.