Configure AnyCAGateway REST Plugins

The AnyCAGateway REST uses a plugin-based architecture to extend its core functionality. Plugins allow the gateway to integrate with external systems and implement specialized logic—such as certificate authority A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA. (CA A certificate authority (CA) is an entity that issues digital certificates. Within Keyfactor Command, a CA may be a Microsoft CA or a Keyfactor gateway to a cloud-based or remote CA.) integrations or domain validation—without requiring changes to the gateway itself. Each plugin is installed and configured independently and is discovered by the gateway at runtime, allowing for flexible deployment and support for both customer-developed integrations and publicly available plugins.

About AnyCAGateway REST Plugins

Gateway plugins are external components that extend the capabilities of the AnyCAGateway REST without modifying the gateway core. Each plugin implements a defined interface, which allows functionality to be added, updated, or replaced independently of the gateway service.

The AnyCAGateway REST supports multiple plugin types, including:

CA plugins, which support integrations with third-party certificate authorities for operations 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)., renewal, and revocation.
Domain validation plugins, which perform domain control validation required for certificate issuance workflows.

Plugins may be developed by customers or sourced from publicly available integrations hosted by Keyfactor. Multiple plugins can be installed on the same gateway instance. Only one CA plugin can be active at a time, while multiple domain validation plugins are supported. Each plugin must be configured in its own directory and referenced correctly in its manifest.

Gateway plugins run in-process with the AnyCAGateway REST service and rely on the gateway for configuration, logging, and request handling. Plugins do not manage authentication, authorization, or network exposure independently. These concerns are handled by the gateway itself.

Plugin Architecture and Requirements

Plugins are discovered and loaded by the AnyCAGateway REST at service startup based on configuration provided in a manifest.json file. The manifest identifies the plugin type, the assembly to load, and the fully qualified type name that implements the required interface. During initialization, the gateway reads the manifest and loads the plugin into the gateway process.

Each plugin must meet the following requirements:

Implement the interface required for its plugin type, such as CA or domain validation.
Be referenced in a valid manifest.json file.
Be placed in a directory accessible to the gateway service.
Reside in its own directory and not share a directory with other plugins.

Plugins run in-process with the AnyCAGateway REST and execute within the context of the gateway service. Configuration, authentication, authorization, and request routing are handled by the gateway. Plugins receive only the data required to perform their specific function and return results to the gateway for further processing.

Plugins are loaded when the gateway service starts. Changes to plugin files or manifests require a gateway service restart to take effect.

Install Plugins on Windows

To install a plugin on Windows running under Kestrel or IIS:

Acquire the plugin artifact for the integration. Gateway integrations for common third-party gateways are publicly available in the Keyfactor GitHub:

CA Plugins: https://keyfactor.github.io/integrations-catalog/content/caplugin

Domain Validation Plugins: https://keyfactor.github.io/integrations-catalog/content/dns-plugin
Follow the instructions provided with the integration to install the plugin, which may include creating a folder, a manifest.json file, and copying the files to specific locations.

Tip: If you receive error messages in the logs that mention connector set up when accessing the portal, it means you have missed the step of installing a CA plugin.
2025-08-30 12:15:13.4538 Keyfactor.AnyGatewayCore.NoOpAnyCAPlugin [Warn] - The current AnyCAPlugin is a placeholder. Please configure a AnyCAPlugin in the manifest.json.
2025-08-30 12:15:13.4538 Keyfactor.AnyGatewayREST.Filters.APIExceptionFilter [Error] - Keyfactor encountered an error processing the request. Please view the server log for more detail. (Error Code: 0x80004001)
2025-08-30 12:15:13.4538 Keyfactor.AnyGatewayREST.Filters.APIExceptionFilter [Error] - The method or operation is not implemented.

Note: Most plugins are added in a plugin specific folder in the following directory with a manifest.json file placed in the same directory:

C:\Program Files\Keyfactor\Keyfactor AnyCA Gateway\AnyGatewayREST\Extensions

An OIDCEventProviders folder exists under the above directory containing a manifest.json file used for Auth0 functionality. Be sure not to disturb this directory.

Install Plugins in Containers (Kubernetes)

To install a plugin for container installations under Kubernetes:

C:\Program Files\Keyfactor\Keyfactor AnyCA Gateway\AnyGatewayREST\Extensions

An OIDCEventProviders folder exists under the above directory containing a manifest.json file used for Auth0 functionality. Be sure not to disturb this directory.

Acquire the plugin artifact for the integration. Gateway integrations for common third-party gateways are publicly available in the Keyfactor GitHub:

CA Plugins: https://keyfactor.github.io/integrations-catalog/content/caplugin

Domain Validation Plugins: https://keyfactor.github.io/integrations-catalog/content/dns-plugin

On your Kubernetes server, create a subdirectory under your working directory for the plugin and copy the manifest.json file for the plugin and the files referenced by the plugin to this directory. The following GoDaddy CA manifest.json file is provided as an example:

Copy

{
    "extensions": {
        "Keyfactor.AnyGateway.Extensions.IAnyCAPlugin": {
            "GoDaddyCAPlugin": {
                "assemblypath": "GoDaddyCAPlugin.dll",
                "TypeFullName": "Keyfactor.Extensions.CAPlugin.GoDaddy.GoDaddyCAPlugin"
            }
        }
    }
}

Create a PersistentVolume in Kubernetes to contain your manifest.json file, the dll it references, and any supporting files. The steps for this will vary depending on your Kubernetes implementation and the intended storage location used by your PersistentVolume.
Tip: You can create a PersistentVolume in the local file system for testing purposes as follows:
1. Create a directory that your PersistentVolume will reference and which will contain the files to be mounted via the persistent volume. For example:
  mkdir /opt/files/godaddy
2. Create a YAML file to define the PersistentVolume similar to the following:
```
apiVersion: v1
kind: PersistentVolume
metadata:
  name: godaddy-pv
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
accessModes:
  - ReadWriteOnce
hostPath:
  path: "/opt/files/godaddy"
```
3. Create the PersistentVolume based on the yaml file you created. For example:
  sudo kubectl apply --filename=/opt/files/godaddy-pv.yaml
  PersistentVolumes are cluster-scoped resources, meaning they are not associated with a specific Namespace.
4. Create a YAML file to define a PersistentVolumeClaim associated with the PersistentVolume similar to the following:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: godaddy-pvc
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
```
5. Create the PersistentVolumeClaim based on the yaml file you created. For example:
  sudo kubectl apply --filename=/opt/files/godaddy-pvc.yaml --namespace keyfactor-command
  Unlike PersistentVolumes, PersistentVolumeClaims are associated with a specific Namespace.
6. Place the files that should be mounted in the container into the directory you specified in the file system. For example:
  /opt/files/workflow/manifest.json
  /opt/files/workflow/GoDaddyCAPlugin.dll
  Note: Plugins and extensions may contain additional files not shown here.
Important: This operation should not be used for a production PersistentVolume.

Edit your values file to add a volume and volumeMount for the PersistentVolume containing the manifest.json file, DLL, and any supporting files. For example, the following values file section shows the example root trusts volume (see Install Keyfactor Command in Containers Under Kubernetes) and the ca-plugin-volume. Your PersistentVolumeClaim name should match the claimName referenced here.

volumes:
  - name: root-cas
    configMap:
      name: ca-roots
      items:
        - key: ca-certificates.crt
          path: ca-certificates.crt
  - name: ca-plugin-volume
    persistentVolumeClaim:
      claimName: godaddy-pvc
volumeMounts:
  - name: root-cas
    mountPath: /etc/pki/tls/certs/ca-bundle.crt   # Common CA bundle path for gateway containers
    subPath: ca-certificates.crt    # Source path for your CA bundle may vary
  - name: ca-plugin-volume
    mountPath: /app/Extensions/ca-plugin-godaddy

Load the new values, referencing the deployment name, Namespace, your customized values file, the Helm chart, and version. For example:

sudo helm upgrade Helm_Deployment_Name --namespace keyfactor-gateway --values values-local.yaml oci://repo.keyfactor.com/charts/command/anygateway-rest --version 1.0.1

Configure CA Plugins

CA plugins define how the AnyCAGateway REST integrates with a third-party certificate authority. Configuration settings for CA plugins are specific to the target CA and determine how the gateway performs operations such as certificate enrollment, renewal, and revocation.

CA plugin configuration is typically provided through plugin-specific configuration files or settings defined by the plugin implementation. Required settings and supported options vary by CA integration and are documented with the plugin itself.

Only one CA plugin can be active on a gateway instance at a time.

For configuration details, refer to the documentation provided with the CA plugin you are installing.

Configure Domain Validation Plugins

Domain validation plugins perform domain control validation as part of certificate issuance workflows. These plugins are used to verify ownership or control of domain names before a certificate request is approved.

Configuration for domain validation plugins is plugin-specific and defines the validation methods supported by the plugin, such as HTTP-based or DNS The Domain Name System is a service that translates names into IP addresses.-based validation. Multiple domain validation plugins can be configured on the same gateway instance, allowing different validation methods to be used as needed.

Domain validation plugin settings are defined by the plugin implementation and are documented with the plugin itself. The gateway uses the configured plugins to perform validation when domain validation is required by a certificate request.

Was this page helpful? Provide Feedback

Version v26.2.1

On This Page