Managed 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/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

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.

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

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.

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 above it, which preserves 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.

What's next