Certificate Authority Operations

Microsoft CA and Keyfactor CA gateway records from the Active Directory forest in which Keyfactor Command is installed and any Active Directory forests in a two-way trust with this forest may be imported using the Import option provided they are registered in Active Directory.

To import CA records:

1. In the Management Portal, browse to Locations > Certificate Authorities.
2. On the Certificate Authorities grid, click the Import action button to import local or two-way trusted forest CAs and Keyfactor CA gateways.

3. In the Import Certificate Authorities dialog, select the forest from which you want to import in the dropdown and click Import.

   

   Figure 211: Import Certificate Authorities

   Your certificate authorities and CA gateways will be retrieved from Active Directory in the selected forest and will populate the CA grid. Import once for each forest containing Microsoft CAs that you want to synchronize or use for enrollment Certificate enrollment refers to the process by which a user requests a digital certificate. The user must submit the request to a certificate authority (CA)..

   Once the records are imported, use the Edit option (see Adding or Modifying a CA Record) to configure synchronization and other optional settings for the CA.

   Tip:  This step does not need to be completed for the forest in which Keyfactor Command is installed because those records are imported during the installation process for domain-joined servers unless you have added a new CA or CA gateway following Keyfactor Command installation.
   Note:  Keyfactor CA gateways are not supported in any configuration other than in the same forest in which Keyfactor Command is installed.
   Note:  The import option only works for Microsoft CAs or Keyfactor CA gateways that have been registered in Active Directory. Non-domain-joined servers will not have any options available in this dropdown.

CA connections can be tested using the action buttons on the 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. dialog, Test Connection and Save and Test.

Certificate Authorities will be tested before they are saved to the database. If the CA can't be verified, an error message with an explanation of the issue will be displayed and added to the Audit Log and you will be given the option to save the configuration anyway.

• For EJBCA, the test checks that the CA name provided is valid for the given EJBCA instance. It validates the hostname The unique identifier that serves as name of a computer. It is sometimes presented as a fully qualified domain name (e.g. servername.keyexample.com) and sometimes just as a short name (e.g. servername)., the EJBCA version (7.8.1 or greater), connectivity to the required REST and SOAP APIs enabled in the EJBCA instance (see Certificate Authorities), and the authentication certificate.

• For Microsoft, the test checks the forest, logical name The logical name of a CA is the common name given to the CA at the time it is created. For Microsoft CAs, this name can be seen at the top of the Certificate Authority MMC snap-in. It is part of the FQDN\Logical Name string that is used to refer to CAs when using command-line tools and in some Keyfactor Command configuration settings (e.g. ca2.keyexample.com\Corp Issuing CA Two)., CA host, and explicit credentials by using a certutil ping.

• Remote CAs (managed by an orchestrator Keyfactor orchestrators perform a variety of functions, including managing certificate stores and SSH key stores.) will not have the connection tested before saving the CA. The Test Connection button will be active, but you will receive a message that the connection cannot be tested if you click it. The Save and Test button will skip the test when saving.

To test a CA record:

1. In the Management Portal, browse to Locations > Certificate Authorities.
2. On the Certificate Authorities grid, click Add to add a new CA, or click Edit to modify an existing CA, from either the top or right-click menu.

3. Follow the instructions for adding or modifying a CA (see Adding or Modifying a CA Record). Once you have entered the details you want to test, click Test Connection or Save and Test.

   1. Upon a successful test, you will receive a green success notification at the bottom of the page and will be returned to the certificates authority grid.

   2. Upon a test failure, you will receive a pop-up message and an entry will also be added to the audit log. Click OK to save the CA despite the error, or click CANCEL to return to the dialog to correct any issues.

      

      Figure 212: Save Certificate Authority

Whether your CA has been imported or added manually, you'll need to update it to configure synchronization and other optional settings. When adding or editing your CAs, the connection can now be tested prior to saving.

CAs that need to be added manually include:

• A domain-joined enterprise or standalone Microsoft CA in a forest with a one-way trust (either direction) with the forest in which Keyfactor Command is installed
• A domain-joined enterprise or standalone Microsoft CA in a forest that has no trust with the forest in which Keyfactor Command is installed
• An EJBCA CA
• A non-domain-joined standalone Microsoft CA

• A Keyfactor CA gateway in the forest in which Keyfactor Command is installed that has not been registered in Active Directory

  The CA gateways are used to access cloud certificate providers (e.g. Entrust) or to support Microsoft or EJBCA CAs in remote or cloud environments (e.g. the Cross-Forest Gateway).

  Note:  Keyfactor CA gateways are not supported in any configuration other than in the same forest in which Keyfactor Command is installed.
• An on-premise Microsoft CA accessed via the Keyfactor CA Management Gateway The Keyfactor CA Management Gateway is made up of the Keyfactor Gateway Connector, installed in the customer forest to provide a connection to the local CA, and the Azure-hosted and Keyfactor managed Hosted Configuration Portal. The solution is used to provide a connection between a customer's on-premise CA and an Azure-hosted instance of Keyfactor Command for synchronization, enrollment, and management of certificates. using a managed instance of Keyfactor Command
• An on-premise EJBCA CA accessed via the Keyfactor CA Management Gateway using a managed instance of Keyfactor Command

• A Microsoft CA accessed via the 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.

  Note:  You must install and configure the Keyfactor Universal Orchestrator on a machine in the same forest where the Microsoft CA resides and configure it with CA Support and approve the orchestrator in the Management Portal before creating the CA record.

If your Microsoft CA or Keyfactor CA gateway is domain-joined in the forest in which Keyfactor Command is installed or a forest in a two-way trust with this forest and has been registered in Active Directory, you can opt to add a record for it manually, but it is generally easier to use the import option (see Importing Trusted Forest CAs).

To create a CA record manually or edit an existing one:

1. In the Management Portal, browse to Locations > Certificate Authorities.
2. On the Certificate Authorities grid, click Add to add a new CA, or click Edit from either the top or right-click menu to modify an existing one.

3. At the top of the dialog, choose an appropriate CA communication protocol in the Select CA Communication Protocol dropdown. The options are:

   • DCOM—Select this option for Microsoft CAs and CA gateways.

   • HTTPS—Select this option for EJBCA CAs and AnyCAGateway REST.

   This field cannot be modified on an edit.

4. The remainder of the Certificate Authority dialog shows four tabs. Only the first three are used for EJBCA CAs. Complete the Certificate Authority dialog with the appropriate data using the following instructions:

   The Basic Tab

   Details

   In the Details section populate the Logical Name, Host Name and Configuration Tenant fields with the appropriate information for the CA. (The Enforce Unique DN and Create new End Entity when renewing or reissuing certificates checkboxes apply only to the HTTPS Certificate Authorities).

   The Configuration Tenant field cannot be modified on an edit.

   Tip:  Previous versions of Keyfactor Command referred to the Configuration Tenant as the Template Forest.

   Domain-Joined Enterprise or Standalone Microsoft CA in a Forest with a One-Way Trust (either direction) with the Forest in which Keyfactor Command is Installed

   • Logical Name—The logical name of the CA in the remote forest. For example: Corp2IssuingCA1

   • Host Name—The fully qualified domain name of the server on which the CA in the remote forest is installed. For example: corp2ca01.keyother.com

   • Configuration Tenant—The DNS The Domain Name System is a service that translates names into IP addresses. domain name for the Active Directory forest in which the CA resides. For example: keyother.com

   Domain-Joined Enterprise or Standalone Microsoft CA in a Forest that has No Trust with the Forest in which Keyfactor Command is Installed

   • Logical Name—The logical name of the CA in the remote forest. For example: Corp3IssuingCA1

   • Host Name—The fully qualified domain name of the server on which the CA in the remote forest is installed. For example: corp3ca01.keyother2.com

   • Configuration Tenant—The DNS domain name for the Active Directory forest in which the CA resides. For example: keyother2.com

   EJBCA CA

   • Logical Name—The logical name of the EJBCA CA. For example: CorpCA1

     Note:  EJBCA CA logical names are case sensitive (e.g. CorpCA1 is not the same as CORPCA1).

   • Host URL—The URL pointing to the EJBCA CA. For example: https://ejbca01.keyother3.com. If the URL provided does not have a virtual directory (/ejbca or otherwise) the /ejbca will be provided, otherwise it will use what is supplied in the URL.

   • Configuration Tenant—A reference ID for the EJBCA CA server. For EJBCA CAs, this does not need to be the DNS domain name. The short hostname of the EJBCA CA server makes a good reference ID.

     Important:  EJBCA and Microsoft CAs cannot be configured with the same Configuration Tenant, so do not set this to the DNS domain name if you will also be configuring Microsoft CAs in the same DNS domain.
   • Enforce Unique DN

     Checking this will cause Keyfactor Command, upon enrollment, to search the EJBCA CA for end entities with DNs that match the DN A distinguished name (DN) is the name that uniquely identifies an object in a directory. In the context of Keyfactor Command, this directory is generally Active Directory. A DN is made up of attribute=value pairs, separated by commas. Any of the attributes defined in the directory schema can be used to make up a DN. in the certificate request. If a matching DN is found, the process will update the existing end entity in EJBCA with the new certificate request information rather than creating a new end entity. If you enable this option in Keyfactor Command, it must also be enabled on the matching EJBCA CA. A mismatch in these settings can result in enrollment failures.

     

     Figure 213: Enforce unique DN Setting on the EJBCA CA

     The value of the Keyfactor Command Enforce Unique DN setting is verified for each certificate request:

     • If unset, enrollment proceeds as usual.

     • If set, EJBCA is searched for an end entity associated with the DN and CA in the certificate request and:

       • If none is found, the enrollment proceeds as usual.
       • If one or more is found, the end entity in EJBCA is updated with the information from the certificate request, so that the new certificate request is tied to the same end entity as the existing certificate (or the first one found, if multiple are found). A new password is generated and the enrollment proceeds as usual.

   Non-Domain-Joined Standalone Microsoft CA

   • Logical Name—The logical name of the standalone CA. For example: CorpSARootCA1

   • Host Name—The fully qualified domain name of the server on which the standalone CA is installed. For example: saroot01.keyexample.com

   • Configuration Tenant—The DNS domain name for the standalone CA. For example: keyexample.com

   Remote CA Accessed via a Keyfactor Universal Orchestrator

   • Logical Name—The logical name of the CA in the remote forest to which the orchestrator will be connecting for synchronization. For example: Corp4IssuingCA1

   • Host Name—The fully qualified domain name of the CA in the remote forest to which the orchestrator will be connecting for synchronization. For example: corp4ca01.keyother4.com

   • Configuration Tenant—The DNS domain name for the Active Directory forest in which the orchestrator is operating and in which the CA resides. For example: keyother4.com

   Note:  You must install and configure the Keyfactor Universal Orchestrator on a machine in the same forest where the CA resides, configure it with CA Support and approve the orchestrator in the Management Portal before creating the CA record.

   Domain-Joined Enterprise or Standalone Microsoft CA in the Forest in which Keyfactor Command is Installed

   • Logical Name—The logical name of the CA in the local forest. For example: CorpIssuingCA1

   • Host Name—The fully qualified domain name of the server on which the CA in the local forest is installed. For example: corpca01.keyexample.com

   • Configuration Tenant—The DNS domain name for the Active Directory forest in which the CA resides. For example: keyexample.com

   Keyfactor CA Gateway

   • Logical Name—The logical name of the CA gateway in the local forest. For example: EntrustGateway

   • Host Name—The fully qualified domain name of the server on which the CA gateway in the local forest is installed. For example: entgtw1.keyexample.com

   • Configuration Tenant—The DNS domain name for the Active Directory forest in which the CA resides. For example: keyexample.com

   Keyfactor CA Management Gateway

   • Logical Name—The logical name created when the gateway was configured. The logical name is unique for each CA gateway. For a gateway providing a bridge to an on-premise Microsoft CA, the name configured as the gateway logical name should match the logical name of the Microsoft CA.

   • Host Name—The fully qualified domain name of the server in the managed forest environment in which the Keyfactor CA Management Gateway is installed.

   • Configuration Tenant—The DNS domain for the Active Directory forest in the managed forest environment in which the Keyfactor CA Management Gateway is installed.

   AnyCAGateway REST

   • Logical Name—The logical name, exactly as entered in AnyCA Gateway portal. The logical name is unique for each CA.

     Note:  Logical names are case sensitive (e.g. CorpCA1 is not the same as CORPCA1).

   • Host URL—The fully qualified domain name of the server on which the gateway is installed and the port number defined in -ServerPort. For example: CAGateway24.keyexample.com:8443. The Host URL is unique for each CA.

   • Configuration Tenant—A reference ID for the gateway CA. Can be any name you choose.

   • Create new End Entity when renewing or reissuing certificates

     Checking this will force the gateway CA to create a new end entity for any renew/reissue of a certificate. This is required for the AnyCAGateway REST.

   Scan

   In the Scan section, choose when to schedule full and incremental scans. You can choose to run each scan Weekly, Daily or on an Interval:

   • If you select Weekly, you can select one or more days of the week on which to run the scan and a time when the scan should begin.
   • If you select Daily, you can set the time of day when the scan should begin.
   • If you select Interval, you can select a scan frequency of anywhere from every 1 minute to every 12 hours.

   • Select Off in the dropdown to disable a scan job.

     There are two types of synchronization schedules available for CAs—Full and Incremental. You do not necessarily need to configure both types. A full scan reads all the certificates and certificate requests in the CA database and synchronizes them to Keyfactor Command regardless of their current state in Keyfactor Command. An incremental scan reads the certificates and certificate requests in the CA database that have been generated since the last full or incremental scan and synchronizes them to Keyfactor Command. A common configuration would be a full scan once or twice a week to provide a clean image of the CA database with a frequent incremental scan to provide timely updates to Keyfactor Command. For a large CA database, a full scan can take a long time to complete. Since an incremental scan only synchronizes updates that have occurred to the CA database since the last synchronization was run, this process is generally quick (other than for the initial synchronization when Keyfactor Command is first installed). The frequency of the incremental scans would depend on the volume of certificate requests coming into the CA.

     Note:  For EJBCA CAs, if the certificate profile has a Validity Offset configured to a value greater than the value configured in the CA Sync Backward Offset Minutes application setting (15 minutes by default), certificates requested outside of Keyfactor Command will not be picked up on incremental scans. These certificates will only appear in Keyfactor Command on a full synchronization. The CA Sync Backward Offset Minutes application setting should be set to the same number of minutes as the Validity Offset value, if Validity Offset is configured.

     

     Figure 214: EJBCA Certificate Profile Validity Offset Greater than 15 Minutes

     Note:  For EJBCA CAs, if the certificate profile has Allow Backdated Revocation configured and a revocation is completed outside of Keyfactor Command with a backdate of greater than 10 minutes, the revocation will not be picked up on incremental scans. These revocations will only appear in Keyfactor Command on a full synchronization.

     

     Figure 215: EJBCA Certificate Profile Backdated Revocation

   For Microsoft CAs, if desired check the Sync External Certificates box to allow foreign certificates that have been imported into a Microsoft CA to be synchronized to Keyfactor Command along with the certificates issued by the Microsoft CA. This option does not appear for HTTPS CAs.

   Enrollment

   In the Enrollment section, check the Enable PFX Enrollment and/or Enable CSR Enrollment box to enable enrollment for the CA through Keyfactor Command.

   If you wish to use One-Click Renewal for certificates, the Allow One-Click Renewals option must be enabled in both the templates and CAs to which you want One-Click Renewal to apply (see Certificate Template Operations and Adding or Modifying a CA Record). For more information about one-click renewals, see Renew.

   Note:  In order to perform enrollment through Keyfactor Command, the account making the request to the CA must be granted appropriate enroll permissions on the CA itself. Which account this is depends on the authorization configuration (see Authorization Methods Tab):

   • If Use Explicit Credentials is set to true (box checked), enrollment is done in the context of that explicit user and that user needs permission.
   • If Use Explicit Credentials is set to false (box not checked), the user context in which enrollment is done will vary (see Grant the Keyfactor Command Users and Service Account(s) Permissions on the CAs).

   Enrollment is not supported using NTLM authentication.

   If desired, check the Require Subscriber Terms box to add a checkbox on the enrollment pages to force users to agree to a custom set of terms before enrolling. Configure a link to the custom terms using the URL to Subscriber Terms application setting (see Application Settings: Enrollment Tab).

   Tip:  To fully configure enrollment for the CA, you will also need to configure access on the Authorization Methods tab (see Authorization Methods Tab) and configure templates (see Certificate Template Operations).

   

   Figure 216: Certificate Authority Basic Tab for a Microsoft CA

   

   Figure 217: Certificate Authority Basic Tab for an AnyGateway REST CA

   Note:  When configuring an HTTPS CA, Enforce Unique DN and Create new End Entity when renewing or reissuing certificates are mutually exclusive options; they CANNOT both be selected since they're telling the CA to do opposite things.

   • Enforce Unique DN will be DISABLED if Create new End Entity when renewing or reissuing certificates is ENABLED.

   • Create new End Entity when renewing or reissuing certificates will be DISABLED if Enforce Unique DN is ENABLED.

   • Create new End Entity when renewing or reissuing certificates is set to false by default.

   Advanced Tab

   Details

   In the Details section, if you've opted to use the Keyfactor Universal Orchestrator to communicate with a remote CA, check the Use Orchestrator box and choose the appropriate orchestrator from the dropdown.

   Note:  The Orchestrator dropdown is only active if the Use Orchestrator box is checked. If Use Orchestrator is checked, the Orchestrator dropdown will populate with any orchestrators approved in Keyfactor Command with the CA capability. The Keyfactor Universal Orchestrator must be installed on a machine in the forest where the remote CA resides, installed and configured as per Universal Orchestrator. In addition, in the Management Portal, the Keyfactor Universal Orchestrator must be configured as per Orchestrator Management.

   Monitoring

   In the Monitoring section, check the Enable Monitoring box to turn on email alerting when certificate issuance or failures (including denials) since the last threshold alert was sent falls outside the configured limits. You can choose to schedule the alerts either for daily delivery at a specified time or at intervals of anywhere from every 1 minute to every 12 hours. Daily is the most common configuration. Set the thresholds for:

   • Issuance Greater Than—You will receive an alert if more certificates are issued by this CA in the time period between executions of the alert than the number you set here. The value set here must be greater than, or equal to, the value set for Issuance Less Than.
   • Issuance Less Than—You will receive an alert if fewer certificates are issued by this CA in the time period between executions of the alert than the number you set here. The minimum allowed value for Issuance Less Than is 1.
   • Failures Greater Than—You will receive an alert if more certificate requests fail or are denied by this CA in the time period between executions of the alert than the number you set here. Zero is a valid setting (meaning you will receive an alert for a single failure).
     Note:  EJBCA CAs do not return failure counts using the API A set of functions to allow creation of applications. Keyfactor offers the Keyfactor API, which allows third-party software to integrate with the advanced certificate enrollment and management features of Keyfactor Command., so failures cannot be reported with threshold monitoring for EJBCA CAs.

   In addition to configuring the thresholds for each CA, you must also configure the email recipients on the Alert Recipients tab (see Certificate Authority Monitoring) of the Certificate Authorities page. Monitoring is not supported for CAs accessed with the Keyfactor Universal Orchestrator.

   

   Figure 218: Certificate Authority Advanced Tab for Microsoft CA

   Authorization Methods Tab

   On the Authorization Methods tab, you configure how access for management tasks and enrollment occurs for the CA.

   Tip:  Keyfactor recommends the following configuration for most DCOM CAs to support access control within Keyfactor Command:

   • Use Explicit Credentials: True or false as required by the environment
   • Delegate Management Operations: False (box unchecked)
   • Delegate Enrollment: False (box unchecked)
   • Restrict Allowed Requesters: Set to the Keyfactor security roles allowed to perform certificate enrollment for this CA. If you're using workflow A workflow is a series of steps necessary to complete a process. In the context of Keyfactor Command, it refers to the workflow builder, which allows you automate event-driven tasks when a certificate is requested or revoked. (see Workflow Definitions), the users who hold these roles are the ones who are able to initiate workflows. This is entirely separate from the roles configured within workflows, which control the users who are able to approve workflows.

   Note:  If Use Explicit Credentials, Delegate Management Operations and Delegate Enrollment are all set to false (box unchecked), requests to the CA are made in the context of the Keyfactor API application pool user. For more information, see Grant the Keyfactor Command Users and Service Account(s) Permissions on the CAs.

   Use Explicit Credentials (DCOM-Microsoft CAs)

   The Use Explicit Credentials option allows you to configure specific credentials that will be used to make requests to the CA for management tasks and enrollment. This is generally used for Microsoft CAs where Windows integrated authentication is not supported. Integrated authentication is generally supported for Microsoft CAs, Keyfactor CA gateways, or Keyfactor CA management gateways on servers joined to the local Active Directory forest in which Keyfactor Command is installed and any Active Directory forests in a two-way trust with this forest.

   To configure this option, check the Use Explicit Credentials box and enter a username in the format DOMAIN\username for a service account user in the forest in which the CA resides or, for non-domain-joined machines, a local machine account on the machine on which the CA is installed. Click the Set Explicit Password button and in the Set Explicit Password dialog, choose from No Value, Load from Keyfactor Secrets or Load From PAM Provider.

   A Keyfactor secret is a user-defined password or other information that is encrypted and stored securely in the Keyfactor Command database. Although Keyfactor recommends using Privileged Access Management (see Privileged Access Management (PAM)) as a more secure solution to secure information, Keyfactor Secret is an option for customers that do not already have a relationship with a PAM provider such as CyberArk or Delinea.

   Important:  Keyfactor highly recommends that you use strong passwords for any accounts or certificates related to Keyfactor Command and associated products, especially when these have elevated or administrative access. A strong password has at least 12 characters (more is better) and multiple character classes (lowercase letters, uppercase letters, numeral, and symbols). Ideally, each password would be randomly generated. Avoid password re-use.

   Select the Load From Keyfactor Secrets radio button as the Secret Source if you want Keyfactor Command to encrypt and store the password in the Keyfactor Command database. Enter and confirm a password.

   Select the Load from PAM Provider radio button as the Secret Source if you want to store the password in a supported third-party PAM solution (see Privileged Access Management (PAM)). The remaining fields on the dialog will vary depending on the PAM provider. For example:

   CyberArk

   Select your CyberArk provider in the Providers dropdown if your PAM provider is CyberArk (see Adding or Modifying a PAM Provider). The remaining fields in the dialog will then be:

   • Safe—The name of the safe the credential resides in.
   • Object—The name of the username or password object in the safe.
   • Folder—The path and name of the folder that stores the object (e.g. Root or Root\MyDir).

   Delinea

   Select your Delinea provider in the Providers dropdown if your PAM provider is Delinea (see Adding or Modifying a PAM Provider). The remaining field in the dialog will then be:

   • Secret Server Secret ID—The numeric ID of the secret to retrieve from Secret Server.
   • Secret Field Name—The name of the field to use when retrieving a secret form Secret Server.

   Hashicorp

   Select your Hashicorp Vault provider in the Providers dropdown if your PAM provider is Hashicorp Vault (see Adding or Modifying a PAM Provider). The remaining field in the dialog will then be:

   • KV Secret Key—The key of the secret to retrieve from the Hashicorp Vault.
   • KV Secret Name—The name of the secret to retrieve from the Hashicorp Vault.

   This service account user needs appropriate permissions in the CA security settings to accomplish the tasks you plan to carry out for this CA through the Management Portal. For example:

   • Certificate enrollment
   • Certificate revocation
   • Certificate key recovery
   • Certificate request approval and denial

   These tasks will be carried out on the CA in the context of the credentials you provide here. Access control for these tasks is controlled with Keyfactor Command security (see Security Roles and Claims) and the Restrict Allowed Requesters option, below.

   Note:  When this option is configured, enrollment and other tasks (e.g. revocation) are done in the context of the user configured here, not the user making the request in Keyfactor Command. This overrides the existing AD security policy used by Keyfactor Command.

   Note:  Once you have established explicit credentials to a forest for a CA, the forest will be included in the forest dropdown on the Import Templates dialog (see Certificate Templates).

   Tip:  The Use Explicit Credentials option is not needed if you are accessing your CA using a Keyfactor Universal Orchestrator. Enrollment is not supported when accessing a CA using an orchestrator, so the Restrict Allowed Requesters option is not relevant for this type of CA configuration.

   The Use Explicit Credentials option is not used for EJBCA CAs.

   Delegate Management Operations & Delegated Enrollment (DCOM-Microsoft CAs & CA Gateways)

   Important:  The Delegate options are only supported when using Active Directory as an identity provider.

   The Delegate Management Operations and Delegate Enrollment boxes are used for CAs that support Windows integrated authentication to allow interactions with the CAs via Keyfactor Command to be done in the context of the user authenticated to Keyfactor Command using Kerberos authentication. These options also apply to users who authenticate to Keyfactor Command using Basic authentication, since Keyfactor Command performs pseudo delegation for these users. These options are not supported for users who authenticate using NTLM or Token authentication.

   Integrated authentication is generally supported for Microsoft CAs, Keyfactor CA gateways, or Keyfactor CA management gateways on servers joined to the local Active Directory forest in which Keyfactor Command is installed and any Active Directory forests in a two-way trust with this forest. If delegation is enabled, when a user authenticates with Kerberos or Basic authentication to Keyfactor Command, the Keyfactor Command server can delegate the user's credentials to the CA to provide end-to-end authentication without unpacking the credentials at the Keyfactor Command layer.

   If you choose to disable one or both of the delegation options and have not enabled the Use Explicit Credentials option, interaction with the CA for the type of activity that is not delegated (e.g. management operations) is done in the context of the service account under which the Keyfactor API application pool is running. For more information, see Grant the Keyfactor Command Users and Service Account(s) Permissions on the CAs.

   Note:  Use of explicit credentials is mutually exclusive of delegation.

   Important:  If you configure CA delegation and are using Kerberos authentication, you must also configure Kerberos constrained delegation for the CAs as per Configure Kerberos Constrained Delegation (Optional).

   The types of interactions affected by these settings include:

   • Approval of pending certificate requests (Delegate Management Operations)
   • Denial of pending certificate requests (Delegate Management Operations)
   • Revocation of certificates (Delegate Management Operations)
   • Certificate key recovery (Delegate Management Operations)
   • Certificate enrollment (Delegate Enrollment)

   Note:  If a workflow (see Workflow Definitions) is configured with a step that will result in a suspended state (e.g. pausing to wait for approvals) and the CA for the request is configured for delegation, the enrollment or revocation request made via the workflow will fail with an error indicating that the failure occurred because CA delegation is enabled. Workflows are not supported with CA delegation in the case where a suspended state may occur because it's possible that the initiating user's context may not be available all the way to the conclusion of the workflow.

   When using workflow with steps that will result in a suspended state, do not use CA delegation. Instead, use the Keyfactor Command access control model provided by the Restrict Allowed Requesters option for enrollment (see Restrict Allowed Requesters (DCOM-Microsoft and HTTPS-EJBCA CAs)) and the Revoke permission for certificates at both the global and collection The certificate search function allows you to query the Keyfactor Command database for certificates from any available source based on any criteria of the certificates and save the results as a collection that will be availble in other places in the Management Portal (e.g. expiration alerts and certain reports). levels (see Certificate Collection Permissions).

   If you choose to enable delegation, be aware that each user performing one of these delegable operations through the Management Portal must have the appropriate permissions to accomplish this task configured in the CA security settings.

   Important:  Granting users permissions in the CA security settings for certificate revocation, certificate key recovery, or certificate request approval and denial—e.g. the Issue and Manage Certificates permission—in order to support delegation of these operations through the Management Portal also grants these permissions to the users when operating outside the Keyfactor Command Management Portal. Any risk associated with this can be mitigated by implementing the Keyfactor Whitelist Policy Handler on each CA where such permissions are granted (see Installing the Keyfactor CA Policy Module Handlers).

   The Delegate Management Operations and Delegate Enrollment options are not used for EJBCA CAs.

   Restrict Allowed Requesters (DCOM-Microsoft and HTTPS-EJBCA CAs)

   The Restrict Allowed Requesters option is used to select Keyfactor Command security roles that a user must belong to in order to successfully enroll for certificates in Keyfactor Command via this CA. This option must be used to provide enrollment access if the Delegate Enrollment option is disabled. With this option checked, you must include at least one role in the Allowed Requester Security Roles table for enrollment to work.

   This option is supported for all CAs, but it must be used for:

   • Implementations using an identity provider other than Active Directory.

   • Microsoft CAs where Windows integrated authentication is not supported.

     Integrated authentication is generally supported for Microsoft CAs, Keyfactor CA gateways, or Keyfactor CA management gateways on servers joined to the local Active Directory forest in which Keyfactor Command is installed and any Active Directory forests in a two-way trust with this forest. Since Keyfactor Command cannot make use of the access control model of the CA itself to determine which users can enroll for certificates at either a template or CA level without using integrated authentication, this setting replaces that functionality. This setting is similar to setting request certificates for the selected security roles at the CA level on a Microsoft CA.

   • EJBCA CAs.

   The Restrict Allowed Requesters check box must be checked—and the Allowed Requester Security Roles populated—if the Use Explicit Credentials box is checked for a Microsoft CA that isn't accessed using integrated authentication.

   Tip:  For Microsoft CAs in a two-way trust environment you don't necessarily need to enable Restrict Allowed Requesters on the CA, though this may be required in some circumstances depending on the security configuration in the environment. However, templates for a two-way trust environment always require configuration of this option at a template level to support enrollment (see Certificate Template Operations).

   In addition to granting permissions at the CA level using this option, you need enable the Restrict Allowed Requesters option to grant permissions on a template-by-template basis (see Certificate Templates).

   Note:  Access control for other types of interactions with the CA (e.g. revocation) is managed with standard security roles (e.g. the certificate revoke permission) at both the global and certificate collection level.

   Authentication Certificate (HTTPS-EJBCA CAs)

   Click the Select Authentication Certificate button to upload a client certificate in PKCS#12 A PFX file (personal information exchange format), also known as a PKCS#12 archive, is a single, password-protected certificate archive that contains both the public and matching private key and, optionally, the certificate chain. It is a common format for Windows servers. format used to provide authentication to the EJBCA CA. This certificate is used to authenticate to the EJBCA database for synchronization, enrollment and management of certificates.

   Note:  Once you have established a connection to the EJBCA CA, it will be included in the forest dropdown on the Import Templates dialog (see Certificate Templates).

   

   Figure 219: Certificate Authority Authentication Methods Tab for a DCOM-Microsoft CA

   

   Figure 220: Certificate Authority Authentication Methods Tab for an HTTPS-EJBCA CA

   Standalone Tab (Microsoft CAs)

   To configure a standalone Microsoft CA, check the Standalone box.

   Check the Enforce RFC 2818 Compliance box to require that certificate enrollments made through the Keyfactor Command Management Portal for this CA include at least one DNS SAN The subject alternative name (SAN) is an extension to the X.509 specification that allows you to specify additional values when enrolling for a digital certificate. A variety of SAN formats are supported, with DNS name being the most common.. This causes the CN A common name (CN) is the component of a distinguished name (DN) that represents the primary name of the object. The value varies depending on the type of object. For a user object, this would be the user's name (e.g. CN=John Smith). For SSL certificates, the CN is typically the fully qualified domain name (FQDN) of the host where the SSL certificate will reside (e.g. servername.keyexample.com or www.keyexample.com). entered in PFX A PFX file (personal information exchange format), also known as a PKCS#12 archive, is a single, password-protected certificate archive that contains both the public and matching private key and, optionally, the certificate chain. It is a common format for Windows servers. enrollment to automatically be replicated as a SAN, which the user can either change or accept. For CSR A CSR or certificate signing request is a block of encoded text that is submitted to a CA when enrolling for a certificate. When you generate a CSR within Keyfactor Command, the matching private key for it is stored in Keyfactor Command in encrypted format and will be married with the certificate once returned from the CA. enrollment, if the CSR does not have a SAN that matches the CN, one will automatically be added to the certificate if this is set.

   If you have configured the CA for PFX enrollment on the Basic tab, the Key Retention field dropdown will display. Select a retention type. Enter the number of days, weeks, months, or years to keep the encrypted private key Private keys are used in cryptography (symmetric and asymmetric) to encrypt or sign content. In asymmetric cryptography, they are used together in a key pair with a public key. The private or secret key is retained by the key's creator, making it highly secure. stored in the Keyfactor Command database based on the type selected, then select the desired time frame (Day(s), Week(s), Month(s), or Year(s)). You will not have the option to choose a retention timeframe if you choose Indefinite.

   Configuring private key retention allows the private keys for certificates enrolled through Keyfactor Command to be stored, encrypted, in the Keyfactor Command database for a user-definable period of time.

   The private key retention configuration options are:

   • Blank

     The private key will not be retained if the box is unchecked, or the blank option is selected.

   • Indefinite

     The private key will be retained until it is explicitly deleted.

   • After Expiration

     The private key will be retained until the specified number of days, weeks, months or years after the certificate expires, at which point it will be scheduled for deletion.

   • From Issuance

     The private key will be retained until the specified number of days, weeks, months or years after the date on which the certificate was issued, at which point it will be scheduled for deletion.

   Note:  When the retention period is stored in the database, weeks are converted to 7 days, months are converted to 30 days, and years are converted to 365 days.

   Tip:  Setting the retention period to 0 will cause the private keys to be purged by the private key clean up job when it next runs, after the certificate expires or after the certificate is issued.

   

   Figure 221: Certificate Authority Standalone Tab

5. Click Test and Save to add or update the CA, or click Test Connection to test the CA prior to saving (see Testing a CA Connection) for more information, including options for a failed CA test.

To delete a CA record:

1. In the Management Portal, browse to Locations > Certificate Authorities.
2. On the Certificate Authorities grid, highlight the row in the CA grid and click Delete at the top of the grid or right-click the CA and choose Delete from the right-click menu.
3. On the Confirm Operation alert, click OK to confirm or Cancel to cancel the operation.

A CA cannot be deleted if:

• It has scanning tasks enabled.
• It has certificates associated with it in the Keyfactor Command database.
• It is the last CA for its Configuration Tenant and there are certificate templates (see Certificate Templates) for that Configuration Tenant in Keyfactor Command.