Stay organized with collections Save and categorize content based on your preferences.

Certificate authority settings

This page describes the various settings of a certificate authority (CA).

Permanent settings

You cannot change the settings mentioned in this section after creating the CA.

Service-specific settings

Type of CA

CA Service lets you create both root CAs and subordinate CAs.

Root CA Subordinate CA
A root CA is a self-signed CA. Parties that need to authenticate certificates created from a root CA (a relying party) must know its CA certificate in advance. The root CA certificate is often referred to as a trust anchor.

Frequently changing a root CA is difficult. To change the root CA, you must first update all relying parties about the new trust anchor. Otherwise, they won't be able to authenticate certificates from the new root CA.

Root CAs cannot be revoked using the CRLs of the issuing CA because root CAs are self-signed. To revoke a root CA, you must remove it from the trust store of every single client that trusts it. This process can be long and tedious. Hence, we recommend protecting the root CAs.
A subordinate CA is a CA that is signed by a root CA or another subordinate CA. Following a chain of subordinate CAs, the chain always ends with a root CA.

A relying party that only knows about a root CA can also implicitly trust a subordinate CA that chains to the explicitly trusted root CA certificate. The subordinate CA can be trusted only if the relying party is able to cryptographically validate the certificate chain that forms a path to the root CA certificate.

A chain containing a root and one or more subordinate CAs can include CAs that are managed in CA Service and CAs that aren't.

Cloud KMS key

By default, new CAs use a Google-managed Cloud Key Management Service (Cloud KMS) key. You can choose a specific key algorithm for the Google-managed Cloud KMS key. Alternatively, you can grant CA Service access to a key that already exists. For more information, see Choosing a key algorithm.

For more information about the management models for Cloud KMS keys and Cloud Storage buckets, see Managed resources.

Cloud Storage bucket

By default, CA Service creates a new Google-managed Cloud Storage bucket in the same location as the CA. You can also choose to use an existing self-managed bucket or create a new bucket. To minimize latency while publishing CRLs, we recommend creating the Cloud Storage bucket in the same location as your CA. For more information, see Managed resources.

CA certificate settings

The following settings are directly reflected in the CA's own certificate:

Setting Description
Lifetime Specifies a CA's lifetime. Lifetime is the amount of time, starting from the CA's creation, that the CA is valid for.
Subject A CA can specify a distinguished name and subject alternative names. In many cases, these fields are purely informational. However, a relying party can choose to treat certificates issued from a CA with particular subject attributes differently.

If you want to specify a subject alternative name for your CA's certificate, you must use the Google Cloud CLI.

Optional CA settings

The following CA settings are optional. You can change the following setting after creating the CA.

Setting Description
Label A CA can have one or more user labels attached to it. Labels have no semantic meaning to CA Service.

What's next