Release Notes

Keyfactor announces the AnyCAGateway REST 25.1. Only those releases with documentation updates are included in the Release Notes section.

AnyCAGateway REST v25.1 (March 2025)
AnyCAGateway REST v24.4 (December 2024)
  • Update: The AnyCAGateway REST now offers container installation under Kubernetes using a Helm chart as an installation option. This can be supported either in a local Kubernetes cluster or a cloud-based cluster. When implemented as a container installation, the AnyCAGateway REST is made up of two containers (one short-lived) using a Microsoft SQL backend database.

  • Update: All of the configuration files have been consolidated into the Configuration directory. The appsettings.json file and nlog.config file are now in the AnyGateway REST configuration directory. The config.json file has been removed and its configuration values have been moved to the appsettings.json file.

  • Update: IdPs are now stored in the database. These have been removed from the appsettings.json file. All OAuth IdP and SuperAdmin information have moved from the config.json file to the database. All Claims (including SuperAdmin) are now stored in the database.

  • Update: The new default value for the RSA field on the Add New Certificate Profile dialog has been changed from 1024 to 2048.

  • Update: The following OAuth parameters are required by both the Database Management Console application and the AnyCAGatewayInstall.ps1 install script when adding/updating an IdP, and will be validated against the URIs in the Discovery Document: Authorization Endpoint, Token Endpoint, User Info Endpoint (optional, required if contained in discovery doc), JSONWebKeySet URI.

  • Update: Similar to the functionality of Keyfactor Command, the AnyCAGateway REST makes use of an IdP hint in the portal URL to specify which IdP to redirect to, if you want to point to a different provider than the default provider identified in the new DefaultIdentityProviderAuthScheme parameter in the appsetting.json file and installation script.

  • Update: The installation and operation of the AnyCAGateway REST now requires .NET 8 to be installed. The AnyCAGateway REST integrates .NET data protection in the application.

  • Update: The AnyCAGateway REST Claims Management now allows for multi-IdP claim management. Additional providers may be added post-installation via new API endpoints.

  • Update: A Logout button is added to the navigation bar. The logout button is only displayed for OAuth configurations and when the user is authenticated.

    Note:  The Auth0 application will need to have the correct Logout url configured; the logout url is configured under the Auth0 Application > Settings > Allowed Logout URLs. The Logout URL is formatted as: https://{FQDN}/Login/Signin, case-sensitive.

  • Update: During an upgrade, all existing client certificate auth claims will be updated to include a default Client Cert Auth Provider . All existing OAuth claims (from 24.2) are updated to include the OAuth Provider Provider added during the installation process. If not provided during the installation process, existing OAuth claims will be assigned Legacy Unassociated Claims (OAuth) until an IdP provider is added via the API endpoints.

  • Update: The Database Management Console application now runs via the AnyCAGatewayInstall.ps1 during installation. The dbconfig.json file has been removed from the delivered and installed directories. The application will determine whether or not the database exists, or is empty, and determine the appropriate action during installation.

  • Known Issue: AnyCAGateway REST and Keyfactor Command now accept SANs via ExtensionData. Pre-24.4 AnyCAGateway REST deployments are not compatible with Keyfactor Command v24.4 regarding the method of handling large 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. enrollments.

  • Known Issue: Logging for gateway installations in containers under Kubernetes does not output correctly to the Kubernetes standard out. This will be corrected in a future release. In the meantime, you can work around this issue by configuring a custom nlog.config using a config map or persistent volume (see Logs).

AnyCAGateway REST v24.2 (June 2024)

  • Update: The Extensions folder is preserved during upgrades. All existing extensions and files located in the install destination's Extensions folder will be preserved unless a file or folder with the same name exists in the Extensions folder located at the source. This directory is located by default here:

    C:\Program Files\Keyfactor\Keyfactor AnyCA Gateway\AnyGatewayREST\net6.0\Extensions

    This can be useful behavior to invoke, especially with regard to the manifest.json file, ensuring the older version of the file no longer exists after an upgrade to prevent unintended behaviors, when the manifest.json file from the source will overwrite the existing manifest.json file at the destination. This can be useful for upgrading an existing extension without going into the install location and manually deleting/modifying the files.

  • Update: The gateway now supports OAuth 2.0 OpenID Connect (OIDC) as an authentication option. Client certificate authentication is also still supported. Only one authentication method is supported at a time for a given instance of the AnyCAGateway REST.

  • Update: A new parameter for both the Database Management Console (DatabaseManagementConsole.exe) and the gateway installation PowerShell script has been introduced that allows users to provide additional connection string settings to use when building the SQL connection string. One possible use of this option is to pass in the following connection string addition to disable the requirement for the gateway to make the connection to the SQL server over a TLS channel, which eliminates the need for an SSLClosed TLS (Transport Layer Security) and its predecessor SSL (Secure Sockets Layer) are protocols for establishing authenticated and encrypted links between networked computers. certificate to be installed on SQL:

    Encrypt=false

    The option must be specified whenever you are communicating with SQL—both when creating (or populating or updating) the database (the connectionstringtemplate parameter) and when installing the gateway (the -ConnectionStringTemplate parameter). See -Connection String Template.

  • Update: Certificate requests with an external validation status now return free-form data provided by the CA in the enrollment response to Keyfactor Command. This data is placed in a workflowClosed 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. data bucket field called EnrollmentContext, which is a dictionary of the returned data. In the Keyfactor Command enrollment workflow the returned data can then be accessed and manipulated as needed using other workflow steps.

  • Update: The comments have been removed from the default config.json and dbConfig.json files to reduce conflicts with tools that might be used to manage these files.

  • Update: The Extensions folder is now preserved on upgrades (see Upgrade the AnyCAGateway REST to a New Version).

  • Fix: Under certain circumstances, when the gateway synchronized certificates from the CA to the gateway database with the same CARequestID but with a different certificate on subsequent syncs (in the case of a renewed certificate, for example), the original certificate was overwritten in the gateway database with the new certificate. This has been corrected. If a different certificate with the same CARequestID is found on synchronization, it will not be synchronized. The original certificate will be retained. The following message will be logged:

    CA sync returned a certificate with thumbprint <NewThumbprint> for record <CARequestID>. The gateway database already has a certificate with thumbprint <OldThumbprint> for record <CARequestID>. The existing certificate will be preserved.

  • Fix: The gateway install has reduced the number of incidences of the following warning on install when the -ServiceCredential parameter is used:

    WARNING: Failed to grant Log on as a Service permission to user [your service account name].

  • Fix: Certificate profiles can now be created with a name that is only one character long.

AnyCAGateway REST v24.1 (February 2024)
Important:   There is an issue where the contents of the Extensions folder (IAnyCAPlugin dlls, manifest.json file, etc...) will be overwritten when upgrading from AnyCAGateway REST v23.1 to AnyCAGateway REST v24.1. This will be addressed in a future release. Keyfactor recommends that you preserve the contents of the Extensions folder by copying it to another location prior to upgrading.

  • Update: This guide includes instructions on hosting the AnyCAGateway REST using IIS in the IIS Hosting section.

  • Update: The AnyCAGateway REST now supports the ability to age out certificates. On the Certificate Authorities page, there is a new Certificate Pruning option (see The Basic Tab). There are three options for configuring pruning: Disabled, FromIssuance, and FromExpiration.

  • Update: The AnyCAGateway REST v24.1 now supports exactly one authentication CA provider for client certificate authentication, so the Provider option has been removed from the product. In the previous release the number of authentication CAs providers was not limited.

  • Update: The AnyCAGateway RESTv24.1 added log Info-level messages when it starts up that contain additional information about the implementation. Also, CA Sync error handling has been improved (see Troubleshooting, Services, and Logs).

AnyCAGateway REST v23.1 (November 2023)

  • Initial release

Note:   There are now two formats of the AnyCA Gateway (DCOM and REST). While it is the intention to deprecate the DCOM format eventually, for a brief period, both versions will be released. This complicates the upgrade process, in terms of determining whether a given gateway install can or cannot be upgraded to a particular destination version. A matrix with the upgrade compatibility is included in the Upgrade Introduction section (see Upgrading).