# Keyfactor EJBCA CA Integration for SSH {% hint style="info" %} This feature is part of the Enterprise plan. If it is not enabled for your organization, please contact StrongDM at the [StrongDM Help Center](https://help.strongdm.com/hc/en-us). {% endhint %} 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](https://docs.strongdm.com/admin/resources/servers/ssh-certificate-auth). ### 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 [Identity Aliases](https://docs.strongdm.com/admin/principals/identity-alias). #### 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** > **Secrets 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](#keyfactor-ejbca-ssh-ca-properties). Complete all required properties. 5. Click **Create certificate authority**. #### Keyfactor EJBCA SSH CA properties {% hint style="info" %} Some of the properties (**Certificate File Path**, **Key File Path**, and **CA File Path**) are obtained in the same way as for the X.509 (RDP) version of this CA. If you have those files for the Keyfactor EJBCA RDP CA, you can also use them for the SSH CA, as long as your client certificates grant permission to issue them for this CA. {% endhint %} | Property | Requirement | Description | | -------------------------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Server Address** | Required | Host address of the Keyfactor CA (for example, `http://example.com`) | | **Certificate File Path** | Required | Path to the Keyfactor client certificate in PEM format (for example, `/path/to/certificate/admin.pem`); the certificate must contain a client certificate that is recognized by the EJBCA instance represented by the hostname; the PEM file may also contain the private key associated with the certificate, but the key file also can be set to configure the private key | | **Key File Path** | Optional | Path to the private key in PEM format (for example, `/path/to/key/admin.key`); the file should contain the private key associated with the client certificate configured in the certificate file | | **CA File Path** | Optional | File path to the Keyfactor CA's root CA/public certificate in PEM format (for example, `/path/to/ca/example.com.pem`); not required if the CA is trusted by the host operating system | | **Certificate Profile Name** | Required | Certificate profile name that EJBCA uses to enroll the CSR (for example, `SSH_CERT`) | | **End Entity Profile Name** | Required | End entity profile that EJBCA uses to enroll the CSR (for example, `SSH_RELAY`) | | **Certificate Authority Name** | Required | Name of the EJBCA CA that enrolls the CSR (for example, `ManagementCA`) | | **Enrollment Username Environment Variable** | Optional | Environment variable for the username that is used by EJBCA during enrollment (for example, `KF_ENROLL_USERNAME`); if not specified, the username must be auto-generated on the Keyfactor side | | **Enrollment Code Environment Variable** | Optional | Code used by EJBCA during enrollment (for example, `KF_ENROLL_CODE`); may be left blank if no code is required | ### 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](https://docs.strongdm.com/admin/resources/servers/ssh-certificate-auth). 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** > **Secrets 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. {% hint style="info" %} Deletion removes the CA configuration from StrongDM only, not from Keyfactor. {% endhint %} 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. {% hint style="warning" %} Every healthcheck for certificate-based resources configured to use a third-party CA generates a certificate with the CA provider. {% endhint %} ### 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. {% hint style="info" %} Activities related to third-party CAs are logged in the same way as secret store activities. For example, adding a third-party SSH CA in Terraform produces an activity similar to `API Account example-terraform-key (cc1e23eb-e456-7891-23c4-edf5678c9123) created a secret store named example-tf-ssh-ca`. {% endhint %} ### 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](https://app.gitbook.com/s/4XOJmXFslCMVCzIG2rKp/cli/admin/secretstores/create) CLI command. Create your "secret store" by choosing `keyfactorSSH` as the secret store type. ```sh sdm admin secretstores create keyfactorSSH ``` In the CLI, the options are the same as the [Keyfactor EJBCA SSH CA properties](#keyfactor-ejbca-ssh-ca-properties) set in the Admin UI. #### CLI example ```sh # 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](https://registry.terraform.io/providers/strongdm/sdm/latest/docs) documentation. #### Terraform example ```tf # 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](https://github.com/strongdm/strongdm-sdk-go) * [Java](https://github.com/strongdm/strongdm-sdk-java) * [Python](https://github.com/strongdm/strongdm-sdk-python) * [Ruby](https://github.com/strongdm/strongdm-sdk-ruby) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.strongdm.com/admin/access/certificate-authorities/ejbca-ca-ssh.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.