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 servers and 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 provide certificate management capabilities on a variety of platforms and devices (for example Amazon Web Services (AWS) resources, Citrix\NetScaler devices, F5 devices, IIS stores, JKS keystores, PEM stores, and PKCS #12 stores) and execute tasks outside the standard list of certificate management functions. It runs on either Windows or Linux servers or Linux containers. and the Keyfactor Command server or servers. HTTPS relies on certificate trust, which means the orchestratorClosed Keyfactor orchestrators perform a variety of functions, including managing certificate stores and SSH key stores. must trust the root 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.) that issued the certificate used by the Keyfactor Command server.

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. The certificate can either be a publicly rooted certificate (for example, from DigiCert or Entrust) or one issued by a private certificate authority (CA). If your Keyfactor Command server is using a publicly rooted certificate, the orchestrator server may already trust the certificate’s root CA because it is included in the operating system’s default trust store.

However, if you use a certificate issued by an internal CA, the orchestrator server may not trust that CA by default. To use HTTPS for communications between the orchestrator and the Keyfactor Command server with a certificate issued from a private CA, you may need to import the certificate chain for that certificate into either the local machine certificate store on the orchestrator server (Windows) or the root certificate store (Linux).

Note:  Any CRLs 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.