How to Configure Google Cloud Certificate Authority Service (CAS) for Internal PKI

Managing an internal Public Key Infrastructure (PKI) using on-premises Microsoft Active Directory Certificate Services (AD CS) or manual OpenSSL scripts is operationally burdensome, prone to catastrophic expiry errors, and incredibly difficult to scale globally. To address this for cloud-native architectures, Google provides the Certificate Authority Service (CAS).

Google Cloud CAS is a highly scalable, fully managed service that allows enterprises to deploy private Certificate Authorities (CAs) to issue certificates for internal workloads—such as mutual TLS (mTLS) for microservices, Istio service meshes, or VPN gateways—without managing any HSM (Hardware Security Module) infrastructure.

This guide explains how to architect, deploy, and issue certificates using Google Cloud CAS to establish a robust internal PKI.

Understanding the CAS Architecture

CAS operates using a hierarchical structure consisting of CA Pools and Certificate Authorities.

• CA Pool: A logical grouping of multiple underlying CAs. When an application requests a certificate, it requests it from the Pool rather than a specific CA instance. This allows Google to rotate CAs seamlessly and provides high availability.
• Root CA: The cryptographic anchor of trust. You can generate a new Root CA within CAS, or bring your own (BYOK) by generating the keys locally and uploading them.
• Subordinate CA: CAs signed by the Root CA, used for day-to-day certificate issuance. Best practices dictate that the Root CA is kept offline (or disabled when not actively signing Subordinates), and only Subordinate CAs exist within the active issuing CA Pools.

Step 1: Creating a Root CA Pool and Root CA

To begin, we must establish the root of trust. First, we create a CA Pool designed specifically to hold our Root CA.

gcloud privateca pools create enterprise-root-pool \
    --location us-central1 \
    --tier enterprise

The enterprise tier is required for Root CAs, as it supports custom subject names and long lifespans, whereas the devops tier is highly optimized for short-lived, high-throughput issuance (like Kubernetes pods).

Next, generate the actual Root CA inside this pool:

gcloud privateca roots create enterprise-root-ca \
    --pool enterprise-root-pool \
    --location us-central1 \
    --subject "CN=Internal Corp Root CA, O=Internal Corp, C=US" \
    --max-chain-length 1 \
    --validity P3650D

The validity P3650D sets the Root CA to be valid for 10 years (3650 days). The max-chain-length 1 ensures that this Root CA can only sign Subordinate CAs, and those Subordinates cannot sign further CAs, protecting against rogue CA generation.

Step 2: Creating an Issuing CA Pool and Subordinate CA

With the root established, we create a separate pool for our Issuing (Subordinate) CA. This pool will be used by our applications and APIs to request end-entity certificates.

gcloud privateca pools create devops-issuing-pool \
    --location us-central1 \
    --tier devops

The devops tier is significantly cheaper and faster, making it perfect for issuing millions of short-lived mTLS certificates.

Now, create the Subordinate CA and instruct CAS to have it cryptographically signed by the Root CA we created in Step 1.

gcloud privateca subordinates create devops-issuing-ca \
    --pool devops-issuing-pool \
    --location us-central1 \
    --issuer-pool enterprise-root-pool \
    --issuer-location us-central1 \
    --subject "CN=DevOps Issuing CA, O=Internal Corp, C=US" \
    --validity P1825D

This Subordinate CA is valid for 5 years. Once created, it is immediately capable of issuing certificates.

Step 3: Issuing an End-Entity Certificate

To test the PKI infrastructure, we will issue a certificate for an internal web service. In a production environment, this is usually handled via APIs, cert-manager (in Kubernetes), or Terraform, but we can issue one manually via the gcloud CLI.

First, generate a private key locally using OpenSSL:

openssl genrsa -out internal-service.key 2048

Generate a Certificate Signing Request (CSR):

openssl req -new -key internal-service.key -out internal-service.csr -subj "/CN=api.internalcorp.local"

Submit the CSR to the Issuing CA Pool to be signed:

gcloud privateca certificates create api-cert \
    --issuer-pool devops-issuing-pool \
    --location us-central1 \
    --csr internal-service.csr \
    --cert-output-file internal-service.crt \
    --validity P30D

CAS processes the CSR, signs it using the devops-issuing-ca, and returns the signed internal-service.crt valid for 30 days.

Step 4: Distributing Trust

For your internal clients (e.g., employee laptops, other servers) to trust the newly issued internal-service.crt, they must trust the Root CA.

You can export the public certificate of your Root CA using:

gcloud privateca roots describe enterprise-root-ca \
    --pool enterprise-root-pool \
    --location us-central1 \
    --format="value(pemCaCertificates)" > root-ca.crt

This root-ca.crt file must be distributed to your fleet—either via Microsoft Intune, Group Policy (for Windows machines), Jamf (for macOS), or injected into the trust stores of your Linux containers.

Conclusion

Google Cloud Certificate Authority Service eliminates the traditional overhead of managing highly secure, highly available PKI infrastructure. By properly structuring Root and Issuing pools and utilizing the DevOps tier for rapid issuance, organizations can effortlessly secure their internal microservices and workloads with robust, cloud-native cryptography.