2025 First Quarterly Release - 25.1.1 Notes

April 2025

Keyfactor announces Keyfactor Command 25.1.1, which includes some major new features and updates such as 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). patterns, which provide flexibility for enrollment, clarification of the reenrollment function with a rename to on-device key generation and expanded availability, and a new certificate cleanup task.

Please refer to Keyfactor Command Upgrading for important information about the upgrade process. For a complete list of the items included in this release, see Release Note Details v25.1.1. For gateway and CA Connector Client release notes, see:

• CA Connector Client Release Notes
• Keyfactor Cloud Gateway Release Notes
• Keyfactor Windows Enrollment Gateway Release Notes
• KeyfactorAnyCAGateway DCOM Release Notes
• Keyfactor AnyCA Gateway REST Release Notes

Highlights

• Enrollment Patterns

  Keyfactor Command now supports enrollment patterns to simplify enrollment configuration management. Enrollment patterns work with certificate templates to define enrollment parameters (such as policies, default subjects, and metadata Metadata provides information about a piece of data. It is used to summarize basic information about data, which can make working with the data easier. In Keyfactor Command, the certificate metadata feature allows you to create custom metadata fields that allow you to tag certificates with tracking information about certificates. values) for different user groups, without requiring multiple duplicate templates at the 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. level.

  With this feature:

  • A single certificate template A certificate template defines the policies and rules that a CA uses when a request for a certificate is received. can have multiple enrollment patterns to meet diverse business needs.

  • One enrollment pattern must always be designated as the default for each template.

  • Access to certificate authorities can be restricted based on enrollment patterns, allowing, for example, users in the Power Users group to enroll for certificates from the CorpIssuingCA1 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. while preventing users in the 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. Users group from seeing CorpIssuingCA1 as an option—even when both groups use the same template.

  Usage notes:

  • The configuration settings for enrollment fields, regular expressions, default subjects, and enrollment policies have moved from the templates to the enrollment patterns.
  • On upgrade, an enrollment pattern will automatically be generated for any template for which at least one of the following is true:
    • 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, 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, or CSR Generation is enabled.
    • Restrict Allowed Requesters is enabled and at least one security role configured in Allowed Request Security Roles.
    • One or more custom values are defined on the Enrollment Fields tab.
    • One or more regular expressions are defined on the Enrollment RegExes tab other than the default value of .+ for Common Name 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)..
    • One or more default values are defined on the Enrollment Defaults tab.
    • Any policies that differ from the system-wide policies are configured.

    Automatically generated enrollment patterns are named using the following conventions:

    • Templates with Friendly Name: FriendlyName (CommonName-ConfigurationTenant)
    • Templates without Friendly Name: TemplateName (CommonName-ConfigurationTenant)
  • Metadata defaults can be configured at both the template level and the enrollment pattern level. Values set at the enrollment pattern level take precedence. Values are set at both levels to support certificates that come into Keyfactor Command without connection to an enrollment pattern (e.g. manual certificate import).

  Known Issue:

  • When editing enrollment patterns, Keyfactor Command is not prompting the user to save unsaved changes. This will be fixed in Keyfactor Command version 25.1.1.

• ODKG - On Device Key Generation

  Reenrollment has been renamed ODKG (On-Device Key Generation) throughout the Keyfactor Command Management Portal and a new option of ODKG has been added to the enrollment menu.

  • The new ODKG page is similar to the CSR/PFX pages except the only delivery option is Include Certificate Store. Only one certificate store can be selected per request.

  • The reenrollment action button on the certificate stores grid has been renamed ODKG and now opens the new ODKG enrollment page when clicked.

  • API An API is 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. changes include:

  • Submitting a request from the ODKG page in the Management Portal will send it to POST /CertificateStores/Reenrollment, which has been updated to include optional fields for SANs, metadata, owner role, and additional enrollment fields.

  • A new query parameter A parameter or argument is a value that is passed into a function in an application. is available for the GET /CertificateStores API endpoint An endpoint is a URL that enables the API to gain access to resources on a server. (ODKGSupported), which filters certificate stores that support ODKG.

• Automated Certificate Cleanup

  The certificate cleanup task periodically removes expired certificates from the database. Once removed, these certificates will not be re-imported during a standard CA synchronization unless certificate cleanup is later disabled. CA synchronization tasks use the certificate cleanup settings to determine whether a certificate is eligible for cleanup and exclude such certificates from import.

  Certificate cleanup settings can be configured at three levels:

  • Certificate Template Record: If configured, overrides the system-wide settings when processing certificate cleanup tasks for certificates associated with this template. These cleanup tasks are processed first.

  • Certificate Authority (CA) Record: If configured, overrides the system-wide settings when processing certificate cleanup tasks for certificates associated with this CA but not associated with any template. These cleanup tasks are processed second.

  • System-Wide: Applies to all certificate authorities and templates in the system. These values are used when processing certificate cleanup tasks for certificates associated with neither a CA nor a template and when no overrides are set at the CA or template level. These cleanup tasks are processed last.

    Note:  For manually imported certificates without an associated template (e.g., from a standalone CA), system-wide cleanup settings will be applied even if the CA exists in Keyfactor Command. This occurs because Keyfactor Command cannot reliably associate such certificates with the correct CA.
  Important:  If a certificate with a stored 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. is deleted and later restored, the stored private key will not be restored.
  Note:  The system-wide settings for certificate cleanup are configured in application settings (see Application Settings: Console Tab).

Changes & Improvements

• Application Settings

  • A new Certificate Cleanup section has been added to the Console tab containing these settings:

    • Certificate Cleanup Enabled: Enable the periodic cleanup job to remove expired certificates from the database. The default is disabled.

    • Time After Expiration: The amount of time after expiration to wait until the certificate is eligible for removal. The default is 24.

    • Time After Expiration Units: The time unit to apply to the expiration time. Options are days, weeks, or months. The default is months.

    • Include Certificates with Archived Key in Cleanup: Determines whether certificates with a private key stored in the system are eligible for removal. The default is disabled.

• Certificate Authorities

  • On the CA configuration Advanced tab, the following changes have been made:

    • The Enable PFX Enrollment and Enable CSR Enrollment toggles have been removed.

    • The Restrict Allowed Requesters toggle and associated Allowed Requester Security Roles section have been removed.

    • A new Use for Enrollment toggle has been added.

      On upgrades, the Use for Enrollment toggle will automatically be enabled for any CAs that previously had either Enable PFX Enrollment or Enable CSR Enrollment enabled.

  • On the CA configuration Standalone tab, the following fields have been added:

    • Enable PFX Enrollment

    • Enable CSR Enrollment

    • Restrict Allowed Requesters

    These are configured here because standalone CAs do not use enrollment patterns.

• Certificate Metadata

  • Now metadata type - email accepts multiple emails at a time via a new text area for data entry. Email address may be separated by commas or semicolons on the same line. This eliminates the need to open, save and close the email recipient dialog multiple times.

• Certificate Search and Collections

  • The Key Type The key type identifies the type of key to create when creating a symmetric or asymmetric key. It references the signing algorithm and often key size (e.g. AES-256, RSA-2048, Ed25519). and Alt Key Type query fields were removed from Certificate Search (but existing collections queries will still work), replaced with Key Algorithm and Alt Key Algorithm fields.
  • The following new query fields have been added to certificate search:
    • AltKeyAlgorithm (see previous bullet)
    • CertificateAuthorityId
    • KeyAlgorithm (see previous bullet)
    • TemplateId
  • The Key Size The key size or key length is the number of bits in a key used by a cryptographic algorithm. and Key Type columns of the certificate search grid were replaced with the Key Algorithm column which holds the key algorithm and OID Object identifiers or OIDs are a standardized system for identifying any object, concept, or "thing" with a globally unambiguous persistent name. in the format Friendly Name (OID).
  • The Certificate Details dialog now includes the Key Algorithm and Alternative Key Algorithm fields rather than the Key Type and Alternative Key Type fields on the Content tab.
  • The Status tab of the Certificate Details dialog now includes the Enrollment Pattern Id and the Enrollment Pattern Name.

• Certificate Stores and Certificate Store Types

  • Alias Field Search Select: The Alias field is a search-select entry type. The dropdown lists all aliases associated with the selected certificate store.If an alias appears in multiple certificate stores, the number of locations is shown in parentheses next to the alias name. This indicator does not appear if the alias exists in only one selected store.Users can enter a new alias as long as Custom Aliases are not forbidden on the certificate store type Certificate Store Types.If you select an existing alias without checking Overwrite, the Save will fail and the certificate store(s) in which that alias already exists will be listed.See also this same text in AddtoCertStore_PFXEnrollment.flsnp and InfoRequiredByCertStore.flsnp, which couldn’t handle it as a snippet due to nested conditions. These can be re-updated to use the snippet once ODKG supports overwrite on the alias.

• Certificate Templates and Enrollment Patterns

  • The system-wide setting configurations have been removed from the templates page and added on the enrollment patterns page.

  • On the certificate template Details tab, the following changes have been made:

    • The CSR Enrollment, PFX Enrollment, and CSR Generation toggles have been removed. These have moved to enrollment patterns.

    • Settings for certificate cleanup have been added (see Certificate Templates - Details Tab).

  • The Enrollment Fields, Authorization Methods, Enrollment RegExes, Enrollment Defaults, and Polices tab have been removed. These have moved to enrollment patterns.

• Dashboard and Reports

  • The Location column on the Revocation Monitoring dashboard panel is now truncated to prevent the panel from being excessively wide or generating a horizontal scrollbar. Hover your mouse over the field to see the full value.

  • Scheduled reports configured for CSV or Excel format that generate no data now will not email an empty report. Instead, they will now deliver an email message that states that no data was found for the report with the provided parameters and therefore the requested report was not attached. This behavior change affects the following reports:

    • Expiration Report
    • Certificates Found At TLS TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer) are protocols for establishing authenticated and encrypted links between networked computers./SSL TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer) are protocols for establishing authenticated and encrypted links between networked computers. Endpoints
    • Certificates In 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).
    • Expiration Report By Days
    • Full Certificate Extract
    • SSH The SSH (secure shell) protocol provides for secure connections between computers. It provides several options for authentication, including public key, and protects the communications with strong encryption. Keys By Age
    • SSH Keys With Root Logon Access
    • SSH Key Usage Report
    • SSH Trusted Public Keys With No Known Private Keys

    Scheduled reports configured for PDF format that generate no data will still email an empty report.

  • The Certificates in Collection report includes a new Include SANs checkbox that, if checked, includes two new columns containing SAN data at the end of the report. The first, named SANs, is a list of all of the 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. data for that certificate, shown in a comma separated list. The second, called Total SANs, shows the total number of SAN values on the certificate. Leaving it unchecked leaves those columns off the report. The default is checked.
  • The certificate collection selection dropdown for reports has been updated to a search select field to support a larger number of possible certificate collections. To narrow the list of results in the search select field, begin typing a search string in the search field.

  • Reports now allow for emails to be sent to multiple recipients where each recipient has visibility of all recipients included in the email.

  • The Logi package used for the dashboard and report features has been updated to version v24.4 to resolve a vulnerability discovered in an earlier version of the package.

• Enrollment

  • Throughout the product and documentation, the term re-enrollment has been renamed to ODKG (on-device key generation).

• Helm

  • Volume mounts for container installations of Keyfactor Command can now be done on a per-deployment basis by entering the volume and volumeMounts information in the appropriate appConfig section. For examples, see Keyfactor Command Configuration Files.

• Installation and Configuration

  • In the configuration wizard, on the top section of the Database tab, there is a new checkbox, Use SQL Always-On, which appends MultiSubnetFailover=True to the connection strings template for the configured installation.

• Keys

  • In order to move to supporting the NIST standardized OIDs for Post-Quantum algorithms, the following algorithms have switched their underlying OIDs: ML-DSA-44 A variant of the Digital Signature Algorithm (DSA) designed for high-performance and secure digital signatures. ML-DSA-44 is optimized for specific machine learning use cases or specialized systems. now uses 2.16.840.1.101.3.4.3.17, ML-DSA-65 Similar to ML-DSA-44, this variant provides a larger key size and is suited for environments requiring more robust security. It is often used in cases where cryptographic strength needs to be balanced with performance. now uses 2.16.840.1.101.3.4.3.18, ML-DSA-87 An even stronger variant of ML-DSA, offering a larger key size and enhanced security features for demanding cryptographic operations. Like the others in the ML-DSA family, it is designed for specific use cases that require high-performance cryptography. now uses 2.16.840.1.101.3.4.3.19. Any previous Dilithium algorithms are not supported.

• Keyfactor Universal Orchestrator

  • Installations on Windows now only support SecureString input for the following values: -ClientCertificatePassword, -ClientSecret

• Licensing

  • The Actioned Certificates license model is introduced in this version. If your Keyfactor Command license enables the Actioned Certificates feature and your Actioned Certificates license type is not Site-License, the number of certificates that are deemed to be actioned are counted each night and these totals can be viewed on the Actioned Certificates tab of the licensing page. The license contains a maximum number of actioned certificates, though exceeding the count does not hamper functionality. The Keyfactor Command license and actioned certificate counts can also be downloaded to a file for review. For more information, see Licensing.

• Logging and Auditing

  • The information message logged to the audit log on user login or log out to the Keyfactor Command Management Portal now includes the authentication provider’s display name.

• PAM

  • SMTP supports PAM secrets for username and password.

  • PAM Providers LocalDB Provider Type has been renamed to Command Secret Provider.

  • PAM providers and provider types can now be configured in the Helm values file for container installs of Keyfactor Command.

  • Values for client credentials in the Helm values file for container installs of Keyfactor Command can now be set using PAM.

• Security Roles and Claims

  • Active Directory security claims can now be created in Keyfactor Command instances using OAuth identity providers if Active Directory is available in the environment. An Active Directory identity provider does not need to be created for this purpose.

• SQL Server

  • A Use SQL Always-On checkbox has been added to the Database tab of the Configuration wizard. This option automatically appends MultiSubnetFailover=True to the connection string template. This setting ensures faster and more reliable failover in environments using multiple SQL listener nodes (such as primary and secondary). In the event of a failure on the primary SQL node, this feature enables a seamless failover experience, allowing the connection to quickly switch to the secondary node. For more information, see High Availability.

  • Fortanix application-level encryption now caches the authentication token to improve performance.

• Workflow and Alerts

  • Workflow A workflow is a series of steps necessary to complete a process. In Keyfactor Command, it refers to the workflow builder, which allows you to automate event-driven tasks such as when a certificate is requested, revoked or found in a certificate store. and alerts now allow for emails to be sent to multiple recipients where each recipient has visibility of all recipients included in the email.

  • The Workflow Step Renew Expired Certificates can now push the certificate to the appropriate certificate stores. There is now a toggle on the Renew Expired Certificates workflow step that enables the functionality, or disables it. The default is enabled/true.

  • The Use Custom PowerShell workflow step and PowerShell handler for the legacy alerting system are not supported when running in containers under Kubernetes to eliminate any risk of cross-container script execution. Customers migrating from Windows installations to container installations, please see Preparing - Release 25.2 or Later.

  • Workflows that use a certificate template as the key (e.g. enrollment) now also accept an enrollment pattern as a subkey.

Fixes

• Uploading a PFX or p12 that exists in Keyfactor Command and has metadata values other than the defaults now causes those metadata values to be populated.

• The issued certificate request alerts grid now correctly shows the template display name rather than the template short name in the template display name column.

• On certificate renewal using the configure option for a certificate with SANs, the SANs are no longer cleared on selecting a new template.

• On upgrade from versions of Keyfactor Command prior to 12.0, SAN email template defaults and regular expressions defined as MAIL will seamlessly become fields defined as EMAIL and will not lose the configurations.

• The batch size numbers reported in the log during a certificate cleanup job are now accurate batch figures instead of a countdown.
• PAM secrets used to store SMTP Short for simple mail transfer protocol, SMTP is a protocol for sending email messages between servers. secrets can no longer be deleted if they are in use.
• If PAM is used to store secrets for CA authentication with OAuth when switching from certificate authentication, the PAM secret is now successfully associated with the CA record.
• Certificates issued from EJBCA CAs can now successfully be revoked using instances of Keyfactor Command running in containers under Kubernetes.
• The /CertificateStores/Reenrollment API endpoint now correctly honors the CA Use for Enrollment flag.
• Obscure error messages generated in PFX and CSR enrollment when the entered value in a Big Text metadata field exceeded the allowed length of 4000 characters have been updated to provide useful feedback indicating the nature of the issue.
• Attempts to save a CA record with the same 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). and configuration tenant A grouping of CAs. The Microsoft concept of forests is not used in EJBCA so to accommodate the new EJBCA functionality, and to avoid confusion, the term forest needed to be renamed. The new name is configuration tenant. For EJBCA, there would be one configuration tenant per EJBCA server install. For Microsoft, there would be one per forest. Note that configuration tenants cannot be mixed, so Microsoft and EJBCA cannot exist on the same configuration tenant. but using a different case no longer generate a generic or 500 error. Instead, a message is returned to the user indicating the record already exists.
• The default value of the PushToCertStore configuration parameter of the ExpirationRenewal workflow step type when submitted using the PUT /Workflow/Definitions/{definitionid}/Steps API endpoint now correctly sets to a Boolean true rather than a string “true”.

Deprecation & Removals

• The license for the Logi Analytics Platform, used by the Keyfactor Command dashboard and reports, will expire on November 28, 2027 and will not be renewed. Customers who have not upgraded to Keyfactor Command 25.3 or later by that date will no longer be able to use the dashboard or reports.

Known Issues

• The PermissionSetId in /IdentityProviders/ endpoint responses is shown inconsistently for different verbs. For PUT it is not among the response parameters. For GET and POST it is among the response parameters. This will be corrected in a future release.

• A workflow with a step of type Send Email generates an unhelpful error if the email address resolves to null. This will be corrected in a future release.

• The ML-DSA information in Logi reports may be slightly incorrect due to the differences between new and old OIDs because the following algorithms have switched their underlying OIDs: ML-DSA-44, ML-DSA-65, ML-DSA-87. Reports will be updated in a future release.

• An incomplete error message is sent when Test SMTP Fails. This seems to be a known issue on Google’s side. The page link that is missing in some messages should be: https://support.google.com/a/answer/3726730?hl=en.

• On a PFX enrollment where Include Chain is selected, if the certificate chain cannot successfully be built, an error message pops up indicating a chain building error. However, the certificate is still issued. Because of the error message format, users may think that the certificate was not issued. This will be clarified in a future release.

  Note:  In order for chain certificates to be included with end entity certificates for download, one of the following must be true:

  • All certificates in the chain must be in the Keyfactor Command database.

  • Each certificate in the chain must include an AIA The authority information access (AIA) is included in a certificate--if configured--and identifies a location from which the chain certificates for that certificate may be retrieved. (Authority Information Access The authority information access (AIA) is included in a certificate--if configured--and identifies a location from which the chain certificates for that certificate may be retrieved.) extension with an HTTP or HTTPS URL pointing to the issuer's certificate. These certificates must be accessible from the Keyfactor Command server. Only HTTP and HTTPS URLs are supported.

  • All certificates in the chain must be present in the Keyfactor Command server's local machine Trusted Root Certification Authorities and Intermediate Certification Authorities stores (Windows installations only).

• If a certificate store inventory is performed and a certificate is found (not in the database) and the template of the certificate does not have a default enrollment pattern, the certificate will be imported but will not be associated to the certificate store. The workaround is to perform a second inventory and this will tie the certificate to the store. This will be fixed in version 25.2.

• Searches for workflow instances using the InitiatingUserName query parser fail with an “invalid column name” error. This will be corrected in a future release.

• Searches for workflow instances using the InitiatingUserName query parser fail with an “invalid column name” error. This will be corrected in a future release.

API Endpoint Change Log

Please review the information in the API Change Log for this release carefully if you have implemented any integration using these endpoints: API Change Log v25.1.1.