GCP Certificate Authority Service Integration for RDP

Last modified on March 18, 2024

This guide provides general information on how to add a certificate authority (CA) issued by Google Certificate Authority Service (CAS), a third-party PKI service for Google Cloud Platform (GCP), as a third-party CA to StrongDM.

GCP Certificate Authority Service CA integration allows a Google CAS CA to be used, instead of the default Strong CA managed by StrongDM, for certificate authentication for RDP using Remote Identities or leased credentials in a Microsoft Active Directory (AD) deployment.


Before you begin, ensure that you have the following.

  • Administrator permission level in StrongDM
  • StrongDM gateway or relay that can access the Google CAS service endpoint https://privateca.googleapis.com/
  • Familiarity with Google CAS, CA pools, and Microsoft AD
  • Properly configured CA in Google CAS
  • Certificate Revocation List (CRL) must accessible by the Active Directory domain controller for the target AD deployment.

Google CAS Configuration Considerations

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

CA structure

Google CAS is structured to host CA certificates in load-balanced CA pools. A CA pool can contain any number of root and subordinate CA certificates. Issued certificates can be requested from individual CAs or from a CA pool.

CAs in a pool need not all be root CAs, as long as each CA that will be used for certificate authentication is added to your AD deployment as a trusted root CA.

If a CA pool has multiple certificates that are part of the same trust chain, all CAs in a trust chain need to be uploaded in order for all CAs (root and intermediate) to be usable for certificate authentication into AD.

CA settings

This CA supports only enterprise-tier CAs for RDP authentication.

In the Google Cloud console, the “Publish CRL to GCS bucket for CAs in this pool” setting is enabled on all CAs within a CA pool and cannot be toggled on/off for individual CAs within a pool when the setting is enabled.


The certificate time-to-live (TTL) determines the lifetime of all certificates generated by the CA. The TTL may be set in either Google Cloud or StrongDM when adding the GCP CA (see the Certificate TTL Minutes property). In StrongDM, the default certificate TTL is five minutes. In Google Cloud, you can set the maximum TTL for certificates issued from any CA in a particular CA pool via the Google Cloud console or Google Cloud CLI.

If set to anything other than the default in StrongDM, and if the TTL set in StrongDM is less than the maximum already set, the TTL of the issued certificate will be used.

Setting the TTL on a CA in StrongDM that only has a CA pool ID (and no specific CA ID) will result in all certificates issued from the CA pool for RDP authentication with StrongDM to have the TTL that is set via StrongDM.

Authentication from a StrongDM gateway or relay to Google CAS

The gateway or relay must be able to reach out to Google CAS for a certificate. The authenticated user or service account must have the correct permissions to request a certificate from Google CAS.

For a service account access key, you will need to do the following:

  • Create an IAM service account with permissions to request certificates
  • Create an access key for the service account
  • Transfer the access key file to relay and run gcloud auth login --cred-file=KEY_FILE

For other authentication options, such as user authentication or service account impersonation, consult the GCP documentation.

Service limit quotas for GCP

Note that Google CAS places a quota on how many certificates can be requested per second (7 requests per second per CA, and 100 requests per second per location per project).

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 Google CAS 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 GCP CA in the Admin UI

To add a GCP CA in the Admin UI, follow these steps.

  1. From the Certificate Authorities page, click Add certificate authority.
  2. Enter the Name for the CA (any name).
  3. For Type, select GCP Certificate Authority Service RDP.
  4. The form updates with other CA properties. Complete all required properties.
  5. Click Create certificate authority.

GCP Certificate Authority Service RDP properties

The following properties are for GCP Certificate Authority Service RDP.

Project IDRequiredProject ID (for example, my-gcp-project)
LocationRequiredLocation (for example, us-east1)
Certificate Authority Pool IDRequiredCA pool ID (for example, my-gcp-pool-id)
Certificate Authority IDOptionalIndividual CA ID (for example, my-certificate-authority-id); optionl only if, for a given CA pool, all CAs in that pool are added as a trusted CA in your AD deployment; in such circumstances, certificate requests made to this pool will be load balanced by GCP to request from different CAs
Certificate TTL MinutesRequiredTTL of the issued certificate, in minutes (for example, 480); default is 5; if not specified, the default TTL of five minutes is used

Add the GCP 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.
  2. On the resource form, pay particular attention to Certificate Authority. For this field, select the newly added GCP 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 GCP CA and set a certificate-based server to use it, you may manage the CA and review its settings on the Certificate Authorities page of the Admin UI. You may select the CA from the list or click its Details button to view diagostics, 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 GCP CA in the CLI

To add a GCP CA in the CLI instead of the Admin UI, use the sdm admin secretstores create gcpCertX509 CLI command. The secret store type GCPCertX509Store corresponds to the GCP Certificate Authority Service RDP CA type.

In the CLI, the options are the same as the GCP Certificate Authority Service RDP CA properties set in the Admin UI.

CLI example

# Create GCP Certificate Authority Service RDP CA
sdm admin secretstores create gcpCertX509
--name="Example GCP CA"
--location value="us-west2"

# Create RDP (Certificate Based) server
sdm admin servers create rdp-cert
--name="Example RDP GCP"

# 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 RDP GCP"

Add GCP RDP CA in Terraform

In addition to using the Admin UI and CLI, you may use Terraform to add a GCP CA for use with certificate-based RDP 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 GCP RDP CA
resource "sdm_secret_store" "example-tf-rdp-ca" {
  gcp_token_cert_x509 {
    name = "${var.prefix}gcp-ca"
    ca-id = "12345678-a0b-123"
    ca-pool-id = "example-ca-pool"
    location value = "us-west2"
    project-id = "example-project-id"
    issued_cert_ttl_minutes = "480"

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

Add GCP CA with the SDKs

To add a GCP CA with the StrongDM SDKs, please see the SDKs on GitHub: