It is a Google Cloud service for deploying, managing, and securing private certificate authorities.

Google’s documentation describes Certificate Authority Service, often shortened to CA Service, as a service for deploying, managing, and securing private certificate authorities. A certificate authority, or CA, is an organization or system that issues digital certificates. A private CA is one that you run for your own organization, to identify your own people, machines, and programs, rather than for the public internet.

The documentation explains that private CAs issue digital certificates that identify entities and carry cryptographic signatures, and that organizations use them to authenticate users, machines, and services, often in DevOps environments that protect containers, microservices, virtual machines, and service accounts.

Encryption hides messages, but trust tells you who you are really talking to.

Suppose your application sends a customer’s data to a payment service over the network. Two worries arise. First, someone could read the data on its way, which encryption solves. Second, someone could pretend to be the payment service and trick your application into handing over the data, which encryption alone does not solve. You need proof of identity. Certificates provide that proof.

A certificate is a digital document that ties a name to a cryptographic key, signed by an authority.

Keys come in pairs

Modern security relies on pairs of keys. One is the private key, which its owner keeps secret. The other is the public key, which can be shared with anyone. Something locked with one key can only be unlocked with the other. If you prove that you hold the private key matching a public key, you prove a certain kind of identity.

What a certificate contains

A certificate bundles the public key with information about its owner, such as a name or an identifier, plus the name of the issuer, validity dates, allowed uses, and the issuer’s digital signature. Google describes private certificates as carrying entity identity, issuer identity, and signatures. The signature is what makes the certificate trustworthy, because only the issuer can create it.

PKI is the whole system of authorities, certificates, and rules that make trust work.

The collection of authorities, certificates, keys, and policies that together provide trust is called a public key infrastructure, or PKI. A PKI is arranged as a chain. At the top sits a root CA, whose certificate is signed by itself. Beneath it can be subordinate CAs, whose certificates are signed by a CA above them. At the bottom are the certificates issued to servers, devices, and people, called end-entity certificates.

To trust a server’s certificate, a computer follows the chain upward: this certificate was signed by that subordinate CA, which was signed by that root CA, which I have been told to trust. If the chain reaches a trusted root without any broken link, the certificate is accepted.

flowchart TD
  ROOT["Root CA: self-signed, kept very safe"] --> SUB1["Subordinate CA: issues for production"]
  ROOT --> SUB2["Subordinate CA: issues for development"]
  SUB1 --> E1["Certificate: payment service"]
  SUB1 --> E2["Certificate: web front end"]
  SUB2 --> E3["Certificate: test service"]
        

Public CAs vouch for the open internet; private CAs vouch for your own world.

Public CAs are run by organizations that browsers and operating systems already trust. They must follow strict rules, such as verifying the identity of whoever requests a certificate, and they must record issued certificates in public logs. Private CAs are run by a single organization for its own clients. According to Google’s overview, this lets organizations issue certificates for internal names without public logging, which keeps internal service names private.

Many modern systems need identities for things that are not people.

Google’s overview lists several use cases. Here they are in plain language.

A handful of resources make up the whole service.

flowchart LR
  T["Certificate template"] --> POOL["CA pool"]
  IP["Issuance policy"] --> POOL
  POOL --> CA1["CA one"]
  POOL --> CA2["CA two"]
  CA1 --> K1["Signing key in Cloud KMS or HSM"]
  CA2 --> K2["Signing key in Cloud KMS or HSM"]
  CA1 --> CERT["Issued certificates"]
  CA2 --> CERT
        

CA Service can host both kinds, and can also connect to authorities outside Google Cloud.

Google’s concepts page explains that a root CA has a self-signed certificate and sits at the top of the chain of trust. A subordinate CA has a certificate signed by another CA, which can be another CA in CA Service or an external CA. When the parent is external, CA Service generates a certificate signing request, a formal request for a certificate. The external CA signs it, and you then activate the subordinate by uploading the signed chain.

The overview adds several flexibilities: you can define each CA’s subject, key algorithm, and location; you can place a subordinate CA in a different region from its root; and you can bring an existing root CA, including one on-premises or elsewhere outside Google Cloud, and chain other CAs to it.

flowchart TD
  EXT["Existing on-premises root CA"] -->|"signs request"| SUBA["Subordinate CA in CA Service"]
  GROOT["Root CA in CA Service"] --> SUBB["Subordinate CA in another region"]
  SUBA --> LEAF1["Certificates for cloud workloads"]
  SUBB --> LEAF2["Certificates for regional workloads"]
        

A pool groups CAs behind a single issuance endpoint and shares the workload.

The CA pool is described as the primary resource in CA Service. It holds CAs and the certificates they issue. Settings such as IAM conditions and issuance policies attach to the pool, and requests for certificates are spread across the CAs inside it. This design has practical benefits.

sequenceDiagram
  participant A as Application
  participant P as CA pool
  participant C1 as CA one
  participant C2 as CA two
  A->>P: Request a certificate
  P->>C1: Route request
  C1-->>A: Signed certificate
  A->>P: Request another certificate
  P->>C2: Route request
  C2-->>A: Signed certificate
        

The tier decides the balance between speed, tracking, and the ability to revoke.

According to Google’s concepts page, the tier is chosen per CA pool. The DevOps tier is built for high-volume issuance with higher throughput. Issued certificates are not tracked in the CA database, so they cannot be revoked, and the tier supports only Google-owned, Google-managed encryption keys rather than customer-managed Cloud KMS keys. The Enterprise tier has lower throughput, but it tracks issued certificates and supports revocation. It suits long-lived certificates and supports both customer-managed Cloud KMS keys and Google-owned keys.

flowchart TD
  Q1{"Do you need to revoke certificates?"} -->|"Yes"| ENT["Enterprise tier"]
  Q1 -->|"No"| Q2{"Short-lived and very high volume?"}
  Q2 -->|"Yes"| DEV["DevOps tier"]
  Q2 -->|"No"| Q3{"Need customer-managed keys?"}
  Q3 -->|"Yes"| ENT
  Q3 -->|"No"| DEV
        

Templates and policies control what kinds of certificates can be issued and how.

Certificate templates

A template is a top-level resource that defines one issuance scenario. Certificates issued from it inherit preset X.509 extensions such as key usage and path length limits. A template also controls which extensions from a request are kept or ignored, and can constrain certificate identities. One template can be shared across multiple pools.

Issuance policies

An issuance policy is a coarse-grained control applied to the whole pool. It defines which certificate types the pool’s CAs may issue. For example, a pool can be limited to client TLS certificates and blocked from issuing CA certificates. Fine-grained control comes from templates combined with IAM conditions, so that different users can have different permissions on the same pool.

The signing key is the crown jewel, so its protection is central to a CA’s security.

If someone steals a CA’s private signing key, they can create certificates that everyone will trust. That is why protecting the key is the most important task in any PKI. Google’s concepts page explains that CA Service uses Cloud Key Management Service to generate and store CA keys, and that a Cloud KMS key version signs both certificates and revocation lists. You can bring your own Cloud KMS key or choose an algorithm and let CA Service create the key. Keys that CA Service creates are always hardware-backed.

The overview adds that CA keys can be stored in Cloud HSM, which Google says is validated to FIPS 140-2 Level 3. A hardware security module is a tamper-resistant device that performs cryptographic operations without ever exposing the private key.

Choosing an algorithm

Google’s guidance says ECDSA offers the best performance and security for well-defined environments with modern devices, while RSA may suit environments with widely varied systems where key support is uncertain. Also weigh compliance requirements, compatibility, and your threat model.

Every certificate follows a predictable journey from birth to retirement.

sequenceDiagram
  participant W as Workload
  participant P as CA pool
  participant CA as Issuing CA
  participant K as Signing key in HSM
  W->>W: Create key pair and signing request
  W->>P: Send request with identity details
  P->>P: Check policy, template, and IAM
  P->>CA: Forward approved request
  CA->>K: Ask key to sign
  K-->>CA: Signature
  CA-->>W: Certificate and chain
  W->>W: Use certificate for secure connections
        

Revocation cancels trust in a certificate before its expiry date.

Sometimes a certificate must stop being trusted early: a private key leaked, a laptop was lost, or an employee left. This is called revocation. A certificate revocation list, or CRL, is a list of serial numbers of certificates that have been revoked. Google’s concepts page says CRLs are a cloud resource nested under each CA and can also be published in PEM or DER format to a Cloud Storage bucket that has a public HTTP address. It adds that a CA publishes its certificates and CRLs to a Cloud Storage bucket in the same location as the CA.

Revocation is available only in the Enterprise tier, because that tier tracks issued certificates. In the DevOps tier, certificates are not tracked, so they cannot be revoked.

Who may manage CAs and who may request certificates must be separated.

CA Service integrates with Identity and Access Management so you can control exactly who can do what. Google’s concepts page notes that IAM conditions can be set on a CA pool and combined with certificate templates to give different users different permissions. The best practices page also advises assigning each person no more than one role at a time, training role holders on their responsibilities, and creating a custom role when someone needs a varied set of permissions instead of stacking several roles.

Several Google Cloud services work with CA Service to protect and observe it.

What to watch in the logs

A sensible hierarchy makes everything easier: security, rotation, and growth.

Google’s best practices page does not give detailed hierarchy design guidance, so the following suggestions are general PKI practice, not statements from Google’s documentation. Verify them against your own security and compliance needs.

flowchart TD
  R["Root CA: Enterprise pool, rarely used"] --> I1["Subordinate: production, Enterprise pool"]
  R --> I2["Subordinate: development, DevOps pool"]
  I1 --> S1["Servers and devices: longer lifetime, revocable"]
  I1 --> S2["Internal CAs for specific teams"]
  I2 --> S3["Short-lived workload certificates"]
        

You pay a monthly fee per CA, plus a fee for each certificate issued.

Google’s pricing page states that charges depend on the number of certificates your CAs issue, with two SKUs, one for each tier. At the time of writing, the page lists a monthly fee of 20 US dollars per DevOps CA and 200 US dollars per Enterprise CA. The per-certificate fee is a one-time charge for each certificate issued, and it falls as volume rises. The volume tiers apply across all your CAs combined, not separately per CA. The page does not mention a free tier.

Worked example from the pricing page

The page shows that one DevOps CA issuing 10,000 certificates costs 3,000 dollars in certificate fees plus 20 dollars monthly, which is 3,020 dollars. For two DevOps CAs issuing 500,000 certificates each, the volume is billed as one million certificates in total, plus two monthly fees. The page suggests a subscription model with predictable billing for more than one million certificates per month, arranged through Google Cloud sales.

Habits that keep costs reasonable

These mistakes appear again and again in real PKI projects.

A managed private CA saves effort, but it is not always the right choice.

Other ways to get certificates

flowchart TD
  N["Need a certificate"] --> A{"Used by the public internet?"}
  A -->|"Yes"| PUB["Use a public CA"]
  A -->|"No"| B{"Want to run PKI servers yourself?"}
  B -->|"Yes"| SELF["Self-managed CA"]
  B -->|"No"| CAS["Use CA Service"]
        

Here is how different organizations typically use a private CA.

Keep this short list close when planning or reviewing a private CA.

Quick answers to the questions beginners ask most.

A Google Cloud service for deploying, managing, and securing private certificate authorities that issue digital certificates for your own users, devices, and workloads.

A root CA has a self-signed certificate and sits at the top of the chain of trust. A subordinate CA’s certificate is signed by another CA, either in CA Service or an external one.

The primary resource in CA Service: a container for CAs and their certificates that spreads requests across the CAs and holds policies and access conditions.

DevOps, for high-volume issuance without tracking or revocation, and Enterprise, which tracks certificates, supports revocation, and also supports customer-managed Cloud KMS keys.

Yes. Google says you can bring an existing root CA, including one on-premises or elsewhere, and chain other CAs to it. Previously issued certificates cannot be imported, however.

Only in the Enterprise tier. DevOps certificates are not tracked, so they cannot be revoked and should be short-lived.

In Cloud KMS, and they can be stored in Cloud HSM. Keys that CA Service creates are always hardware-backed, and Google recommends Google-managed keys unless you have custom requirements.

A reusable definition of one issuance scenario. Certificates inherit its preset extensions, and it can control which requested fields are kept or ignored.

Google states that the DevOps tier supports up to 25 certificates per second per CA, and that a pool can effectively reach about 100 per second.

A monthly fee per CA plus a one-time fee per certificate issued, with volume tiers across all your CAs. Verify current figures on Google’s pricing page, and note that I found an inconsistency in one worked example there.

It is designed for private PKI. Public browsers do not trust your private CA by default, so public sites normally use public CAs.

Through APIs, the gcloud command line tool, the Google Cloud console, or Terraform.

Certificate Authority Service gives you a managed, private passport office for digital identities. A chain of trust runs from a protected root CA through subordinate CAs to the certificates used by servers, devices, people, and programs. CA pools group authorities behind one endpoint and share the load. The DevOps tier delivers high-volume, short-lived, non-revocable certificates, while the Enterprise tier tracks certificates, supports revocation, and allows customer-managed keys. Templates, issuance policies, and IAM conditions keep issuance safe, and Cloud KMS, Cloud HSM, audit logs, and VPC Service Controls protect the keys and the service. With a sensible hierarchy, automation, careful access control, and honest cost planning, a private CA becomes a quiet foundation that lets everything else in your systems trust each other.