Manage resources

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

• A Cloud Key Management Service 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 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

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

Google-managed

CA Service automatically creates and configures the resources following this model on CA creation, and deletes the resources on CA deletion. You aren't 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. Google-managed Cloud KMS keys aren't reused across CAs.

For information about creating a root CA, see Create a root CA. To learn how to create a subordinate CA, see Create a subordinate CA. For guidance on choosing a key algorithm, see Choose a key algorithm.

Customer-managed

You can create customer-managed resources only for CAs in the Enterprise tier. You must create and configure the customer-managed resources 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.

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 administrator 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.

Advantages of creating customer-managed resources

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

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.

Location of Cloud KMS keys

You must 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.

Location of Cloud Storage buckets

You must create customer-managed Cloud Storage buckets in approximately the same location as your CA Service resources. You cannot create the Cloud Storage bucket outside the continent where you have created the CA Service resources.

For example, if your CA is in us-west1, you can create the 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. For information about configuring alerts for these scenarios, see Create an alerting policy.

Access to the managed resources

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

By adding the project containing the CA pool to a VPC Service Controls perimeter, the Google-managed Cloud Storage bucket joins the perimeter. The VPC Service Controls perimeter ensures that the Cloud Storage bucket cannot be accessed from outside the approved networks.

Clients within the network perimeter can still access the CRLs and CA certificates without authentication. The access requests from outside the approved network fail.

HTTP-based URLs for CA certificates and CRLs

CA certificates and CRLs are available on HTTP-based URLs for the following reasons:

• A CA certificate that is published in a Cloud Storage bucket isn't supposed to be trusted by clients as-is. The CA certificates are a part of a certificate chain, which starts with the certificate of the root CA. Each certificate in the certificate chain is signed by the CA certificate that is higher in the chain to preserve the integrity of the certificate. Hence, there is no added advantage of using the HTTPS protocol.

• Some clients reject HTTPS-based URLs while validating certificates.

Enable CA certificate and CRL publication for CAs in a CA pool

CA Service enables CA certificate and CRL publication to Cloud Storage buckets by default when you create a new CA pool. If you disabled CA certificate and CRL publishing while creating the CA pool and want to enable them now, you can follow the instructions in this section.

To enable CA certificate publication and CRL publication for all CAs in a CA pool, do the following:

Console

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

   Go to Certificate Authority Service

2. Under the CA pool manager tab, click the name of the CA pool you want to edit.

3. On the CA pool page, click Edit.

   

4. Under Configure allowed key algorithms and sizes, click Next.

5. Under Configure accepted certificate request methods, click Next.

6. Under Configure publishing options, click the toggle for Publish CA certificate to Cloud Storage bucket for CAs in this pool.

7. Click the toggle for Publish CRL to Cloud Storage bucket for CAs in this pool.

gcloud

Run the following command:

gcloud privateca pools update POOL_ID --publish-crl --publish-ca-cert

Replace POOL_ID with the name of the CA pool.

If you enable --publish-ca-cert, CA Service writes each CA's CA certificate to a Cloud Storage bucket, whose path is specified in the CA resource. The AIA extension in all the issued certificates points to the Cloud Storage object URL that contains the CA certificate. The CRL Distribution Point (CDP) extension in all the issued certificates point to the Cloud Storage object URL that contains the CRL.

Note: --publish-ca-cert and --publish-crl are enabled by default. Use --no-publish-ca-cert and --no-publish-crl to disable.

For more information about the gcloud privateca pools update command, see gcloud privateca pools update.

To learn more about enabling CRL publication for revoking certificates, see Revoking certificates.

Disable CA certificate and CRL publication for CAs in a CA pool

To disable CA certificate publication or CRL publication for all CAs in a CA pool, do the following:

Console

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

   Go to Certificate Authority Service

2. Under the CA pool manager tab, click the name of the CA pool you want to edit.

3. On the CA pool page, click Edit.

4. Under Configure allowed key algorithms and sizes, click Next.

5. Under Configure accepted certificate request methods, click Next.

6. Under Configure publishing options, click the toggle for Publish CA certificate to Cloud Storage bucket for CAs in this pool.

7. Click the toggle for Publish CRL to Cloud Storage bucket for CAs in this pool.

gcloud

Run the following command:

gcloud privateca pools update POOL_ID --no-publish-crl --no-publish-ca-cert

Replace POOL_ID with the name of the CA pool.

Disabling distribution points doesn't delete the Cloud Storage bucket or its permissions, and doesn't remove any CA certificates or CRLs that are already hosted there. It does, however, mean that future CRLs will no longer be published to the Cloud Storage bucket, and future certificates won't have the AIA and CDP extensions.

Update the encoding format of published CA certificates and CRLs

To update the encoding format of published CA certificates and CRLs, do the following:

Console

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

   Go to Certificate Authority Service

2. Under the CA pool manager tab, click the name of the CA pool you want to edit.

3. On the CA pool page, click Edit.

4. Under Configure allowed key algorithms and sizes, click Next.

5. Under Configure accepted certificate request methods, click Next.

6. Under Configure publishing options, click the drop-down menu for Publishing Encoding Format.

7. Select the publishing encoding format.

gcloud

Run the following command:

gcloud privateca pools update POOL_ID --publishing-encoding-format=PUBLISHING_ENCODING_FORMAT

Replace the following:

• POOL_ID: The name of your CA pool.
• PUBLISHING_ENCODING_FORMAT: Either PEM or DER.

For more information about the gcloud privateca pools update command, see gcloud privateca pools update.

What's next

• Learn how to create CA pools.
• Learn how to create a root CA.
• Learn how to create a subordinate CA.
• Learn how to create a subordinate CA from an external CA.