CAS is a managed service for creating and running private certificate authorities that issue digital certificates to your own services, devices and people.

A certificate authority, usually shortened to CA, is a trusted organization that issues digital certificates. A certificate binds a name, such as a server’s address or a device’s identity, to a cryptographic key, and the CA signs it so that others can check that the binding is genuine. Public CAs issue certificates for websites on the open internet. Private CAs issue certificates that are trusted only inside an organization, for internal services, employee devices, factory equipment and similar uses.

Running a private CA yourself is hard. You must protect the most sensitive keys in your company, write procedures for issuing and revoking certificates, publish lists of revoked certificates, keep records, and survive audits. Certificate Authority Service takes on much of that work. Google operates the infrastructure, stores the signing keys in protected systems, handles scale, and gives you a clean interface and API to issue and manage certificates. You keep control of policy: who can request what, with which names, for how long.

What CAS is not

CAS is a private CA service. It is not a public CA that issues certificates every web browser trusts out of the box. For public websites, Google Cloud offers other certificate management capabilities, and it is wise to check the current documentation to choose correctly. CAS also does not decide which of your services use certificates. It provides the identities, and your applications, platforms and tools must be configured to ask for and use them.

Modern systems have far more machine conversations than human ones, and each needs trust.

A typical application today is not one program but dozens of small services calling each other across a network. Add mobile apps, partner systems, scheduled jobs, containers that live for minutes and devices in the field. Every connection raises two questions. Am I talking to the real thing, and can anyone else listen in? Without good answers, an attacker who reaches the network can pretend to be a trusted service, read sensitive traffic or give false orders.

A short glossary makes the rest of the guide and the documentation far easier to read.

The whole system rests on one idea: trust a few roots, and extend that trust through signatures.

A certificate contains the name of its owner, the owner’s public key, a validity period, the name of the issuing CA, and a signature made by the CA with its private key. Anyone who has the CA’s public key can check the signature. If it is valid, they know the CA vouched for this exact name and key, and that nobody has altered the certificate since.

The question then becomes: why trust the CA? The answer is the chain. A server’s certificate is signed by a subordinate CA. The subordinate CA’s own certificate is signed by a higher authority, and so on up to a root CA. The root signs its own certificate, and a client trusts it because the root’s certificate was installed in the client in advance, by the operating system, the company or the platform. Verification walks up the chain until it reaches a root the client already trusts.

flowchart TD
  R["Root CA (self-signed, installed as trusted)"] --> S1["Subordinate CA: Production"]
  R --> S2["Subordinate CA: Devices"]
  S1 --> C1["Certificate: payments service"]
  S1 --> C2["Certificate: orders service"]
  S2 --> C3["Certificate: sensor 1047"]
  S2 --> C4["Certificate: sensor 1048"]
        

What a checker verifies

The most common use of certificates is to secure connections between systems.

Transport Layer Security, known as TLS, is the protocol that protects most internet traffic. When a client connects to a server, the server presents its certificate. The client checks the chain, name and validity, and if everything is correct, the two sides agree on temporary keys and encrypt the conversation. This is the padlock you see in a web browser.

In ordinary TLS, only the server proves its identity. In mutual TLS, written mTLS, the client also presents a certificate, and the server verifies it. This lets services know exactly which other service or device is calling, with strong cryptographic proof, instead of relying on network location or shared passwords.

sequenceDiagram
  participant C as Client service
  participant S as Server service
  C->>S: Hello, here are the encryption options I support
  S-->>C: Hello, here is my certificate
  C->>C: Check chain, name, dates and revocation
  S->>C: Please show your certificate too
  C-->>S: Here is my certificate
  S->>S: Check chain, name, dates and revocation
  C->>S: Both sides agree on session keys
  Note over C,S: Traffic is now encrypted, and both sides know who the other is
        

Choosing the right kind of CA depends on who must trust your certificates.

Many organizations use both. Public certificates secure the front door that customers use, while a private CA secures the thousands of internal doors. Using a public CA for internal traffic is awkward, since it may refuse internal names and gives you no control over policy. Using a private CA for public websites fails because browsers will not trust it.

In CAS, you request certificates from a pool, not from an individual CA.

According to Google’s documentation, a CA pool is the primary container for CAs and the certificates they issue. Settings such as access conditions and issuance policies are applied at the pool level. Issuance goes through the pool, which spreads requests across the CAs inside it. This arrangement makes rotation smooth: you can add a new CA to a pool, let it share the work, and later retire the old one, while your applications keep asking the same pool for certificates.

Why pools make life easier

A good private PKI is a small hierarchy, with a protected root at the top and working CAs below.

A root CA is self-signed and sits at the top of the chain. Because everything below depends on it, the root is the most valuable asset in the system. If it is compromised, every certificate issued under it is in doubt. For this reason, best practice keeps the root rarely used and heavily protected, and lets subordinate CAs do the daily work of issuing certificates.

Subordinate CAs are signed by another CA. In CAS, according to Google’s documentation, a subordinate CA can be signed by another CA created in CAS or by an external CA. In the external case, CAS produces a certificate signing request, you have your external CA sign it, and you activate the subordinate by uploading the signed certificate chain in PEM format using the command line or the console.

The shape of your hierarchy is hard to change later, so it deserves a sketch before any button is pressed.

The simplest hierarchy is a root and one subordinate. A more common arrangement for medium and large organizations is a root, a layer of intermediate CAs for broad regions or business areas, and issuing CAs below them that serve specific purposes. More layers give finer isolation and containment, but add complexity and longer chains to verify.

flowchart TD
  R["Root CA (Enterprise tier, rarely used)"] --> I1["Intermediate: Internal services"]
  R --> I2["Intermediate: Devices"]
  I1 --> P1["Pool: Long-lived server certificates (Enterprise)"]
  I1 --> P2["Pool: Short-lived workload certificates (DevOps)"]
  I2 --> P3["Pool: Factory devices (Enterprise)"]
  P1 --> E1["Server certificates"]
  P2 --> E2["Container and job certificates"]
  P3 --> E3["Device certificates"]
        

Questions that shape the design

The tier is the most important choice you make for a pool, and it decides what the pool can and cannot do.

Google’s best practices say that the DevOps tier should be used only for short-lived certificates, such as those for microservices, containers, session certificates and non-persistent virtual machines. The Enterprise tier is the usual choice for pools that issue certificates to other CAs and to long-lived end entities. A single PKI can mix both tiers in different pools.

A short decision path will keep you from the two most common mistakes: overpaying and under-protecting.

flowchart TD
  A["What will this pool issue?"] --> B{"Other CAs or long-lived certificates?"}
  B -->|"Yes"| E["Enterprise tier"]
  B -->|"No"| C{"Do you ever need to revoke individual certificates?"}
  C -->|"Yes"| E
  C -->|"No"| D{"Need customer-managed signing keys?"}
  D -->|"Yes"| E
  D -->|"No"| F{"Very high volume of short-lived certificates?"}
  F -->|"Yes"| G["DevOps tier"]
  F -->|"No"| H["Either; consider cost and growth"]
        

Rules of thumb

A template turns a certificate request into a controlled, repeatable recipe.

A certificate template is a top-level resource that defines a specific issuance scenario. According to Google’s documentation, it holds preconfigured X.509 extensions, such as key usage and path length, which certificates issued from the template inherit. It controls which extensions in a request are kept or ignored, and it can define identity constraints to limit the identities a certificate may carry. A template can be used with one or more pools.

Why templates matter

Without templates, every requester decides the contents of their own certificate, which invites mistakes and abuse. With templates, a security team designs the allowed shapes once. Requesters pick a template and supply only what the template allows, such as the name. The template overrides anything else they try to add. Combined with access conditions on the pool, templates also let different users have different powers on the same pool: a web team may use the server template, while a device team uses the device template.

Policy decides what a pool may issue, and access conditions decide who may ask.

The documentation describes two layers of control. At the coarse level, an issuance policy on a pool states which kinds of certificates its CAs are allowed to issue. For example, a pool can be limited to client authentication certificates and forbidden from issuing CA certificates. At the fine level, templates combined with Identity and Access Management conditions control which operations each user can perform. This allows one pool to serve several teams safely.

A CA is only as trustworthy as the protection of its private signing key.

CAS uses Cloud KMS to generate, store and use CA signing keys. A key version signs both certificates and revocation lists. You can bring your own Cloud KMS key, or specify an algorithm and let CAS create the key. Keys created by CAS are always hardware-backed, according to the documentation. Keys can be software-backed or hardware-backed when you bring your own. DevOps tier CAs cannot use customer-managed keys, so they use Google-owned keys.

Google’s best practices add some useful points. Unless you have custom security or operational needs, use Google-owned, Google-managed keys, which are generated and stored in Cloud HSM. A key cannot be exported from Cloud HSM after creation or import, so it cannot be migrated elsewhere. CA keys sign only certificates and revocation lists, and are never used for encryption. Choose algorithms and sizes that will stay secure for the CA’s whole intended life.

Algorithm choice

The best practices page notes that ECDSA gives the best performance and security for well-defined PKIs with modern devices, while RSA is suitable where device support is uncertain. Check the devices and software that must verify your certificates before choosing, because an algorithm that a device cannot verify makes the certificate useless there.

From the first request to a working certificate, the same steps repeat every time.

sequenceDiagram
  participant W as Workload or device
  participant A as Automation agent
  participant P as CAS CA pool
  participant K as Cloud KMS and HSM
  W->>W: Create a private key
  W->>A: Prepare a signing request with its public key and name
  A->>P: Request a certificate using a template
  P->>P: Check access conditions, template and policy
  P->>K: Ask the CA key to sign the certificate
  K-->>P: Signature
  P-->>A: Signed certificate and chain
  A-->>W: Install certificate and chain
  Note over W: Workload uses the certificate until it expires, then renews
        

Step by step

Sometimes a certificate must stop being trusted before its expiry date.

A device may be stolen, a private key may leak, or an employee may leave. In such cases, the CA must be able to cancel the certificate. The standard method is a certificate revocation list, or CRL, a signed list of serial numbers of certificates that are no longer to be trusted. Clients that check revocation download the CRL and refuse any certificate on it. According to Google’s documentation, CRLs exist as a cloud resource nested under each CA.

Revocation is available only on Enterprise tier CAs, since the DevOps tier does not track issued certificates. The documentation states that DevOps certificates are not tracked in the CA database and therefore cannot be revoked. For DevOps pools, the practical answer is very short lifetimes, which is why that tier suits short-lived workloads.

Clients need a place to fetch the CA certificate and revocation list, and CAS provides it through Cloud Storage.

The documentation explains that CAs publish their CA certificates and CRLs to a Cloud Storage bucket in the same location as the CA. CRLs can be published in PEM or DER encoding. The bucket can be managed by Google or by you, and CRLs can be served from a publicly accessible web address. Certificates issued by the CA can carry pointers to these addresses, so clients know where to fetch the information.

Practical thinking about publishing

The published files must be reachable by every client that verifies your certificates. If those clients sit outside your network, a public address may be needed, which means the CA certificate and CRL are visible to anyone. These documents contain no secrets, but think about what the names inside them reveal. If your clients are all inside private networks, you may restrict access to match.

How long a certificate lives is one of the most important security settings you control.

Every certificate has a start and an end date. A long lifetime means fewer renewals, but a stolen key stays dangerous for longer. A short lifetime limits the damage of a leak and reduces the need to revoke, but demands reliable automation, because a missed renewal means an outage when the certificate expires. The Google documentation I reviewed did not give default or maximum lifetimes, so check the current documentation and your own policy before deciding. The principle is widely accepted: make lifetimes as short as your automation can safely support.

Making renewal reliable

Many companies already have a CA, and CAS can fit beneath it.

Organizations often already run an on-premises CA that issues certificates for office networks and legacy systems. Replacing it overnight is rarely possible, and not always desirable. CAS supports a subordinate CA signed by an external CA, which lets cloud workloads join the existing trust framework without asking every client to trust a second root.

The documentation describes the process. CAS creates a certificate signing request for the subordinate CA. You take the request to the external CA, which signs it. You then activate the CA in CAS by uploading the signed, PEM-encoded certificate chain through the command line or the console. From then on, the cloud CA issues certificates that chain up to your corporate root.

flowchart TD
  R["Corporate root CA (on premises)"] --> O["On-premises issuing CA"]
  R --> C["CAS subordinate CA in Google Cloud"]
  O --> L["Office and legacy system certificates"]
  C --> W["Cloud workload and service certificates"]
        

The best practices guidance adds a useful warning: previously issued certificates cannot be imported, so avoid importing an external CA that has already issued certificates. Start new CAs for new issuance and let old certificates expire naturally.

The value of a CA appears when your platforms use its certificates automatically.

CAS issues certificates, but something must request and install them. On Google Cloud, several kinds of platforms can do this. Container platforms and service meshes can obtain workload certificates for each pod or service, enabling mutual TLS between services without developers handling keys. Virtual machines can use agents or scripts to request certificates at start-up. Load balancers and other managed components can use certificates from a private CA for internal traffic. The exact integrations, setup steps and supported versions change often, so confirm the current list in the documentation for each platform you use.

What a good integration looks like

Certificates make “never trust, always verify” a practical design instead of a slogan.

Zero trust is a design approach that assumes the network can never be trusted by itself. Every request must prove who it comes from and be checked against policy, whether it originates inside or outside the company’s network. Machine certificates are a natural foundation. A service presents its certificate, the receiver verifies it, and the receiving service checks policy about which services may call which endpoints.

Devices in the field are the hardest place to keep identity safe and current.

Sensors, machines, meters and vehicles may be installed far from any technician, run for years, and connect over unreliable links. Each must prove its identity to the platform it reports to, and the platform must be able to cancel a device that is lost or stolen. These needs favor Enterprise tier pools, where certificates are tracked and can be revoked, and where customer-managed keys may be used if rules require.

A CA concentrates power, so who may do what must be designed with great care.

Identity and Access Management controls access to CAS resources. Different jobs exist in a CA: administering the service and its CAs, managing certificate templates, requesting certificates, and auditing. Google’s best practices say that an individual should not hold more than one role at a time, and that a custom role should be created if a broader permission set is needed. They also advise training everyone who holds a role about their responsibilities and security practices. Role names and permissions change, so check the current documentation before designing your grants.

Principles to keep

A private CA must be able to show exactly what it did.

Google’s best practices say to enable Cloud Audit Logs, including Data Access logs, and note that on the DevOps tier these logs are the only way to track certificates, since the tier does not record them in the CA database. Administrative logs record who created or changed pools, CAs and templates. Data access logs record certificate requests and related operations. Together they give a trail for audits and investigations.

Expiry monitoring

Beyond logs, monitor certificate expiry across your estate. Track the CA certificates themselves most closely, since an expired CA breaks everything below it. Also track the soonest expiring end certificates, and the success rate of renewals. A falling renewal success rate is an early warning that something in the automation is breaking.

CAs expire and keys age, so replacing them calmly is part of normal operation.

Google’s best practices advise setting up a process for regular CA key rotation, whatever the lifetime, key size or algorithm. The documentation I reviewed gave no specific interval. In practice, rotation of a CA means creating a new CA, with a new key, in the same pool, so that the pool can spread issuance across old and new CAs and then retire the old one. Certificates already issued by the old CA remain valid until they expire, provided clients still trust its chain.

stateDiagram-v2
  [*] --> Planned
  Planned --> Active: create and activate
  Active --> Overlap: new CA added to the pool
  Overlap --> Retiring: old CA stops issuing
  Retiring --> Expired: last certificates expire
  Expired --> [*]
        

A rotation plan

A sensible shape that many organizations can adapt.

In this layout, a dedicated PKI project holds all CAS resources. An Enterprise root CA, kept almost entirely unused, signs two subordinate CAs, one for long-lived certificates and one for short-lived workload identities. The long-lived branch sits in an Enterprise pool with revocation and publishes its revocation list to a bucket. The short-lived branch sits in a DevOps pool for high volume. Templates define server, client and device certificates. Workloads get identities from their platforms, requests are limited by templates and names, logs flow to a protected project, and alerts watch expiry and unusual issuance.

flowchart TD
  subgraph PKI["PKI project (few administrators)"]
    ROOT["Root CA (Enterprise pool)"]
    SUB1["Subordinate CA: long-lived (Enterprise pool)"]
    SUB2["Subordinate CA: workloads (DevOps pool)"]
    TPL["Certificate templates"]
    ROOT --> SUB1
    ROOT --> SUB2
    TPL --- SUB1
    TPL --- SUB2
  end
  SUB1 --> BKT["Storage bucket: CA certificates and CRLs"]
  SUB1 --> DEV["Devices and long-lived servers"]
  SUB2 --> MESH["Containers and service mesh workloads"]
  PKI --> LOG["Audit logs to protected project"]
  LOG --> ALR["Alerts on policy changes, volume spikes and expiry"]
        

Why this works

CAS has a simple pricing shape: a monthly fee for each CA, plus a one-time fee for each certificate issued.

According to the pricing page I reviewed, a DevOps tier CA costs about twenty dollars per month and an Enterprise tier CA about two hundred dollars per month. Each certificate issued carries a one-time fee that falls as volume rises. For the DevOps tier, the listed rates were about thirty cents per certificate for the first fifty thousand, about three cents from there to one hundred thousand, and under a tenth of a cent beyond that. Enterprise rates were somewhat higher, at about fifty cents, five cents and a tenth of a cent for the same bands. Volume bands apply across all your CAs combined. For more than a million certificates per month, the page suggests contacting sales about a subscription with predictable billing.

The same page also contains worked examples. The DevOps examples matched the listed rates when I recalculated them. One Enterprise example did not match the page’s own rates, so I will not quote it. The lesson is to calculate your own estimate with the official calculator, check the figures with Google if a large commitment depends on them, and expect prices to change. I also did not see a free tier mentioned on the page.

What really drives cost

Stories show how the ideas appear in daily life.

You have more than one way to get private certificates, and each suits different teams.

Cloud-based certificate management for public websites and load balancers is a related but different area, and Google Cloud has other capabilities for it. Confirm the current set of certificate services and choose the one that matches who must trust your certificates.

Architects write down significant choices so later teams understand the reasons.

The cheapest education is learning from other teams’ mistakes.

Five classic traps in detail

Start with the simplest cause and work toward the hardest.

A calm method

A short list to review before every launch.

Quick answers to the questions beginners ask most often.

Everything in this guide on one short page.

Certificate Authority Service gives you a managed private PKI. You organize CAs into pools, build a hierarchy with a protected root and working subordinates, choose a tier per pool, define templates and access conditions, protect signing keys in Cloud KMS and HSM, publish certificates and revocation lists, and let platforms request and renew certificates automatically. Done well, it turns machine identity from a risky patchwork of shared secrets into a consistent, auditable and automated system.