Managed resources

Certificate authorities (CAs) created through Certificate Authority Service rely on two secondary resource types:

• A Cloud KMS key version, used to sign certificates and Certificate Revocation Lists (CRLs) issued by the CA. For more information about key versions, see Key versions.
• A Cloud Storage bucket, used to host a CA certificate and/or any CRLs published by the CA, if these settings are enabled. For more information about Cloud Storage buckets, see Buckets.

Both of these resources must exist for each CA, and cannot be changed after the CA is created.

Management models

CA Service supports two lifecycle management models for these resources:

• Google-managed
• Customer-managed

Both resources don't need to use the same management model. For example, the key can be Google-managed, and the bucket can be customer-managed, or the other way around.

Google-managed

Resources following this model are automatically created and configured by the CA Service on CA creation and deleted on CA deletion. You are not billed separately for these resources.

By default, new CAs use Google-managed Cloud KMS keys and Cloud Storage buckets. You can choose a specific key algorithm for the Google-managed Cloud KMS key while creating a CA by using the following instructions:

Console

1. Go to the Certificate Authority Service page in the Google Cloud Console.

   Certificate Authority Service

2. Click the Create CA button

3. Choose the appropriate CA type, tier, and region, then click Next.

4. Configure the CA organization, common name, and resource ID, then click Next.

5. Under Configure CA key size and algorithm:

   1. Choose the one of the available key algorithms.
   2. Click Next.

6. Under Configure CA artifacts:

   1. Configure extension options for issued certificates.
   2. Click Next.

gcloud

gcloud privateca roots create CA_ID --pool POOL_ID \
    --subject "CN=Common Name, O=Organization Name" \
    --key-algorithm key-algorithm

Replace roots with subordinates to create a subordinate CA.

• key-algorithm can be one of the algorithms described here.
• If the --key-algorithm flag is omitted, this command defaults to:
  • rsa-pkcs1-4096-sha256 for root CAs.
  • rsa-pkcs1-2048-sha256 for subordinate CAs.
• Most other CA creation options are unchanged.

For more information on creating a CA, see Creating certificate authorities. For guidance on choosing a key algorithm, see Choosing a key algorithm.

Customer-managed

You must create and configure the resources following this model before CA creation. Additionally, you must delete these resources at an appropriate time after the CA is destroyed. Users are billed directly for these resources.

One advantage of this model is that callers have direct control over those resources, and may directly update attributes such as access management to fit their organizational requirements.

Note: Customer-managed resources are only supported for CAs in the Enterprise tier. For more on the supported tiers, see Workload-optimized tiers.

Note: Creating a CA with customer-managed resources requires the caller to have administrative access over those resources, in order to grant the appropriate access to CA Service. For more information, see CA Service Service Agent.

To use an existing Cloud KMS key version, follow these instructions:

Console

1. Go to the Certificate Authority Service page in the Google Cloud Console.

   Certificate Authority Service

2. Click the Create CA button

3. Under Select CA type:

   1. Choose an appropriate CA type and validity duration.
   2. Choose the Enterprise tier.
   3. Choose an appropriate location.
   4. Click Next.

4. Configure the CA organization, common name, and resource ID, then click Next.

5. Under Configure CA key size and algorithm:

   1. Click Customer managed key.

   2. Paste your key version resource name here.

      For instructions on finding the key version resource name, see Getting the ID for a key and version.

gcloud

gcloud privateca roots create CA_ID --pool POOL_ID\
    --subject "CN=Common Name, O=Organization Name" \
    --kms-key-version kms-resource-name

Where:

• kms-resource-name refers to the existing key version resource name. For instructions on finding , see Getting the ID for a key and version.
• Most other CA creation options are unchanged.

To create a subordinate CA, replace roots with subordinates in the gcloud command.

For more information about the gcloud privateca roots create command, see gcloud privateca roots create.

To use an existing Cloud Storage bucket, follow these instructions:

Console

1. Go to the Certificate Authority Service page in the Google Cloud Console.

   Certificate Authority Service

2. Click Create CA.

3. Under Select CA type:

   1. Choose an appropriate CA type and validity duration.
   2. Choose the Enterprise tier.
   3. Choose an appropriate location.
   4. Click Next.

4. Choose the appropriate CA subject and resource ID, then click Next.

5. Choose the appropriate CA key or key algorithm, then click Next.

6. Under Configure CA artifacts:

   1. Click Customer managed.
   2. Enter your existing Cloud Storage bucket name, or click "Browse" to find it.

gcloud

gcloud privateca roots create CA_ID --pool POOL_ID \
    --subject "CN=Common Name, O=Organization Name" \
    --bucket bucket-name

Where:

• bucket-name refers to the existing bucket name.
• Most other CA creation options are unchanged.

To create a subordinate CA, replace roots with subordinates in the gcloud command.

CA Service treats the project as the security boundary for customer-managed Cloud KMS keys. For example, consider that a user Alice uses a customer-managed Cloud KMS key to create a CA in project test. Then, another user Bob can use the same Cloud KMS key to create another CA in the same project. While Alice needs to have admin access on the key to create the first CA, Bob doesn't need any access on that key because Alice already enabled use of the key by CA Service in project test.

Note: You are required to create customer-managed Cloud KMS keys in the same location as that of your CA Service resources. For the complete list of locations for CA Service, see Locations. For the list of locations where Cloud KMS resources can be created, see Cloud KMS locations.

Note: You must create customer-managed Cloud Storage buckets in the same approximate location as your CA Service resources. For example, you can create CA Service resources in us-west1 and you can use Cloud Storage buckets in any single region in the US such as us-west1 or us-east1, the dual-region NAM4, and the multi-region US. For the list of locations where Cloud Storage resources can be created, see Cloud Storage locations.

Caution: You maintain control over the resources in this model. Therefore, it is possible to cause accidental outages for the CA by deleting those resources or removing the CA Service Service Agent account from their IAM policies. See Create an alerting policy to learn how to configure alerts for these scenarios.

Access to managed resources

Anybody who has the URL of the CA certificate hosted on Cloud Storage bucket or any CRLs published by the CA can access these resources by default. To prevent public access to your CA certificate, place the CA in a VPC Service Controls perimeter.

What's next

• Learn how to create CA pools.
• Learn how to create certificate authorities.