Keyfactor EJBCA CA Integration for SSH

This guide provides general information on how to add an existing Keyfactor EJBCA certificate authority (CA) as a third-party CA to StrongDM. Using a Keyfactor EJBCA CA allows certificate-based SSH resources to authenticate with certificates issued by Keyfactor EJBCA, instead of the default Strong CA managed by StrongDM.

Prerequisites #

Before you begin, ensure that the following requirements are met.

• Have the Administrator permission level in StrongDM.
• Have a running Keyfactor instance that is accessible by a StrongDM node (gateway or relay).
• The REST SSH V1 API endpoint must be enabled (to allow the REST API client to communicate with Keyfactor).
• The client certificate file, key, and CA file must be accessible.
• Know the hostname of the KeyFactor CA.
• The CA’s certificate file must be deployed to the target SSH servers.

Keyfactor Configuration Considerations #

StrongDM doesn’t manage or configure third-party CAs. It is up to you to configure Keyfactor appropriately for your organization, as well as to ensure that the appropriate CA is trusted by the target resources.

This section briefly describes the most important parts of Keyfactor EJBCA setup to consider when integrating a CA with StrongDM.

End Entity Profile settings #

In Keyfactor, under Main Certificate Data, ensure that your End Entity Profile is configured to use an SSH Certificate Profile. If not configured with an SSH-type Certificate Profile, your End Entity configuration may not be compatible with SSH.

The minimum requirement for your End Entity Profile configuration is to have at least two modifiable principal slots in the SSH Certificate Data fields.

However, we recommend that you lock down the profile by using the following kind of profile configuration:

• Have two principal slots total.
• The first principal slot must be filled with strongdm, must be set as required, and cannot modifiable. Adding this principal ensures that the CA is issued by the StrongDM Control Plane.
• The second principal is blank (no name), required, and modifiable. This principal is left empty and able to be modified because it will be filled by a Remote Identity username later, if your SSH resource is configured to use Remote Identities.

Certificate requests #

For certificate signing, StrongDM generates a certificate request containing the public key of the key pair. The request is submitted to Keyfactor for signing. The resulting signed certificate is then used, along with the private key, to authenticate to the target resource. The private key never leaves the gateway or relay where it was created.

Add Keyfactor EJBCA CA in the Admin UI #

To add a Keyfactor EJBCA CA for SSH in the Admin UI, follow these steps.

1. From the Settings > Credentials Management page in the Certificate Authorities tab, click Add certificate authority.
2. Enter the Name for the CA (any name).
3. For Type, select Keyfactor EJBCA SSH.
4. The form updates with other CA properties. Complete all required properties.
5. Click Create certificate authority.

Keyfactor EJBCA SSH CA properties #

Add the Keyfactor EJBCA SSH CA to a Certificate-Based SSH Server #

1. If you have not already done so, follow the instructions to add an SSH server with certificate authentication.
2. On the resource form, pay particular attention to the Certificate Authority property. For this property, select the newly added Keyfactor EJBCA SSH CA.
3. Complete all required fields and save.
4. Test the connection to the resource (for example, use sdm ssh in the CLI to connect).

Manage the CA #

After you have added the Keyfactor EJBCA CA and set a certificate-based server to use it, you may manage the CA and review its settings on the Certificate Authorities tab of the Settings > Credentials Management page in the Admin UI. You may select the CA from the list or click its Details button to view diagnostics, update its settings, or delete the CA configuration.

The Diagnostics tab shows all the nodes (gateways and relays) that are configured to access the CA, as well as health information for the nodes.

If the CA is unable to be accessed by any gateway or relay, please review the CA’s Settings tab and make sure the CA credentials are correct.

Additional Information #

Third-party CAs also may be added and managed in the CLI, SDKs, and Terraform. Note that third-party CAs are treated like secret stores in the CLI, SDKs, and Terraform. As such, they use secret store commands, domain objects, and resources.

Add CA in the CLI #

To add the Keyfactor EJBCA CA for SSH in the CLI instead of the Admin UI, use the sdm admin secretstores create CLI command. Create your “secret store” by choosing keyfactorSSH as the secret store type.

sdm admin secretstores create keyfactorSSH

In the CLI, the options are the same as the Keyfactor EJBCA SSH CA properties set in the Admin UI.

CLI example #

# Create Keyfactor EJBCA CA for SSH
sdm admin secretstores create keyfactorSSH
--ca-file-path="/Users/alice/dev/ejbca/ec2-12-345-678-910-us-east-2-compute-amazonaws-com.pem"
--certificate-file-path="/Users/alice/dev/ejbca/admin.pem"
--default-certificate-authority-name="ManagementCA"
--default-certificate-profile-name="SSH_CERT"
--default-end-entity-profile-name="SSH_RELAY"
--enrollment-code-env-var="KF_ENROLL_CODE"
--enrollment-username-env-var="KF_USERNAME"
--key-file-path="/Users/alice/dev/ejbca/admin.key"
--name="Keyfactor CA"
--server-address="ec2-12-345-678-910-us-east-2-compute-amazonaws.com"

# Create SSH (Certificate Based) server
sdm admin servers create ssh-cert
--name="Example SSH Keyfactor"
--hostname="https://host.example.com:1234"
--secret-store-id="se-e1b2"
--username="username"

# Run secret store healthcheck
sdm admin secretstores healthcheck se-e1b2

# Check that the secret store is reachable
sdm admin secretstores status

# Check the connection to the resource
sdm connect "Example Keyfactor CA"

Add Keyfactor EJBCA SSH CA in Terraform #

In addition to using the Admin UI and CLI, you may use Terraform to add a Keyfactor EJBCA CA for use with certificate-based SSH servers. This section includes a Terraform example.

For additional information, see our Terraform provider documentation.

Terraform example #

# Install StrongDM provider
terraform {
  required_providers {
    sdm = {
      source  = "strongdm/sdm"
      version = "7.1.1"
    }
  }
}

# Configure StrongDM provider
provider "sdm" {
    # Add API access key and secret key from Admin UI
    api_access_key = "njjSn...5hM"
    api_secret_key = "ziG...="
}

variable "prefix" {
  type = string
  default = "example-tf-"
}

# Create Keyfactor EJBCA CA for SSH
resource "sdm_secret_store" "example-tf-ssh-ca" {
  keyfactor_x_509_store {
    name = "${var.prefix}ssh-ca"
    ca-file-path = "/Users/alice/dev/ejbca/ec2-12-345-678-910-us-east-2-compute-amazonaws-com.pem"
    certificate-file-path = "/Users/alice/dev/ejbca/admin.pem"
    default-certificate-authority-name = "ManagementCA"
    default-certificate-profile-name = "SSH_CERT"
    default-end-entity-profile-name = "SSH_RELAY"
    enrollment-code-env-var = "KF_ENROLL_CODE"
    enrollment-username-env-var = "KF_USERNAME"
    key-file-path = "/Users/alice/dev/ejbca/admin.key"
    name = "example-ca-name"
    server-address = "ec2-12-345-678-910-us-east-2-compute-amazonaws.com"
  }
}

# Create SSH (Certificate Based) server
resource "sdm_resource" "example-ssh-cert-based" {
  ssh {
    name = "${var.prefix}ssh-keyfactor-ca"
    hostname = "https://keyfactor.example.com:1234"
    secret_store_id = sdm_secret_store.example-tf-ssh-ca.id
    username = "username"
  }
}

Add Keyfactor EJBCA CA for SSH with the SDKs #

To add a Keyfactor EJBCA CA for SSH with the StrongDM SDKs, please see the SDKs on GitHub:

• Go
• Java
• Python
• Ruby