Learn about three different ways to relate root and subordinate Certificate Authorities in your Google Cloud projects and organization

Certificate Authority Service is a fully managed service that allows you to simplify, automate, and customize the deployment, management and security of private certificate authorities (CA).

If your organization currently provisions and manages private certificates for workloads and Internal SSL load balancers in Google Cloud, you can use the Certificate Authority Service to eliminate the manual certificate creation and rotation process and to implement strict access controls.

This article will show the pros and cons of three design options for the implementation of a certificate authority service: three different ways to relate root and subordinate CAs in your Google Cloud projects and organization.

All will use the Enterprise CA pool service tier (as opposed to the more limited DevOps tier) and a certificate authority hierarchy with two levels. (You can have more levels, but I suggest keeping it to three or fewer.)

Option 1: Organization-level CA setup

In this architecture, we will set up a single root CA and a subordinate CA per environment. It is the most straightforward architecture and allows us to manage all the CAs and certificates centrally and apply the required IAM policy controls.

Only one root CA needs to be installed on all clients. You can use the certificate issuance policy to ensure each subordinate CA can only provide certificates for domains we expect.

The disadvantage of this option is that a single root CA means all clients trust all certificates in all environments (e.g. production systems will trust pre-production systems and vice versa).

Using a single root CA setup makes testing any changes difficult, since misconfiguration will affect all the subordinate CAs. You should avoid making changes to the root CA and instead deploy new subordinate CAs and test the changes.

Option 2: CA setup per environment type

In this architecture, we set up a separate root CA and subordinate CA per environment type. The CAs are all in a single project, distinguishing production from pre-production, while other cloud resources have separate projects, e.g. for development, pre-production and production.

Based on the environment type, the services running in the project can get the required certificate from the subordinate CA, and can use a certificate issuance policy to ensure each subordinate CA can only provide certificates for the domains we expect.

This setup allows us to test changes in a lower environment before rolling them out to production.

The disadvantage of this option is that we need to install different root CAs for various clients depending on their environment type.

Option 3: CA setup per project

In this architecture, we set up a separate root CA and subordinate CA per project to provide complete separation. We can easily test changes in a lower environment without affecting other CA setups.

Multiple root CAs mean that we must install different root CAs for different clients depending on the environment they are in.

If we require trust across multiple environments, we must install multiple root CAs for that client.

This is the most complex option in terms of architecture and maintenance, but it does allow for security through separation.

Wrapping up

Your choice of design option for certificate authority service will depend on how your organization balances security requirements against easy management and low cost.

Get in touch to learn more about working with DoiT. We’re here to help if you require guidance on certificate authority service (CAS) design or any other cloud-related issues.