# AWS CA Integration for RDP This guide provides general information on how to add an existing AWS certificate authority (CA) as a third-party CA to StrongDM. AWS CA integration allows certificate-based RDP resources to authenticate with certificates issued by AWS, instead of the default Strong CA managed by StrongDM. ### Prerequisites Before you begin, ensure that you have the following. * Administrator permission level in StrongDM * Running AWS Private CA instance that is accessible by a StrongDM gateway or relay * Familiarity using AWS Private CA * Certificate Revocation List (CRL) distribution activated and accessible by the Active Directory domain controller for the target AD deployment ### AWS Configuration Considerations StrongDM doesn't manage or configure third-party CAs. It is up to you to configure AWS 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 AWS setup to consider when integrating an AWS CA with StrongDM. #### CA setup * AWS Private CA can host multiple certificate authorities. * Either General-purpose or Short-lived CAs can be used. * Root or subordinate CAs may be used, as long as the public certificate for any CAs that are to be used are installed on AD. * RDP only works with RSA 2048 key pairs for the client certificate, but the CA can use any RSA- or ECDSA-based key type and signing algorithm. * A CRL must be activated. * Select **Activate CRL distribution**. CRL distribution must be activated for certificate authentication with Active Directory. #### IAM role The IAM role used for making certificate requests to AWS Private CA must have the following permissions: ```json { "Effect": "Allow", "Action": [ "acm-pca:IssueCertificate" ], "Resource": "arn:aws:acm-pca:*:*:certificate-authority/*", "Condition": { "StringLike": { "acm-pca:TemplateArn": [ "arn:aws:acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V*" ] } } } ``` The template does not have to be the same one in the example, but it must allow Certificate Signing Request (CSR) passthrough for the alternative name, key usage, and extended key usage fields. AWS requires that you select from a predefined list of templates. The ARN of each template may be found in [AWS documentation](https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html#BlankEndEntityCertificate_CSRPassthrough). Examples of allowed templates include: * `BlankEndEntityCertificate_CSRPassthrough/V1` * `BlankEndEntityCertificate_CriticalBasicConstraints_CSRPassthrough/V1` #### Certificate signing requests How does certificate signing work? StrongDM generates a key pair on the gateway or relay and generates a CSR signed by the private key. The CSR is submitted to AWS Private CA 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. ### Configure the Gateway or Relay With Credentials to Access AWS Private CA This section provides several options to authenticate your StrongDM gateway or relay server with AWS. The gateway or relay needs to be configured with the proper credentials to access the AWS Private CA. #### Option 1: Access keys via environment variables 1. [Get an access key for AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#Using_CreateAccessKey) and set the necessary environment variables on your gateway or relay server (`AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY`). 2. Edit the environment file. The default environment file location is `/etc/sysconfig/sdm-proxy` for gateways and relays, or `/etc/sysconfig/sdm-worker` for proxy clusters. 3. Add the following lines, substituting your ID and key: ``` AWS_ACCESS_KEY_ID=aswf234rt4rsag4t3g AWS_SECRET_ACCESS_KEY=23452321h2893hf2ioufh2938229fh2oufgh23890fh29fh23bif2f0928hf02f3n2bf290fn9230f ``` 4. Restart the service. If your system uses systemd, the command will be `sudo systemctl restart sdm-proxy` for gateways and relays, or `sudo systemctl restart sdm-worker` for proxy clusters. #### Option 2: IAM via EC2 role {% hint style="info" %} The IAM role that is used to authenticate and derive access keys must have the permissions outlined in the [IAM role](#iam-role) section of this guide. {% endhint %} 1. In your AWS Management Console, navigate to **IAM**, click on **Role**, and click on **Create Role**. 2. Select **EC2 for Service**. 3. In the policy, select `SecretsManagerReadWrite`, and click **Next**. 4. Add the role name and description, and then go to **EC2** and click on **Instances**. 5. Select the instance that houses the gateway, and click on **Actions > Security > Modify IAM Role**. 6. Choose the name of the IAM role created earlier. {% hint style="info" %} If your gateway is deployed in an EKS cluster and you are using [IAM Roles for Service Accounts](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html), you will need to set the following environment variable: `SDM_AWS_DEFAULT_PRIORITY=true`. {% endhint %} #### Option 3: ECS authentication In the task definition for the ECS cluster, the `Task Role` must have a policy allowing access to Secrets Manager attached to it, as in the following example: ```json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "arn:aws:secretsmanager:us-east-1:12345678910:secret:*" ] } ] } ``` If `Resource Permissions` is configured for Secrets Manager, the policy statement also needs to allow the `Task Role` to access that particular Secrets Manager. #### Credential reading order During authentication with Secrets Manager, the system looks for credentials in the following places in this order: 1. Environment variables 2. EC2 role 3. ECS authentication or other remote authentication methods (set via `AWS_CONTAINER_CREDENTIALS_FULL_URI` or `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`) 4. Shared credentials file As soon as the relay or gateway finds credentials, it stops searching and uses them. Due to this behavior, we recommend that all similar AWS resources with these authentication options use the same method when added to StrongDM. For example, if you are using environment variables for AWS Management Console and using EC2 role authentication for an EKS cluster, when users attempt to connect to the EKS cluster through the gateway or relay, the environment variables are found and used in an attempt to authenticate with the EKS cluster, which then fails. We recommend using the same type for all such resources to avoid this problem at the gateway or relay level. Alternatively, you can segment your network by creating subnets with their own relays and sets of resources, so that the relays can be configured to work correctly with just those resources. This behavior was changed in CLI version 39.51.0. If you experience unexpected errors when upgrading to this version or above, you can set the environment variable `SDM_AWS_LEGACY_PRIORITY` to a truthy value such as `1` or `true`, to temporarily revert to the old behavior. In a future release, this option will go away. {% hint style="info" %} If you would prefer to alter the priority of credentials to follow the default order specified by [Configuring the AWS SDK for Go - AWS SDK for Go (version 1)](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html) in the "Specifying Credentials" section, you may set the environment variable `SDM_AWS_DEFAULT_PRIORITY` to a truthy value such as `1` or `true`. {% endhint %} ### Add AWS CA in the Admin UI To add an AWS RDP CA in the Admin UI, follow these steps. 1. From the **Settings** > **Credentials Managemen** page in the **Certificate Authorities** tab, click **Add certificate authority**. 2. Enter the **Name** for the CA (any name). 3. For **Type**, select **AWS Private CA RDP**. 4. The form updates with other [CA properties](#aws-private-ca-rdp-properties). Complete all required properties. 5. Click **Create certificate authority**. #### AWS Private CA RDP properties | Property | Requirement | Description | | ---------------------------------------------- | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Region** | Required | AWS region (for example, `us-east-1`) | | **Certificate Authority Amazon Resource Name** | Required | Amazon Resource Name (ARN) for the CA (for example, `arn:aws:acm-pca:us-east-1:12345678:certificate-authority/abcd-1234-defg-5678`) | | **Signing Algorithm** | Required | Signing algorithm that the CA uses to sign certificate requests; acceptable values are `SHA256WITHECDSA`, `SHA384WITHECDSA`, `SHA512WITHECDSA`, `SHA256WITHRSA`, `SHA384WITHRSA`, and `SHA512WITHRSA`; the signing algorithm must match the key type of the CA (for example, the signing algorithms that specify `WITHRSA` should be used for CAs with key type RSA 2048 or RSA 4096) | | **Certificate Template Amazon Resource Name** | Required | ARN of the configuration template used by the AWS CA to issue certificates (for example, `arn:aws:acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1`) | | **Certificate TTL Minutes** | Required | TTL of the issued certificate, in minutes (for example, `480`); default is `5`; if not specified, the default TTL of five minutes is used | {% hint style="info" %} All third-party CAs except for AD CS and Keyfactor EJBCA have a default TTL of five minutes. A five-minute TTL ensures short-lived certificates so that authentications can’t be reused beyond the specified TTL. If you wish to have a longer TTL, please set it appropriately for your organization and consult your CA service provider and CA administrator. {% endhint %} ### Add the AWS CA to a Certificate-Based RDP Server 1. If you have not already done so, follow the instructions to add an [RDP server with certificate authentication](https://docs.strongdm.com/admin/resources/servers/rdp-certificate-auth). 2. On the resource form, pay particular attention to **Certificate Authority**. For this field, select the newly added AWS CA. 3. Complete all required fields and save. 4. Test the connection to the resource (for example, use Remote Desktop to connect). ### Manage the CA After you have added the AWS 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 AWS. {% 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 Reference](https://app.gitbook.com/s/4XOJmXFslCMVCzIG2rKp/cli "mention"), [StrongDM SDKs](https://app.gitbook.com/s/4XOJmXFslCMVCzIG2rKp/api#strongdm-sdks), and [Terraform Provider](https://github.com/strongdm/terraform-provider-sdm). 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 RDP 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-rdp-ca`. {% endhint %} ### Add AWS CA in the CLI To add an AWS CA in the CLI instead of the Admin UI, use the [sdm admin secretstores](https://app.gitbook.com/s/4XOJmXFslCMVCzIG2rKp/cli/admin/secretstores "mention") CLI command. Create your "secret store" by choosing `awsCertX509` as the secret store type. ```sh sdm admin secretstores create awsCertX509 ``` In the CLI, the options are the same as the [AWS CA properties](#aws-private-ca-rdp-properties) set in the Admin UI. #### CLI example ```sh # Create AWS Private CA RDP sdm admin secretstores create awsCertX509 --ca-arn="arn:aws:acm-pca:us-east-1:12345678:certificate-authority/abcd-1234-defg-5678" --certificate-template-arn="arn:aws:acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1" --issued-cert-ttl-minutes="480" --name="AWS CA" --region="us-east-1" --signing-algo="SHA256WITHRSA" # Create RDP (Certificate Based) server sdm admin servers create rdp-cert --name="Example RDP AWS" --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 AWS CA" ``` #### Add AWS CA in Terraform In addition to using the Admin UI and CLI, you may use Terraform to add an AWS CA for use with certificate-based RDP 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 AWS Private CA RDP resource "sdm_secret_store" "example-tf-rdp-ca" { aws_token_cert_x509 { name = "${var.prefix}rdp-ca" ca_arn = "arn:aws:acm-pca:us-east-1:12345678:certificate-authority/abcd-1234-defg-5678" certificate_template_arn = "arn:aws:acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1" issued_cert_ttl_minutes = "480" name = "example-ca-name" region = "us-east-1" signing-algo ="SHA256WITHRSA" } } # Create RDP (Certificate Based) server resource "sdm_resource" "example-rdp-cert-based" { rdp { name = "${var.prefix}rdp-aws-ca" hostname = "https://aws.example.com:1234" secret_store_id = sdm_secret_store.example-tf-rdp-ca.id username = "username" } } ``` #### Add AWS CA with the SDKs To add an AWS CA 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/aws-ca-rdp.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.