Configure Certificate Root Trust for the Universal Orchestrator

Keyfactor recommends using HTTPS to secure the channel between each Keyfactor Universal OrchestratorClosed The Keyfactor Universal Orchestrator, one of Keyfactor's suite of orchestrators, is used to interact with Windows servers (a.k.a. IIS certificate stores) and FTP capable devices for certificate management, run SSL discovery and management tasks, and manage synchronization of certificate authorities in remote forests. With the addition of custom extensions, it can run custom jobs to provide certificate management capabilities on a variety of platforms and devices (e.g. F5 devices, NetScaler devices, Amazon Web Services (AWS) resources) and execute tasks outside the standard list of certificate management functions. It runs on either Windows or Linux. and the Keyfactor Command server(s). This requires an SSLClosed TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer) are protocols for establishing authenticated and encrypted links between networked computers. certificate configured in IIS on the Keyfactor Command server(s). This certificate can either be a publicly-rooted certificate (e.g. from DigiCert, Entrust, etc.), or one issued from a private certificate authorityClosed A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA. (CAClosed A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA.). If your Keyfactor Command server is using a publicly rooted certificate, the orchestratorClosed Keyfactor orchestrators perform a variety of functions, including managing certificate stores and SSH key stores. server may already trust the certificate root for this certificate. However, if you have opted to use an internally-generated certificate, your orchestrator server may not trust this certificate. In order to use HTTPS for communications between the orchestrator and the Keyfactor Command server with a certificate generated from a private CA, you may need to import the certificate chain for the certificate into either the local machine certificate store on the orchestrator server on Windows or the root certificate store on Linux.

Note:  The CRLClosed A Certificate Revocation List (CRL) is a list of digital certificates that have been revoked by the issuing Certificate Authority (CA) before their scheduled expiration date and should no longer be trusted.(s) for the Keyfactor Command certificate need to be available to the orchestrator (see Troubleshooting).

If the public key infrastructureClosed A public key infrastructure (PKI) is a set of roles, policies, and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption. (PKIClosed A public key infrastructure (PKI) is a set of roles, policies, and procedures needed to create, manage, distribute, use, store and revoke digital certificates and manage public-key encryption.) that issued the certificate has only a root CA, the root certificate from this CA must be installed in the Trusted Root Certification Authorities store under Local Computer on the orchestrator server. If the PKI that issued the certificate has both a root and issuing CA, the root certificate must be installed in the Trusted Root Certification Authorities store under Local Computer on the orchestrator server and the issuing CA certificate must be installed in the Intermediate Certification Authorities store under Local Computer on the orchestrator server.

The location of the OpenSSL trusted root store varies depending on your Linux implementation. The root certificate must be installed in the appropriate location for the operating system before beginning the installation.