Keyfactor recommends using HTTPS to secure the channel between each Keyfactor Universal Orchestrator
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 (e.g. 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(s). This requires an SSL 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 authority 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. (CA 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 orchestrator 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.
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).Installations on Windows Servers
If the public key infrastructure 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. (PKI 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.
Installations on Linux Servers and in Linux Containers
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.
Was this page helpful? Provide Feedback