Certificate Authority Service in Google Cloud: The Complete Guide to Building and Running Your Own Private Certificate Authority
A deep, plain-English walkthrough of how Certificate Authority Service issues, tracks and revokes private digital certificates, how CA pools, root and subordinate authorities fit together, and how to design a secure and affordable trust system on Google Cloud.
Imagine a country that issues passports. A border officer does not know every traveler personally. Instead, the officer trusts the passport because it was issued by a government office that everyone agrees to trust, and because the passport carries seals that are very hard to fake. Computers face the same problem all day long. When one server talks to another, how does it know the other side is genuine and not an imposter? The answer is the digital certificate, a kind of passport for machines, and the office that prints and signs those passports is called a certificate authority. Certificate Authority Service, or CAS, is Google Cloud’s managed passport office for the private world inside your company. This guide explains the whole system in simple language, from a single certificate to a global trust design.
1What Certificate Authority Service Is and Why It Exists
Certificate Authority Service is a highly available, scalable and fully managed service for creating private certificate authorities and issuing certificates from them.
The problem it solves
Modern systems are made of many small parts that must talk to each other safely: microservices, databases, devices, build pipelines and employee laptops. Each conversation should be encrypted, and each side should prove who it is. That proof usually comes from a certificate. In the past, companies ran their own certificate authority on a spare server, often with the secret signing key sitting on an ordinary disk, a forgotten spreadsheet tracking expiry dates and one person who understood how it all worked. When that person left or the server failed, the whole company’s trust broke.
CAS replaces that fragile setup. Google runs the infrastructure, keeps the signing keys inside protected hardware-backed key services, scales to very large numbers of certificates and records every action in audit logs. You decide the rules for who may receive certificates and what those certificates may contain, and CAS enforces those rules every time.
CAS is like a professional passport printing office for your own private country. You decide who qualifies for a passport and what it may say. The office has a heavily guarded vault for the master stamp, a log of every passport it ever printed, and a published list of cancelled passports.
What it is used for
Teams use CAS for encrypting traffic between internal services, proving the identity of workloads and devices, securing connections between servers and clients, signing code and documents, and issuing short-lived credentials to automation. It is for private trust inside an organization, not for the public websites that ordinary visitors reach.
2Core Concepts You Must Know First
Public key infrastructure has a small vocabulary, and mastering these eight terms makes the rest of the guide easy.
Digital Certificate
A signed electronic document that links a name, such as a server or person, to a public key, and states how long and for what purposes it is valid.
Key Pair
Two mathematically linked keys. The private key is kept secret and used to prove identity. The public key is shared freely and is placed inside the certificate.
Certificate Authority
The trusted party that checks a request and then signs a certificate with its own private key, vouching for the name and key inside.
Root CA
The top authority in a trust chain. It signs itself, and everyone who trusts it trusts everything beneath it. It is the most sensitive key you own.
Subordinate CA
An authority signed by a higher authority. It does the daily work of issuing certificates so the root can stay protected and rarely used.
Certificate Signing Request
A message sent by a system that says “please certify this name and this public key”. The private key never leaves the requester.
Revocation
The act of cancelling a certificate before it expires, for example because its private key was stolen.
Chain of Trust
The path from a certificate up through its issuers to a root that the verifier already trusts. If every link checks out, the certificate is accepted.
A certificate is a passport. The key pair is your signature, where only you can produce it but anyone can check it. The authority is the passport office, the root is the head office of the whole country, and a subordinate is a regional branch that the head office has authorized to print passports on its behalf.
3Anatomy of a Certificate
Every certificate follows a standard shape, and knowing its parts helps you write good rules and diagnose problems.
The fields that matter most
Certificates follow a widely used standard format. The subject says who the certificate belongs to. The subject alternative names list extra identities, such as several host names or addresses, and modern software relies on them more than on the subject itself. The issuer says who signed it. The validity period gives a start and an end time, after which the certificate is rejected. The public key is the shareable half of the key pair. The signature is the issuer’s mathematical seal over everything else.
Two more groups of fields control what the certificate may be used for. Key usage lists low-level actions such as signing or encrypting. Extended key usage lists higher-level purposes such as proving a server’s identity, proving a client’s identity or signing code. A basic constraints field says whether the certificate belongs to a CA that may sign others, and how many levels of authorities may exist below it.
| Field | What it tells you | Why it matters |
|---|---|---|
| Subject | The owner’s name | Identifies who the certificate is for |
| Subject alternative names | Additional host names, addresses or identities | What clients actually match against |
| Issuer | The CA that signed it | Starts the chain of trust |
| Validity period | Start and end times | Limits how long a stolen certificate is useful |
| Public key | The shareable half of the key pair | Used by others to verify or encrypt |
| Key usage and extended key usage | Allowed actions and purposes | Prevents a certificate from being used for the wrong job |
| Basic constraints | Whether it is a CA and how deep | Stops ordinary certificates from acting as authorities |
| Revocation and issuer locations | Where to find cancellation lists and issuer certificates | Lets verifiers check validity and build the chain |
| Signature | The issuer’s seal | Proves the content was not changed |
A certificate that lives for hours or days is far less dangerous if stolen than one that lives for years. Modern designs prefer short-lived certificates that are renewed automatically.
A certificate is like a passport page. It has your photo (public key), your name (subject), an issuing country (issuer), an expiry date (validity), a list of visa types (key usage) and a hologram that is hard to copy (signature).
4Private Versus Public Certificates
Beginners often wonder why they would run their own authority when public ones already exist.
Two different worlds of trust
Public certificates are issued by authorities that web browsers and operating systems already trust, so any visitor can open your public website without warnings. Private certificates are issued by an authority that only your organization trusts. Nobody outside your company has your root installed, so a private certificate means nothing to the outside world, and that is exactly the point. It is perfect for things the outside world never needs to see.
Google Cloud offers different services for these two worlds. Certificate Manager is used to obtain and attach public certificates, for example to a load balancer that serves a website. Certificate Authority Service is used to run your own private authority and issue private certificates. They are complementary, and a typical company uses both.
| Question | Public certificates | Private certificates with CAS |
|---|---|---|
| Who trusts them? | Everyone, through built-in browser lists | Only systems that you configure |
| Typical use | Public websites and APIs | Internal services, devices, workloads |
| Who sets the rules? | Industry standards and the public authority | You, through policy and templates |
| Name rules | Must be verifiable public names | Any internal naming you choose |
| Lifetime | Limited by industry rules | Your choice, from minutes to years |
| Google service | Certificate Manager and related services | Certificate Authority Service |
Why not use public certificates everywhere?
Internal hosts often have names the public internet cannot verify, and many devices and services need hundreds of thousands of short-lived certificates. Public authorities have strict rules and rate limits that make this impractical, while a private authority gives you full control.
A public certificate is an international passport accepted by every country. A private certificate is a company staff badge, accepted only inside your own buildings. You would not use a staff badge to cross a border, and you would not print international passports just to enter the cafeteria.
5Architecture and Main Components
CAS is built from a handful of resources, each with one clear job.
The big picture
At the top of your design are one or more CA pools. A pool is a container that holds several certificate authorities and presents them as one issuing service. Inside the pool are the authorities themselves, which may be roots or subordinates. Each authority has a signing key stored in Cloud Key Management Service, which may be backed by protected hardware. Rules for what may be issued sit in two places: an issuance policy on the pool and optional certificate templates. Revocation information and issuer certificates are published to Cloud Storage. Clients such as applications, service meshes and automation tools send requests to the pool, which signs and returns certificates.
flowchart LR
CL["Clients: apps, mesh, automation"] --> POOL["CA Pool"]
POOL --> POL["Issuance Policy"]
POOL --> TPL["Certificate Templates"]
POOL --> CA1["CA One"]
POOL --> CA2["CA Two"]
CA1 --> KMS["Cloud KMS or HSM Keys"]
CA2 --> KMS
CA1 --> GCS["Cloud Storage: CA certs and CRLs"]
CA2 --> GCS
POOL --> LOG["Audit Logs"]
Each piece in one line
The pool is the front door and choice of authority. The authorities sign. The keys prove the authority is real and are never exported. The policy and templates limit what may be issued. Storage publishes the lists and certificates that outsiders need to verify the chain. Audit logs record every action so nothing happens in secret.
A pool is like a passport office with several counters. Visitors approach the office, not a specific clerk. Behind the counters sit the clerks (authorities) who each hold a stamp in a shared vault (keys), following one rulebook (policy), and every action is written in a ledger (logs).
6CA Pools in Depth
The pool is the unit that applications actually talk to, which makes it the most important design choice after the hierarchy itself.
What a pool does
A CA pool groups multiple authorities that share the same rules and the same access controls. When a request arrives, the pool picks one of its enabled authorities to sign, so you can add a new authority or retire an old one without any application noticing. Applications and access rules refer to the pool, not to an individual authority.
What belongs in a pool
The sensible rule is that authorities in one pool should be interchangeable. They should serve the same purpose, follow the same policy and be trusted by the same clients. A pool for production workloads should not mix with a pool for experiments, because the policies and the people who may use them differ. Pools are created in a specific region, so choose one close to the systems that will request certificates, and consider more than one region for resilience.
Pool-level settings
A pool carries the tier, which controls cost and features, and it holds the issuance policy, which sets limits such as allowed key types, maximum certificate lifetime and rules about names. It can also be configured for whether revocation lists and issuer certificates are published. Access control is applied at the pool level, so granting someone permission to request certificates from a pool lets them use any authority in it.
graph TD
P["CA Pool: Production Services"] --> A["Issuing CA 2026 A"]
P --> B["Issuing CA 2026 B"]
P --> OLD["Retiring CA 2025"]
APP["Application Requests Certificate"] --> P
Because clients ask the pool rather than a named authority, you can add a fresh authority, let it begin signing, and later disable the old one without redeploying applications. This is the main reason pools exist.
Think of a taxi stand. Passengers join one queue at the stand and get whichever driver is available. The stand can add new drivers or retire old ones without passengers ever needing to learn their names.
7Root and Subordinate Authorities: Designing the Hierarchy
A good trust hierarchy limits the damage of any single compromise.
Why not just one authority?
If one authority both anchors trust and signs every certificate, it is used constantly, so it is exposed constantly. If it is ever compromised, every certificate you ever issued becomes suspect, and every client that trusted it must be updated. The standard answer is a hierarchy. The root authority is kept extremely protected and signs only a few subordinate authorities. The subordinates, sometimes in several layers, handle daily issuance. If a subordinate is compromised, you cancel it and replace it, while the root and everything beneath other branches stay safe.
Typical shapes
A common design has a root in its own protected pool, one or more intermediate authorities per business area or environment, and issuing authorities that sign the actual certificates. Smaller companies may use just a root and one subordinate. Very large ones may use many layers and regions. The number of layers allowed is controlled by the path length setting in each authority’s certificate.
Bringing your own root
Some organizations already have a corporate root, perhaps held offline or in another system. CAS lets a subordinate authority be created inside Google Cloud and signed by that external root. This allows the new service to slot into the existing chain of trust, so clients already trusting the corporate root automatically trust CAS-issued certificates, without any change on every device.
graph TD
ROOT["Root CA: rarely used, highly protected"] --> INT1["Subordinate: Production"]
ROOT --> INT2["Subordinate: Non-Production"]
INT1 --> ISS1["Issuing CA: Services"]
INT1 --> ISS2["Issuing CA: Devices"]
INT2 --> ISS3["Issuing CA: Test Workloads"]
ISS1 --> C1["Service Certificates"]
ISS2 --> C2["Device Certificates"]
ISS3 --> C3["Test Certificates"]
Problem
Using the root authority to sign everyday certificates directly.
Why It’s Harmful
The most sensitive key is exposed all day. One mistake or breach forces you to replace trust on every client in the company.
Correct Approach
Keep the root separate and rarely used, and let subordinate issuing authorities handle all routine signing.
The root is the national treasury’s master seal, kept in a vault and used once in a while. Regional offices hold their own seals, authorized by the master. If a regional seal is stolen, you cancel that one office, and the national treasury is untouched.
8The Two Tiers: DevOps and Enterprise
CAS offers two service tiers, and the choice shapes cost, speed and features.
DevOps tier
The DevOps tier is designed for very high volumes of short-lived certificates, such as those used by containers, microservices and automated pipelines. It is optimized for speed and a lower price per certificate. To achieve that, it makes some trade-offs. Certificates are typically not stored or listed by the service afterwards, and revocation is not offered, since the certificates live so briefly that waiting for expiry is a better answer.
Enterprise tier
The Enterprise tier is designed for lower volumes of longer-lived certificates, such as those for servers, devices, people and code signing. It stores certificates, lets you list and look them up later, and supports revocation with published cancellation lists. It costs more per certificate and issues at a lower rate.
| Feature | DevOps tier | Enterprise tier |
|---|---|---|
| Best for | High-volume, short-lived workloads | Long-lived, managed certificates |
| Typical lifetime | Minutes to days | Months to years |
| Revocation | Not supported | Supported |
| Certificate storage and lookup | Not kept for later lookup | Kept and searchable |
| Issuance rate | Very high | Moderate |
| Relative price per certificate | Lower | Higher |
Choosing the tier by price alone. If you later discover you need revocation or certificate lookup for compliance, you cannot simply flip a switch on an existing pool. The tier is chosen when the pool is created, so decide with your requirements in front of you.
A natural pairing
Many organizations create an Enterprise pool for their long-lived subordinate authorities and device certificates, and a separate DevOps pool for the ocean of short-lived workload certificates, each under a shared root.
The DevOps tier is like day-pass tickets handed out by the thousand at an amusement park gate. They expire tonight, so nobody records or cancels them. The Enterprise tier is like annual membership cards, which are recorded, can be cancelled early and cost more to issue.
9Protecting the Keys: Cloud KMS, HSM and External Keys
The whole system is only as trustworthy as the private keys of its authorities, so key protection is the heart of the design.
Where authority keys live
Each authority has a private signing key, and that key is held in Cloud Key Management Service. The signing happens inside the key service, so the raw key material is never handed to CAS or to any administrator. The authority simply asks the key service to sign, and receives a signature back.
Protection levels
Keys can be protected at different levels. Software-protected keys are stored by the key service and are suitable for many uses. Hardware-protected keys live inside certified hardware security modules, which are tamper-resistant devices built to resist extraction. Keys can also be held outside Google altogether and used through an external key manager, which suits organizations with strict rules about who controls key material. Higher protection generally costs more, so reserve the strongest options for the most valuable keys, such as roots.
Software Keys
Managed in the key service with strong controls and the lowest cost, good for lower-risk issuing authorities.
Hardware Security Module Keys
Generated and used inside certified hardware designed to resist physical and logical theft.
External Key Manager Keys
Held and controlled outside Google for organizations that must keep full authority over their key material.
Algorithms and sizes
Authorities can use common signing algorithms in a variety of strengths. Stronger and newer algorithms offer better security margins, but every client that must verify the chain needs to support them, so compatibility with older devices should be checked before choosing.
Because keys live in the key service, the people who manage keys can be different from the people who manage certificate issuance. Use that separation so that no single person can both control the key and issue arbitrary certificates.
The authority’s key is like the master stamp kept in a bank vault. Clerks never hold the stamp. They hand a document through a window, the vault staff stamp it inside, and the stamped document comes back. Nobody walks out with the stamp.
10Certificate Templates and Issuance Policies
Rules are what turn a signing machine into a safe service. These two tools define what may and may not be issued.
Issuance policy
The issuance policy is attached to a pool and acts as the outer fence. It can limit which key types and sizes are acceptable, set a maximum certificate lifetime, restrict which kinds of names may appear and control whether requesters may supply their own values for certain fields. Anything outside the policy is rejected, no matter who asked.
Certificate templates
A template is a reusable recipe. It can predefine values such as the key usages, extended key usages and certain extensions, and it can restrict which of those a requester is allowed to change. A template for web servers will say “this certificate is for proving a server’s identity” and nothing else, while a template for employee laptops will say “this certificate proves a client’s identity”. Requesters who use a template get consistent, correct certificates without needing to understand the details.
Policies and templates together
Think of the policy as the law of the land and templates as approved forms. The law sets boundaries for everyone. A form fills in the right values for one job. You can also control who may use which template through access rules, so only the right people can request the most powerful kinds of certificates.
| Tool | Scope | Purpose | Example |
|---|---|---|---|
| Issuance policy | Whole pool | Set hard limits for everything issued | No certificate longer than ninety days |
| Certificate template | One kind of certificate | Predefine values for a specific purpose | Server identity only, with fixed key usages |
| Name constraints | Authority level | Limit which domains an authority may certify | Only internal company names |
Constraining a subordinate
A subordinate authority for one business unit can be restricted so it can only issue certificates for that unit’s internal names. Even if it is compromised, it cannot produce a believable certificate for another unit’s systems.
Leaving the policy wide open and relying on requesters to behave. A request is only as safe as the strictest rule that applies to it, so set tight defaults and loosen deliberately.
The issuance policy is the law that says no passport may be valid longer than ten years. A template is the standard application form for a tourist visa, already filled in with the correct category. Both protect the office from mistakes and abuse.
11Internal Working: How a Certificate Is Issued
Follow one application from needing a certificate to using it.
The requester creates a key pair
The application generates its own private and public keys. The private key stays with the application and is never sent anywhere.
A signing request is built
The application packages its name and public key into a certificate signing request, signed with its private key to prove it holds it.
The request reaches the pool
The application calls the service with its Google identity. CAS first checks that the caller is permitted to request certificates from that pool.
Policy and template are applied
The service merges the request with the template, then checks the result against the issuance policy. Anything outside the rules is rejected here.
An authority signs
The pool chooses an enabled authority, which asks its protected key to sign the final certificate content.
The certificate and chain are returned
The application receives its certificate plus the chain of issuer certificates, installs them and begins using them. The action is written to audit logs.
sequenceDiagram
participant App as Application
participant Pool as CA Pool
participant Pol as Policy and Template
participant CA as Issuing CA
participant Key as Cloud KMS Key
App->>App: Generate key pair and request
App->>Pool: Submit signing request
Pool->>Pool: Check caller permission
Pool->>Pol: Apply template and policy
Pol-->>Pool: Approved content
Pool->>CA: Sign certificate
CA->>Key: Ask key to sign
Key-->>CA: Signature
CA-->>Pool: Signed certificate
Pool-->>App: Certificate plus chain
How the other side verifies
When the application later connects to another system, it presents the certificate and chain. The other system checks the signatures link by link up to a root it already trusts, checks that the dates are valid, checks that the purpose fits, and on the Enterprise tier can check whether the certificate has been cancelled. If all checks pass, the connection proceeds.
The private key never leaves the requester and never reaches CAS. CAS signs a public statement about the key, so even the service itself cannot impersonate your workloads.
12Revocation and Certificate Revocation Lists
Sometimes a certificate must be cancelled before it expires, and the world needs a way to find out.
Why revocation exists
If a certificate’s private key is stolen, or an employee leaves, or a device is lost, waiting for the certificate to expire naturally could leave a long window of risk. Revocation lets the authority declare “this certificate is no longer valid” immediately.
How CAS handles it
On the Enterprise tier, you can revoke a certificate and give a reason, such as key compromise or the system being retired. The authority records this and periodically publishes a certificate revocation list, a signed list of cancelled certificate numbers, into a Cloud Storage location. Certificates carry the address of this list, so verifying systems can fetch it and refuse any certificate that appears on it.
The weakness of lists
Revocation lists have a known weakness: a verifier may use an old copy, or fail to fetch the list and carry on anyway. That is why short lifetimes are a more reliable safeguard than revocation alone. If a certificate lives for only a few hours, the risk window is small even if nobody notices the theft. The DevOps tier takes this approach to the extreme by avoiding revocation entirely.
Revocation Advantages
- Lets you cancel a stolen or retired certificate immediately
- Gives auditors a visible record of cancellations
- Fits long-lived certificates for servers and people
- Published lists work with standard verifying software
Revocation Trade-offs
- Lists are only refreshed periodically, so there is a delay
- Verifiers may use cached or skipped checks
- Not available on the DevOps tier
- Requires keeping published storage reachable
A revocation list is the printed bulletin of cancelled passports that border guards check. It is updated at set times, so a very recent cancellation might not yet be on the guard’s copy. Passports that expire within hours simply avoid the problem.
13Authority Lifecycle, States and Rotation
Authorities are not permanent. They are created, used, retired and replaced, and planning that life prevents emergencies.
States an authority moves through
An authority begins either awaiting activation, when it needs a signed certificate from a higher authority, or staged, when it exists but is not yet allowed to issue. Once enabled, it issues certificates. It can be disabled to temporarily stop issuing, and it can be scheduled for deletion, during which there is a recovery window before it is removed permanently. Knowing these states helps you control exactly when an authority begins and ends its work.
Create
Define the authority, its key, its name and its lifetime. A subordinate may wait for its parent to sign.
Activate
Complete the signing of its own certificate and place it into service in a pool.
Issue
The authority signs certificates for workloads, devices and people under policy.
Rotate
Well before expiry, a new authority joins the pool and begins issuing, while clients are updated to trust it if needed.
Retire
The old authority is disabled once the certificates it issued have expired or been replaced.
Delete
After a safe period, the authority is deleted, with a recovery window protecting against accidents.
Planning the lifetimes
The rule of thumb is that each layer lives longer than the layers beneath it. A root may live for ten years or more, intermediate authorities for several years and issuing authorities for a shorter period, while the certificates they sign live for the shortest time of all. An authority must always outlive the certificates it signs, so rotation must begin early enough for the old one to fade out naturally.
Forgetting that an authority’s own certificate expires. When it does, everything it issued stops being trusted at the same moment. Put expiry dates for every authority on a calendar with alerts months ahead.
Authority rotation is like replacing a bridge while traffic keeps flowing. You build the new bridge beside the old one, open it, move the traffic over gradually and only then close the old bridge, never before.
14Security, Access Control and Governance
A certificate authority is a high-value target, because whoever controls it can mint trust.
Roles that separate duties
Access is managed through Identity and Access Management with roles designed for specific jobs. Administrators manage authorities and pools. Operators handle day-to-day operations such as enabling and disabling. Auditors may only read. Requesters may ask for certificates, and some roles also allow managing issued certificates, including revoking them. Workload-focused roles allow a program to request certificates that represent its own identity. By splitting these jobs across different people and groups, you prevent any single account from doing everything.
| Job | Can do | Should be held by |
|---|---|---|
| Service administrator | Create and delete authorities, pools and templates | A very small security or platform team |
| Operations manager | Enable, disable and manage authorities and certificates | Operations staff |
| Auditor | View settings and records, change nothing | Compliance and review teams |
| Certificate requester | Ask the pool to issue certificates | Applications, automation and approved users |
| Certificate manager | Issue and revoke certificates | Trusted operators or tightly controlled processes |
Additional protections
Grant requester access to groups and workload identities rather than to individuals. Keep roots in a separate project and pool with very few people having access. Use a perimeter such as VPC Service Controls to limit where the service can be reached from. Protect the published storage location so only the authority can write to it while verifiers can read it. Require approvals for creating or deleting authorities.
Giving broad certificate manager rights to developers so they can fix problems fast. That permission can mint a certificate for almost any internal name. Keep powerful roles narrow and temporary.
The people who may print passports, the people who may review the log of printed passports and the people who may order the master stamp replaced should be different people. If one person can do all three, nobody is watching the watcher.
15Where Certificates Are Used: Integrations
CAS is only useful when workloads can easily obtain and renew certificates, and it connects to many Google Cloud and open-source tools.
Service meshes
A service mesh adds encrypted, mutually authenticated connections between microservices. It can obtain its workload certificates from CAS, giving every service a short-lived identity and encrypting all traffic between services automatically.
Kubernetes certificate automation
Popular Kubernetes tools can request, renew and install certificates for applications. An issuer plugin lets them use CAS as the source, so developers simply ask for a certificate and the platform handles the rest.
Workload identity certificates
Google Kubernetes Engine can issue certificates that represent a workload’s own identity, enabling strong mutual authentication without passwords or long-lived keys.
Load balancers and internal gateways
Internal load balancers and gateways can present certificates from a private authority, with internal clients trusting your root, so internal applications get encrypted entry points without public certificates.
Devices, virtual machines and automation
Virtual machines, network devices and automation tools can request certificates through the service interface or standard enrollment protocols that CAS supports through partner tooling, depending on configuration.
Code and document signing
Longer-lived certificates from the Enterprise tier can be used to sign software releases or documents, so recipients can verify the origin and detect tampering.
flowchart LR
MESH["Service Mesh Workloads"] --> POOL["CAS Pool"]
K8S["Kubernetes Certificate Automation"] --> POOL
VM["Virtual Machines and Devices"] --> POOL
LB["Internal Load Balancers"] --> POOL
POOL --> CERT["Short-lived Private Certificates"]
CERT --> MTLS["Mutual TLS Between Services"]
Issuing certificates is only half the job. Every client that needs to verify them must trust your root, so plan how the root certificate is distributed to servers, containers, devices and laptops.
16Auditing, Logging and Monitoring
If an authority is misused, you need to know quickly, and you need evidence afterward.
Audit logs
Administrative actions such as creating an authority, changing a policy or revoking a certificate are recorded in audit logs automatically. Data access logs can also record who requested certificates and from which pool, though these must be enabled and can be large in high-volume environments. Together they let you answer who asked for which certificate and when.
Monitoring the service
Metrics about issuance volume, errors and latency flow into the monitoring service, where dashboards and alerts can be built. Sudden spikes in issuance, repeated denials or requests from unexpected identities are classic warning signs of abuse or misconfiguration.
Authority Creation or Deletion
These should be rare. An unexpected event is a strong signal of trouble.
Policy and Template Changes
A loosened policy can quietly widen what may be issued.
Issuance Spikes
A sudden surge may mean a runaway process or an attacker minting certificates.
Revocations
Unexpected cancellations can reveal an incident or an operational mistake.
Approaching Expiry
Authority certificates nearing their end need early action, long before they fail.
Treating certificate expiry as an unimportant detail. Expired certificates are one of the most common causes of sudden outages. Monitor expiry for both authorities and the certificates they issue.
Audit logs are the ledger of the passport office, written automatically. Monitoring is the manager watching the counter for strange rushes, like a hundred passports requested in one minute by the same person.
17Design Patterns for Certificate Architecture
Experienced teams reuse a few well-tested layouts.
Protected Root Pattern
The root lives alone in its own project and pool, is used only to sign or rotate subordinates, and is disabled the rest of the time. Very few people can reach it, and every use is a planned, approved event.
Two-tier Pattern
An Enterprise-tier subordinate with revocation handles long-lived certificates, while a DevOps-tier subordinate handles high-volume short-lived ones. Both sit under the same root so clients trust a single anchor.
Per-environment Pattern
Production, staging and development each have separate pools and subordinates. A certificate from the test environment cannot be mistaken for a production one, and a compromise stays contained.
Regional Resilience Pattern
Pools are created in more than one region so that a regional problem does not stop certificate issuance, with workloads requesting from the nearest healthy region.
Bring-your-own-root Pattern
An existing corporate root signs a CAS subordinate, so existing devices already trust the new authority and migration needs no mass reconfiguration.
flowchart TD
ROOT["Root CA in Protected Project"] --> ENT["Enterprise Subordinate: long-lived certificates"]
ROOT --> DEVOPS["DevOps Subordinate: short-lived workload certificates"]
ENT --> SRV["Servers and Devices"]
ENT --> SIGN["Code Signing"]
DEVOPS --> POD["Containers and Microservices"]
Anti-patterns to avoid
Problem
Issuing certificates that last for many years to workloads that could renew automatically.
Why It’s Harmful
A stolen key stays useful for years, and revocation lists cannot be relied on to fix that quickly.
Correct Approach
Issue short-lived certificates and automate renewal, so theft has little value and expiry becomes the safety net.
Problem
Putting every environment and purpose into one pool with one wide-open policy.
Why It’s Harmful
A test application could obtain a certificate that production systems trust, and access control cannot be tuned per purpose.
Correct Approach
Separate pools by environment and purpose, each with its own policy and access rules.
18Understanding and Controlling Cost
CAS pricing follows what you run and what you issue, so cost control is mostly about matching design to need.
What you pay for
At the time of writing, costs come from three main places. First is a monthly charge for each authority that exists, which differs by tier and is higher for the Enterprise tier. Second is a charge per certificate issued, which is much lower on the DevOps tier. Third is the cost of the related services, namely key protection in Cloud KMS or hardware modules, and storage for published lists and certificates. Exact prices change, so always check the official pricing page before budgeting.
Ways to spend wisely
Use the right tier
Send high-volume short-lived workloads to the DevOps tier and keep the Enterprise tier for certificates that truly need storage and revocation.
Do not run idle authorities
Remove or disable test and abandoned authorities, since each existing authority carries a recurring charge.
Match key protection to risk
Use hardware-backed keys for roots and important authorities, and software keys where the risk is lower.
Avoid unnecessary issuance
Reuse certificates sensibly and prevent runaway automation that requests far more than needed.
Watch the volume
Alert on sudden jumps in issuance, which protects both the budget and security.
Saving money by weakening key protection or lengthening certificate lifetimes. The savings are small compared with the cost of a compromised authority, so cut waste elsewhere first.
19Best Practices and Common Mistakes
A short checklist of habits that separate calm teams from those fighting certificate emergencies.
Best practices
Design the hierarchy first
Decide on root, subordinates, tiers and lifetimes before issuing anything, since the foundation is hard to change later.
Protect the root
Keep it in a separate project, use strong key protection, and use it only for planned events.
Prefer short-lived certificates
Automate renewal so that expiry, not revocation, is your main safety net.
Set tight policies and templates
Limit lifetimes, key types and names, and constrain subordinate authorities to the names they should serve.
Separate duties
Use different people for administration, issuance and audit, and grant access to groups and workload identities.
Plan rotation early
Track authority expiry dates and start rotation months ahead, with trust store updates tested.
Log, monitor and rehearse
Alert on sensitive changes and practice the response to a compromised authority before it happens.
Common mistakes
Picking a tier without considering revocation, storage and volume needs, and having to rebuild the pool later.
Creating a perfect authority but forgetting to distribute its root to clients, so nothing verifies.
Having no rehearsed plan for a compromised or expired authority. In an emergency, teams discover that replacing trust on every client takes days, not minutes.
If the location holding cancellation lists or issuer certificates becomes unreachable or is modified by the wrong people, verification fails or becomes unsafe. Protect and monitor it.
20Real-world and Industry Scenarios
Stories show how the pieces combine under real pressure.
A Fintech Encrypting Every Internal Call
A payments company runs hundreds of microservices. It uses a service mesh whose workload certificates come from a DevOps-tier pool, renewed every few hours. Every internal call is encrypted and mutually authenticated, and the audit team sees exactly which workload identity received each certificate.
A Manufacturer Securing Factory Devices
A manufacturer gives each machine on its factory floor a certificate from an Enterprise-tier authority, valid for a year. When a device is stolen from a plant, the certificate is revoked immediately and the device can no longer join the network.
A Bank Extending Its Existing Root
A bank already trusts an offline corporate root across thousands of devices. It creates a CAS subordinate signed by that root, so all existing devices trust the new cloud authority from day one without any mass update.
A Software Company Signing Releases
A software vendor uses a dedicated Enterprise-tier authority and hardware-backed key to sign its releases. Customers can verify the origin, and the keys are controlled by a tiny release engineering group with strict approvals.
A Healthcare Provider Meeting Regulation
A hospital group must prove that only authorized systems can reach patient data. It issues client certificates to approved systems from a pool constrained to internal names, requires them for access to sensitive services and keeps audit logs for its auditors.
21Advantages, Disadvantages and Trade-offs
No service is perfect, and a mature team knows both sides before committing.
Advantages
- Fully managed, with no certificate servers to patch or back up
- Keys protected in Cloud KMS, hardware modules or external managers
- Scales from a few certificates to very high volumes
- Fine-grained policy, templates and access controls
- Integrates with service meshes, Kubernetes and Google Cloud services
- Complete audit trail of issuance and administration
- Supports bringing your own root for existing trust chains
Disadvantages / Trade-offs
- Recurring charges per authority and per certificate
- The tier is fixed when a pool is created
- The DevOps tier offers no revocation or certificate lookup
- You must still distribute your root to every client
- Designing hierarchy and rotation needs real planning and expertise
Choosing your approach
| Need | Best fit | Why |
|---|---|---|
| Public website certificates | Public certificate service | Browsers already trust public authorities |
| Encrypt service-to-service traffic | DevOps-tier pool | Fast, cheap, short-lived certificates |
| Long-lived server or device certificates | Enterprise-tier pool | Storage, lookup and revocation |
| Extend an existing corporate root | Subordinate signed by your root | Existing clients already trust it |
| Strict control of key material | External key manager | Keys never leave your control |
Choosing how to run trust is like choosing how to issue badges. Day passes for thousands of visitors need a fast, cheap printer. Employee cards need a database and a way to cancel them. A government passport needs the strictest vault of all.
22Frequently Asked Questions
Quick answers to the questions beginners ask most often.
No. Certificate Authority Service lets you run your own private authority and issue private certificates. Certificate Manager is mainly about obtaining and attaching public certificates to Google Cloud load balancers and similar services.
Not for the public internet. CAS creates private authorities, so only systems that you configure to trust your root will accept their certificates. That makes it ideal for internal use.
A CA is a single authority with its own key and certificate. A pool is a container of several authorities that share rules and access controls, and it is what applications actually send requests to.
Choose the DevOps tier for large volumes of short-lived workload certificates, and the Enterprise tier when you need long-lived certificates with storage, lookup and revocation. Many organizations use both.
The tier is set when the pool is created and is not meant to be switched afterward. If your needs change, create a new pool of the other tier and migrate gradually.
Workload private keys never reach the service, since only a signing request is sent. Authority keys are held in the key service, where signing is performed without exporting the key, and you can choose hardware or external key protection for extra assurance.
You disable it, issue a replacement from the layer above, and revoke affected certificates where the tier allows. A good hierarchy and short lifetimes keep the damage small, and a rehearsed plan makes the response fast.
Yes. You can create a subordinate authority in Google Cloud and have your existing root sign it, so clients that already trust the root will trust certificates from the new authority.
As short as your automation can support. Workloads often use hours to days, while long-lived items such as servers or devices may use months to a year. Authorities live longer than the certificates they sign, and roots live longest of all.
A frequent cause is that an authority’s own certificate expired, which invalidates everything beneath it. Another is that clients do not trust the root or cannot reach the published lists. Check expiry dates and the trust store first.
Grant request permission to specific groups and workload identities, scoped to the pool they truly need. Keep the broader manager role, which can issue and revoke freely, for a very small and monitored group.
Often not, since expiry within hours limits the risk. Revocation matters most for long-lived certificates such as those on servers, devices and people, and the Enterprise tier supports it for those cases.
23Summary and Key Takeaways
Certificate Authority Service is the managed passport office for the private world inside your organization. It lets you build a hierarchy of root and subordinate authorities, group them into pools that applications can rely on, protect their keys in Cloud KMS, hardware modules or external managers, and control issuance through policies, templates and tight access roles. Two tiers match two very different needs: the DevOps tier for enormous volumes of short-lived workload certificates, and the Enterprise tier for longer-lived certificates with storage and revocation. Around the core service sit integrations with service meshes, Kubernetes and load balancers, plus audit logs and monitoring that make every action visible. The best designs share common habits: a protected root, layered subordinates, short-lived certificates, separated duties, early rotation planning and a rehearsed incident response. Teams that treat trust as a designed system, not an afterthought, enjoy encrypted and verified connections everywhere without constant firefighting.
Key Takeaways
- Private trust, managed — CAS runs your own certificate authority without servers to patch, with keys held in protected key services.
- Layer the hierarchy — keep a protected root that rarely signs, and let subordinate authorities handle daily issuance so one compromise stays contained.
- Use pools for stability — applications talk to the pool, so authorities can be added, rotated and retired without disturbing clients.
- Choose the tier deliberately — DevOps for high-volume short-lived certificates, Enterprise for storage, lookup and revocation, and decide before creating the pool.
- Short lifetimes beat revocation — automated renewal of short-lived certificates is the most reliable defense against stolen keys.
- Constrain and separate — tight issuance policies, templates, name constraints and split roles stop any one person or authority from minting arbitrary trust.
- Plan the whole lifecycle — track authority expiry, rotate early, distribute your root to every client and rehearse your response to a compromise.