Certificate authority settings
This page describes the various settings of a certificate authority (CA).
You cannot change the settings mentioned in this section after creating the CA.
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:
|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.
|Label||A CA can have one or more user labels attached to it. Labels have no semantic meaning to CA Service.|
- Learn how to create CAs.