Certificate Authority Operations

During installation of Keyfactor Command, 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. records are created for any Microsoft CAs found in the local forestClosed An Active Directory forest (AD forest) is the top most logical container in an Active Directory configuration that contains domains, and objects such as users and computers. in which Keyfactor Command is installed. If you have Microsoft CAs in separate forests in a two-way trust with the forest in which Keyfactor Command is installed, you will need to use the import option to import CA records from those forests. If you have Microsoft CAs in any other configuration or EJBCA CAs, you will need to manually configure CA records for them.

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.

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 199: Import Certificate Authorities

    Your certificate authorities and CA gateways will be retrieved from Active Directory in the trusted forest and will populate the CA grid. Import once for each forest containing Microsoft CAs that you want to synchronize or use for enrollmentClosed 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.
    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.

As of Keyfactor Command version 10, CA connections can be tested from the 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. page. There are two new action buttons on the Certificate Authority dialog, Test Connection and Save and Test, in addition to the Cancel button.

Certificate Authorities will be tested before they are saved to the database and must be valid and reachable to be saved. If the CA can't be verified, an error message with an explanation of the issue will be displayed and added to the Command_APIClosed 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._Log.

Note:  As a result of this functionality, it is not possible to add offline root or policy CAs, as they will not be able to be verified. Add any certificates for offline root or policy CAs manually to the Keyfactor Command database using the Add Certificate option (see Add Certificate).

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. Upon a successful test, you will receive a green success notification at the bottom of the page. Upon a test failure, you will receive a pop-up message with the details of the failure; a message will also be added to the log.

Tip:  When adding or editing your CAs, the connection can now be tested and must be valid and reachable for the CA to be saved. See Test a CA Connection.

Whether your CA has been imported or added manually, you'll need to update it to configure synchronization and other optional settings.

Certificate Authorities that need to be added manually include:

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).

Important:  In order for CAs to successfully synchronize to the Keyfactor Command database and perform other functions (e.g. enrollment), the service account under which Keyfactor Command is making the request to the CA must be granted appropriate permission to the CA database as per Grant the Keyfactor Command Users and Service Account(s) Permissions on the CAs in the Keyfactor Command Server Installation Guide.

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.

    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:

    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 checkbox applies 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.
    • 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 DNSClosed 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

    • 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

    • 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 DNClosed 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 200: 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.
    • 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

    • 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 or Windows 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.
    • 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

    • 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

    In the Scan section, choose when to schedule Closedfull 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 201: 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 202: 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.

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

    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), enrollment is done in the context of the user authenticated to Keyfactor Command using Kerberos or Basic authentication.

    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 203: Certificate Authority Basic Tab for a Microsoft CA

    Figure 204: Certificate Authority Basic Tab for an EJBCA CA

    In the Details section, if you've opted to use the Keyfactor Universal Orchestrator or Windows 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 or Windows Orchestrator must be installed on a machine in the forest where the remote CA resides, installed and configured as per Universal Orchestrator in the Keyfactor Orchestrators Installation and Configuration Guide. In addition, in the Management Portal, the Keyfactor Universal Orchestrator or Windows Orchestrator must be configured as per Orchestrator Management.

    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, so failures cannot be reported on 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 or Windows Orchestrator.

    Figure 205: Certificate Authority Advanced Tab for Microsoft CA

    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 CAs to support access control within Keyfactor Command:
    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 Command application pool user. For more information, see Grant the Keyfactor Command Users and Service Account(s) Permissions on the CAs in the Keyfactor Command Server Installation Guide.

    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, ClosedLoad from Keyfactor Secrets or ClosedLoad 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 (formerly Thycotic).

    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.

    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 Identities) 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 or Keyfactor Windows 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.

    The Delegate Management Operations and Delegate Enrollment boxes are used for CAs that support 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. 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 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.

    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 authentication.

    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 Command application pool is running. For more information, see Grant the Keyfactor Command Users and Service Account(s) Permissions on the CAs in the Keyfactor Command Server Installation Guide.

    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) in the Keyfactor Command Server Installation Guide.

    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 (Microsoft and EJBCA CAs)) and the Revoke permission for certificates at both the global and collectionClosed 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 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.

    Warning:  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 in the Keyfactor Command Server Installation Guide).

    The Delegate Management Operations and Delegate Enrollment options are not used for 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. (NOTE: 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 Microsoft CAs where integrated authentication is not supported and EJBCA CAs. 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.

    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.

    Click the Select Authentication Certificate button to upload a client certificate in PKCS#12Closed 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 206: Certificate Authority Authentication Methods Tab for a Microsoft CA

    Figure 207: Certificate Authority Authentication Methods Tab for an EJBCA CA

    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 SANClosed 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 CNClosed 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 PFXClosed 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 CSRClosed 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 Closedretention type. Enter the number of days, weeks, months, or years to keep the encrypted private keyClosed 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.

    Figure 208: 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 Test a CA Connection).

Once a CA record has been created for your CA, go to certificate templates (see Certificate Templates) and import templates for the CA. Template import is supported for both Microsoft and EJBCA CAs. Template import is not supported for the following:

  • Non-domain-joined standalone Microsoft CAs (these don't use templates)

  • CAs accessed via the Keyfactor Universal Orchestrator or Windows Orchestrator

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.