Google Cloud Certificate Manager Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Security

by

Category

Security

1. Introduction

Google Cloud Certificate Manager is a managed service for provisioning, storing, and deploying SSL/TLS certificates used to encrypt traffic to internet-facing and internal endpoints—most commonly through Cloud Load Balancing.

In simple terms: Certificate Manager helps you get HTTPS working correctly and keep it working by centralizing certificates and automating issuance/renewal for supported certificate types.

Technically, Certificate Manager provides APIs and resources (such as certificates, certificate maps, and DNS authorizations) that let you attach the right certificate to the right hostname using SNI (Server Name Indication). It integrates tightly with Google Cloud networking entry points (such as target proxies behind Cloud Load Balancing), so certificates can be rolled out and rotated without manually touching individual backends.

The problem it solves is operational and security-oriented: managing certificates at scale is error-prone (expired certs, wrong hostnames, missed renewals, inconsistent deployment). Certificate Manager reduces these risks with a managed, policy-driven workflow and consistent integrations.

2. What is Certificate Manager?

Official purpose (scope and intent)
Certificate Manager is a Google Cloud service for managing SSL/TLS certificates and deploying them to supported Google Cloud endpoints (primarily load balancers/proxies) using a centralized, API-driven model.

Core capabilities – Provision Google-managed SSL/TLS certificates (domain-validated) where supported. – Store and deploy self-managed certificates (you provide the cert chain and private key). – Map certificates to hostnames using certificate maps and map entries (SNI routing). – Perform domain control validation using DNS authorizations (for managed cert issuance workflows that require it).

Major components (mental model) – Certificate: Represents a TLS certificate. Can be Google-managed (issued/renewed by Google) or self-managed (uploaded by you). – DNS Authorization: A resource used to prove you control a domain via a DNS record (record details are provided by the service). – Certificate Map: A routing object that selects which certificate to present based on the requested hostname (SNI). – Certificate Map Entry: A hostname (or hostname pattern, depending on product support) mapped to one or more certificates.

Service type – Managed control plane service (API-first), integrated with Google Cloud networking datapaths (for example, load balancer target proxies). – Not a general-purpose PKI/CA by itself. For private CA capabilities, Google Cloud provides Certificate Authority Service (a different product).

Resource scope (global/regional/project) – Certificate Manager resources are project-scoped and created in a location (commonly global, and in some cases regional—depending on the target integration).
Because location and supported integrations can evolve, verify the correct location (global vs regional) for your specific load balancer/proxy type in the official docs.

How it fits into the Google Cloud ecosystem – Pairs naturally with: – Cloud Load Balancing (HTTPS and SSL/TLS termination) – Cloud DNS (to publish the required validation records and A/AAAA records) – Cloud Logging / Cloud Audit Logs (for operations and change tracking) – IAM (fine-grained access to create/update certificates and maps) – Complements (but does not replace) other security services: – Secret Manager (general secret storage; not a certificate deployment system) – Certificate Authority Service (issuing private certs; separate lifecycle and pricing)

3. Why use Certificate Manager?

Business reasons

  • Reduces outage risk from expired/incorrect TLS certificates (a common production incident).
  • Centralizes certificate operations for many applications/domains across teams.
  • Supports standardization: consistent naming, ownership, and automation patterns.

Technical reasons

  • SNI-based routing via certificate maps makes multi-domain TLS on shared IPs straightforward.
  • Managed certificate lifecycle (where supported) minimizes manual issuance and renewal work.
  • A single certificate management workflow integrates with Google Cloud’s edge/load balancer architecture.

Operational reasons

  • API-driven management integrates cleanly into CI/CD and Infrastructure as Code (Terraform is commonly used; verify the latest provider resources).
  • Enables safer rotation practices: update map entries and roll forward/back quickly.
  • Separation of duties: security team controls certs, platform team controls load balancers, app team controls backends.

Security / compliance reasons

  • Helps enforce HTTPS everywhere with consistent certificate handling.
  • Makes it easier to implement least privilege for certificate operations using IAM roles.
  • Improves auditability: changes to certificates and maps can be captured in audit logs.

Scalability / performance reasons

  • Designed for scale: many hostnames and applications can share load balancing infrastructure with correct certificate selection.
  • Works with Google Cloud’s global networking where supported, reducing operational burden.

When teams should choose it

Choose Certificate Manager when: – You terminate TLS on Cloud Load Balancing and want centralized certificate management. – You need to host many domains on one or more load balancers and want clean SNI mapping. – You want to reduce manual certificate renewal/rotation risk.

When teams should not choose it

Consider alternatives when: – You need a full private PKI/CA (use Certificate Authority Service). – Your endpoint is not supported for attachment via Certificate Manager (some Google Cloud products manage certificates in their own way). – You need advanced certificate lifecycle logic tightly coupled to Kubernetes ingress controllers (in GKE, you may prefer cert-manager depending on architecture—though you can still integrate with Google Cloud load balancing in some models).

4. Where is Certificate Manager used?

Industries

  • SaaS and web platforms (multi-tenant domains)
  • Financial services and insurance (strict change control and audit needs)
  • Healthcare (compliance-driven transport security)
  • Media/e-commerce (global HTTPS delivery, CDN fronting)
  • Education and public sector (standardized security posture)

Team types

  • Platform engineering teams operating shared load balancers
  • Security engineering teams enforcing encryption standards
  • SRE/operations teams responsible for uptime and incident response
  • DevOps teams implementing IaC and CI/CD pipelines

Workloads and architectures

  • Public web apps behind external HTTPS load balancers
  • APIs behind HTTPS load balancers (REST/gRPC over TLS termination)
  • Multi-domain frontends (many hostnames on a shared global IP)
  • Shared “edge” projects where central networking teams manage ingress

Real-world deployment contexts

  • Central certificate inventory per environment (dev/stage/prod)
  • Multi-project organizations using shared VPC and centralized ingress projects (attachment patterns vary; verify supported cross-project patterns and IAM requirements in docs)
  • Gradual migration from legacy/“classic” load balancer certificate objects to Certificate Manager certificate maps

Production vs dev/test usage

  • Production: primary value is reliability (avoid expiry), change control, and auditability.
  • Dev/test: useful for rehearsing certificate rotations and validating DNS authorization workflows; cost is typically dominated by load balancer runtime rather than certificate objects.

5. Top Use Cases and Scenarios

Below are realistic scenarios where Google Cloud Certificate Manager is commonly used.

1) Centralized HTTPS for many microservices (shared load balancer)

  • Problem: Each service team manages its own certificates and renewal schedule; outages occur due to expiration.
  • Why Certificate Manager fits: Central certificate provisioning and mapping per hostname.
  • Example: api.example.com, billing.example.com, auth.example.com all terminate TLS on one external HTTPS load balancer using a certificate map.

2) Multi-tenant SaaS with customer custom domains

  • Problem: Customers bring custom domains; onboarding requires adding/rotating certificates at scale.
  • Why it fits: Certificate maps support clean hostname-to-certificate selection.
  • Example: customer-a.app.com and shop.customer-b.com each map to the right cert without separate load balancers.

3) Standardized certificate rotation playbooks

  • Problem: Rotations are risky, manual, and inconsistent.
  • Why it fits: Rotate by updating certificate resources and map entries, then validate.
  • Example: Replace expiring cert with a new one, update map entry, roll back if needed.

4) Strict change control and separation of duties

  • Problem: App teams shouldn’t handle private keys; security team needs control.
  • Why it fits: IAM can restrict who can upload self-managed certs and who can attach maps.
  • Example: Security team manages Certificate Manager; platform team manages load balancers; app team only deploys backend services.

5) Migration from legacy load balancer SSL certificate objects

  • Problem: Existing load balancers use legacy certificate attachments; managing multiple certs becomes messy.
  • Why it fits: Certificate maps provide a cleaner, scalable model for SNI-based host routing.
  • Example: Migrate from “classic” compute ssl-certificates attachments to Certificate Manager map-based attachments.

6) Blue/green certificate rollouts (risk reduction)

  • Problem: A new cert chain causes client compatibility issues; need safe rollback.
  • Why it fits: You can maintain multiple certs and switch mapping.
  • Example: Test new intermediate chain on a subset of hostnames, then expand.

7) Central inventory and audit of certificates

  • Problem: Certificates are scattered across teams and tooling; no clear owner.
  • Why it fits: Certificates and maps are first-class resources; changes are auditable.
  • Example: Compliance team reviews certificate list, domains, and rotation schedules.

8) Rapid incident response (revoke/replace compromised cert)

  • Problem: Private key compromise requires immediate replacement and re-deployment.
  • Why it fits: Upload replacement cert/key and re-map quickly.
  • Example: Emergency rotate the cert used by login.example.com with minimal service disruption.

9) Consistent TLS termination for static sites and APIs

  • Problem: Different platforms have different certificate mechanisms; inconsistent.
  • Why it fits: Unify TLS at the load balancer edge.
  • Example: Static assets in Cloud Storage and APIs in Cloud Run both served under www.example.com via one LB with Certificate Manager.

10) Sandbox environments that mimic production TLS topology

  • Problem: Dev/test environments don’t match production TLS setup, so issues appear late.
  • Why it fits: Same certificate map model and attachment workflow can be used in non-prod.
  • Example: Stage environment uses its own domain and Certificate Manager resources to test rotations.

6. Core Features

Note: Google Cloud evolves quickly. For any feature’s exact availability by load balancer type/region, verify in official docs.

6.1 Google-managed certificates (where supported)

  • What it does: Google provisions and renews domain-validated certificates for your domains.
  • Why it matters: Eliminates renewal outages and most manual CA work.
  • Practical benefit: Fewer pager incidents and less operational toil.
  • Caveats: Requires domain control validation and correct DNS/routing. Provisioning time can be non-instant.

6.2 Self-managed certificates (upload your own)

  • What it does: You upload a certificate chain and private key (PEM) to be deployed via supported integrations.
  • Why it matters: Supports enterprise PKI, custom chains, and migration scenarios.
  • Practical benefit: Keep using your preferred CA while still centralizing deployment.
  • Caveats: You are responsible for renewal and key management practices.

6.3 Certificate maps (SNI-driven certificate selection)

  • What it does: A certificate map selects the right certificate based on the hostname requested by the client (SNI).
  • Why it matters: You can host multiple domains on the same IP/load balancer cleanly.
  • Practical benefit: Reduce infrastructure sprawl and simplify operations.
  • Caveats: You must design hostname coverage carefully (overlaps, default behavior). Verify wildcard/priority behavior in docs.

6.4 Certificate map entries (hostname routing rules)

  • What it does: Each entry maps a hostname (or supported hostname pattern) to one or more certificates.
  • Why it matters: Fine-grained control over which cert is presented for each hostname.
  • Practical benefit: Per-domain rotations and migrations without changing the load balancer topology.
  • Caveats: Limits/quotas apply (number of entries, hostnames, etc.); verify current quotas.

6.5 DNS authorizations (domain control validation)

  • What it does: Provides a DNS record you publish to prove you control a domain for managed certificate issuance.
  • Why it matters: Domain validation is required for public-trust managed certs.
  • Practical benefit: Repeatable, auditable validation workflow.
  • Caveats: DNS delegation and propagation issues are the most common cause of provisioning delays.

6.6 API-driven lifecycle + IAM integration

  • What it does: Manage resources through Google Cloud Console, gcloud, REST APIs, and IaC tools.
  • Why it matters: Automation and guardrails reduce manual mistakes.
  • Practical benefit: CI/CD pipelines can update certificates/maps safely with approvals.
  • Caveats: Use least-privilege roles; avoid granting broad Owner access.

6.7 Integration with Cloud Load Balancing (primary integration)

  • What it does: Attach certificate maps to supported load balancer target proxies so traffic gets the correct certificate.
  • Why it matters: Load balancers are the common TLS termination point.
  • Practical benefit: Central TLS at the edge with consistent behavior.
  • Caveats: Not every Google Cloud product endpoint uses Certificate Manager; verify supported targets.

7. Architecture and How It Works

High-level architecture

Certificate Manager sits in the control plane: 1. You create certificate-related resources (certificates, DNS authorizations, maps). 2. You attach a certificate map to a supported ingress datapath (typically a load balancer target proxy). 3. Google’s edge/load balancing infrastructure presents the correct certificate during TLS handshake based on SNI.

Request / data / control flow

  • Control plane flow
  • Admin/operator uses Console/CLI/API to create:
    • DNS authorization → publish DNS record
    • Certificate → becomes ACTIVE after validation/issuance (managed) or immediately stored (self-managed)
    • Certificate map + entry → connect hostname → certificate
  • Attach certificate map to target proxy
  • Data plane flow
  • Client connects to load balancer IP/hostname.
  • TLS handshake includes SNI hostname.
  • Load balancer selects the certificate from the certificate map entry and presents it.
  • After TLS termination, HTTP(S) request routes to backends (VMs, NEGs, backend bucket, etc.).

Integrations with related services

  • Cloud Load Balancing: TLS termination and SNI selection via certificate maps.
  • Cloud DNS: Publish A/AAAA records and validation records for domain authorization.
  • Cloud Logging / Monitoring: Observe LB traffic, error rates, and operational events.
  • Cloud Audit Logs: Track who changed certificates/maps and when.

Dependency services

  • DNS provider (Cloud DNS or external) for validation records.
  • Load balancer/proxy resources for actual TLS serving.
  • Optionally your CA and secure key generation processes (for self-managed).

Security/authentication model

  • IAM governs management actions:
  • Creating/updating certificates and maps.
  • Viewing certificate metadata.
  • Private keys for self-managed certs are sensitive; treat upload permissions as highly privileged.

Networking model

  • Certificate Manager resources themselves are not “in your VPC.”
  • The certificates are used by Google-managed frontends (load balancing/edge) when attached.

Monitoring / logging / governance

  • Use Cloud Audit Logs to monitor:
  • Certificate creation/updates
  • Map and map entry changes
  • Permission denials (potential misconfigurations)
  • Use LB logs/metrics to detect:
  • TLS handshake failures
  • Sudden traffic drops after a certificate change

Simple architecture diagram (Mermaid)

flowchart LR
  A[Client Browser / API Client] -->|TLS + SNI hostname| B[Cloud Load Balancing<br/>Target HTTPS Proxy]
  B -->|Select cert via map| C[Certificate Manager<br/>Certificate Map]
  C --> D[Certificate<br/>(Google-managed or Self-managed)]
  B -->|HTTP to backend| E[Backend Service<br/>(VMs/NEGs/Cloud Run/etc.)]
  F[DNS Provider / Cloud DNS] -->|A/AAAA + validation records| A

Production-style architecture diagram (Mermaid)

flowchart TB
  subgraph Internet
    U[Users / Clients]
  end

  subgraph DNS
    DNSP[Cloud DNS / External DNS]
  end

  subgraph GoogleCloud[Google Cloud Project: edge-ingress-prod]
    IP[Global Static IP]
    FR[Forwarding Rule :443]
    THP[Target HTTPS Proxy<br/>--certificate-map]
    UM[URL Map]
    BKS[Backend Services / Backends]
    LOG[Cloud Logging / Monitoring]
    AUD[Cloud Audit Logs]
  end

  subgraph Certs[Certificate Manager]
    DMA[DNS Authorization]
    CERT[Certificate(s)]
    CM[Certificate Map]
    CME[Certificate Map Entries<br/>(hostnames)]
  end

  U --> DNSP
  DNSP -->|A/AAAA record| IP
  U -->|TLS + SNI| IP --> FR --> THP --> UM --> BKS

  THP -->|SNI lookup| CM --> CME --> CERT
  CERT -->|Managed cert validation| DMA
  DNSP -->|Publish validation record| DMA

  THP --> LOG
  Certs --> AUD
  GoogleCloud --> AUD

8. Prerequisites

Account / project requirements

  • A Google Cloud project with billing enabled.
  • A domain name you control (recommended for managed certificate labs).

Permissions / IAM roles

You can complete this tutorial with project-level permissions such as: – Certificate Manager: – roles/certificatemanager.admin (or least-privileged equivalent) – Load Balancing / Compute: – roles/compute.loadBalancerAdmin (or roles/compute.admin for broad labs) – Cloud DNS (if using Cloud DNS): – roles/dns.admin – Storage (if using a backend bucket lab): – roles/storage.admin (or narrower permissions for bucket creation and object upload)

In production, prefer least privilege and separation of duties.

Tools

  • Google Cloud CLI: gcloud
    Install: https://cloud.google.com/sdk/docs/install
  • Optional but useful:
  • openssl for certificate and TLS verification
  • dig or nslookup for DNS verification

Region availability

  • Certificate Manager and Cloud Load Balancing are broadly available, but specific combinations (global vs regional resources) can differ.
    Verify supported locations and target proxy types in official docs.

Quotas / limits

  • Quotas exist for certificates, maps, and entries, and for load balancer resources.
  • If you hit quota errors, request increases in the Google Cloud Console → Quotas.

Prerequisite services/APIs

Enable these APIs (minimum for this lab): – Certificate Manager API – Compute Engine API (for load balancer resources) – Cloud DNS API (optional, if you use Cloud DNS) – Cloud Storage API (optional, if you use a backend bucket)

9. Pricing / Cost

Certificate Manager cost is usually not the largest part of an HTTPS setup; Cloud Load Balancing runtime is commonly the main cost driver.

Official pricing sources (verify current SKUs)

  • Certificate Manager pricing: https://cloud.google.com/certificate-manager/pricing
  • Google Cloud Pricing Calculator: https://cloud.google.com/products/calculator

Because pricing and SKUs can change by date, feature, and location, do not rely on third-party blog numbers. Always confirm on the official pricing page.

Pricing dimensions to understand

Verify on the official pricing page, but expect costs to fall into categories such as: – Certificate Manager resource charges (if any) for: – Managed certificate lifecycle – Stored certificates and/or map entries – Dependent service charges (often larger): – Cloud Load Balancing (forwarding rules, data processing, rule evaluations, etc.) – Cloud DNS (zone and query charges) – Cloud Storage (object storage and egress, if you use backend buckets) – Data egress to the internet (varies by region and path)

Free tier

  • Google Cloud has various free tiers across products, but free tier eligibility is product-specific.
    Verify whether Certificate Manager has a free tier and what it covers on the official pricing page.

Main cost drivers (typical)

  1. Load Balancer hours and traffic volume (often dominant)
  2. Internet egress (serving content to users)
  3. Cloud DNS queries (especially at scale)
  4. Certificate inventory scale (number of certificates/domains, depending on pricing model)

Hidden / indirect costs

  • Keeping a load balancer running 24/7 for a small test can cost more than expected.
  • Enabling Cloud CDN or advanced LB features increases cost.
  • Operational overhead: time spent debugging DNS validation, managing domain delegation, and incident response.

Cost optimization tips

  • Use one shared load balancer where appropriate rather than many small ones.
  • Keep test environments short-lived; automate teardown.
  • Avoid enabling Cloud CDN for labs unless you need it.
  • Use a minimal backend (small static site) to validate TLS quickly.

Example low-cost starter estimate (how to think about it)

For a small lab: – 1 external HTTPS load balancer (running briefly) – 1 static backend bucket with a tiny page – Low traffic (a few test requests) – 1–2 domains for certificate testing

Your cost will largely be: – Load balancer runtime + any minimum resource charges – Small Cloud Storage + egress for test downloads – DNS zone/query charges if using Cloud DNS

Use the pricing calculator to model a one-day lab vs a full month.

Example production cost considerations

For production: – Many hostnames (multi-tenant), potentially many certificates – High throughput traffic (LB processing + egress) – DNS query volume (including health checking and client lookups) – Multi-region architecture (more LBs, more IPs, more rules) – Operational cost of managing keys/certs if self-managed

10. Step-by-Step Hands-On Tutorial

Objective

Provision and deploy an HTTPS certificate using Google Cloud Certificate Manager, attach it to a global external HTTPS load balancer via a certificate map, and validate TLS from a client.

Lab Overview

You will: 1. Create a minimal backend (static page in Cloud Storage) and an external HTTPS load balancer. 2. Reserve a global IP for the load balancer. 3. Create Certificate Manager resources: – DNS authorization (for managed certificate) – Managed certificate – Certificate map and map entry 4. Attach the certificate map to the target HTTPS proxy. 5. Update DNS to point your domain to the load balancer IP and publish the DNS authorization record. 6. Validate the certificate becomes ACTIVE and confirm HTTPS works. 7. Clean up resources.

Important: A Google-managed certificate requires you to control DNS for the domain. If you don’t have a domain you can modify, skip to the Self-managed (demo) alternative inside Step 4.

Step 1: Set up your environment and enable APIs

1.1 Set environment variables

export PROJECT_ID="YOUR_PROJECT_ID"
export DOMAIN="example.yourdomain.com"   # a hostname you control (recommended)
export LOCATION="global"

# Load balancer resource names
export BUCKET_NAME="${PROJECT_ID}-cm-lab-bucket"
export BACKEND_BUCKET_NAME="cm-lab-backend-bucket"
export URL_MAP_NAME="cm-lab-url-map"
export HTTPS_PROXY_NAME="cm-lab-https-proxy"
export FORWARDING_RULE_NAME="cm-lab-fr-https"
export ADDRESS_NAME="cm-lab-ip"

# Certificate Manager resource names
export DNS_AUTH_NAME="cm-lab-dns-auth"
export CERT_NAME="cm-lab-cert"
export CERT_MAP_NAME="cm-lab-cert-map"
export CERT_MAP_ENTRY_NAME="cm-lab-cert-map-entry"

Expected outcome: You have consistent names to copy/paste.

1.2 Set your project

gcloud config set project "${PROJECT_ID}"

1.3 Enable required APIs

gcloud services enable \
  certificatemanager.googleapis.com \
  compute.googleapis.com \
  storage.googleapis.com

If you will use Cloud DNS in this lab, also enable:

gcloud services enable dns.googleapis.com

Expected outcome: APIs enabled successfully (may take a minute).

Step 2: Create a minimal backend (Cloud Storage static content)

This creates a tiny backend to serve behind the load balancer.

2.1 Create a bucket

Using gcloud storage:

gcloud storage buckets create "gs://${BUCKET_NAME}" --location=US

2.2 Upload a simple page

cat > index.html <<'EOF'
<!doctype html>
<html>
  <head><meta charset="utf-8"><title>Certificate Manager Lab</title></head>
  <body>
    <h1>HTTPS is working via Google Cloud Certificate Manager</h1>
  </body>
</html>
EOF

gcloud storage cp index.html "gs://${BUCKET_NAME}/index.html"

2.3 Make the object publicly readable (lab only)

gcloud storage objects update "gs://${BUCKET_NAME}/index.html" --add-acl-grant=entity=AllUsers,role=READER

Expected outcome: index.html is accessible publicly (only for lab simplicity).
In production, use private buckets and appropriate access patterns.

Step 3: Create an external HTTPS load balancer (without certificate attached yet)

You’ll create the load balancer resources and reserve a global IP.

3.1 Reserve a global static IP

gcloud compute addresses create "${ADDRESS_NAME}" --global

Get the reserved IP:

export LB_IP="$(gcloud compute addresses describe "${ADDRESS_NAME}" --global --format='value(address)')"
echo "Load balancer IP: ${LB_IP}"

Expected outcome: You have a stable IPv4 address for DNS.

3.2 Create a backend bucket

gcloud compute backend-buckets create "${BACKEND_BUCKET_NAME}" \
  --gcs-bucket-name="${BUCKET_NAME}"

3.3 Create a URL map

gcloud compute url-maps create "${URL_MAP_NAME}" \
  --default-backend-bucket="${BACKEND_BUCKET_NAME}"

At this point you have an HTTPS LB “skeleton” but no target HTTPS proxy yet (we’ll create it after the certificate map exists).

Expected outcome: Backend bucket + URL map exist.

Step 4: Create Certificate Manager resources (managed certificate path)

This is the core of the lab.

Step 4A (Recommended): Google-managed certificate with DNS authorization

4A.1 Create DNS authorization

gcloud certificate-manager dns-authorizations create "${DNS_AUTH_NAME}" \
  --domain="${DOMAIN}" \
  --location="${LOCATION}"

Now retrieve the required DNS record details that prove domain control:

gcloud certificate-manager dns-authorizations describe "${DNS_AUTH_NAME}" \
  --location="${LOCATION}" \
  --format="value(dnsResourceRecord.name,dnsResourceRecord.type,dnsResourceRecord.data)"

Expected outcome: The command prints a DNS record (name/type/data) you must publish exactly.

4A.2 Publish DNS records You must publish two DNS things:

1) The DNS authorization record (printed above).
2) An A record pointing your hostname to the load balancer IP: – DOMAIN → LB_IP

How you do this depends on your DNS provider:

  • If your DNS is in Cloud DNS, add records using gcloud dns record-sets ... (requires an existing public zone and domain delegation).
  • If your DNS is elsewhere (Route 53, Cloudflare, etc.), add records there.

Because zones and delegation vary, the safest instruction is: – Add the record exactly as shown by dns-authorizations describe – Add the A record: hostname ${DOMAIN} → ${LB_IP}

Verification tip (from your workstation):

# verify A record
dig +short "${DOMAIN}"

# verify the authorization record: use the exact name printed by the describe command
# Example:
# dig +short CNAME _acme-challenge.example.yourdomain.com

Expected outcome: DNS resolves correctly (may take time due to TTL/propagation).

4A.3 Create a Google-managed certificate

gcloud certificate-manager certificates create "${CERT_NAME}" \
  --location="${LOCATION}" \
  --domains="${DOMAIN}" \
  --dns-authorizations="${DNS_AUTH_NAME}"

Check status:

gcloud certificate-manager certificates describe "${CERT_NAME}" \
  --location="${LOCATION}" \
  --format="value(managed.state)"

Expected outcome: Initially the state is typically PROVISIONING. It should later become ACTIVE.

Provisioning can take time depending on DNS propagation and validation.

4A.4 Create a certificate map and entry

Create the map:

gcloud certificate-manager maps create "${CERT_MAP_NAME}" \
  --location="${LOCATION}"

Create the map entry for your hostname:

gcloud certificate-manager maps entries create "${CERT_MAP_ENTRY_NAME}" \
  --location="${LOCATION}" \
  --map="${CERT_MAP_NAME}" \
  --hostname="${DOMAIN}" \
  --certificates="${CERT_NAME}"

Expected outcome: The certificate map has an entry mapping ${DOMAIN} to ${CERT_NAME}.

Step 4B (Alternative): Self-managed certificate (demo path)

Use this if you cannot complete DNS authorization. This path demonstrates attachment and SNI mapping, but browsers will not trust a self-signed cert.

4B.1 Generate a self-signed certificate locally

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout key.pem -out cert.pem -days 7 \
  -subj "/CN=${DOMAIN}"

4B.2 Create a self-managed certificate resource

gcloud certificate-manager certificates create "${CERT_NAME}" \
  --location="${LOCATION}" \
  --certificate-file="cert.pem" \
  --private-key-file="key.pem"

4B.3 Create certificate map and entry (same as Step 4A.4)
Run the same maps create and maps entries create commands as above.

Expected outcome: You can proceed with the load balancer attachment and test TLS with curl -k.

Step 5: Create the target HTTPS proxy and forwarding rule (attach the certificate map)

5.1 Create the target HTTPS proxy with the certificate map attached

Certificate map full resource name:

export CERT_MAP_RESOURCE="projects/${PROJECT_ID}/locations/${LOCATION}/certificateMaps/${CERT_MAP_NAME}"
echo "${CERT_MAP_RESOURCE}"

Create the proxy:

gcloud compute target-https-proxies create "${HTTPS_PROXY_NAME}" \
  --url-map="${URL_MAP_NAME}" \
  --certificate-map="${CERT_MAP_RESOURCE}" \
  --global

Expected outcome: Target HTTPS proxy exists and references the certificate map.

5.2 Create a global forwarding rule for port 443

gcloud compute forwarding-rules create "${FORWARDING_RULE_NAME}" \
  --global \
  --address="${ADDRESS_NAME}" \
  --target-https-proxy="${HTTPS_PROXY_NAME}" \
  --ports=443

Expected outcome: The load balancer is reachable on ${LB_IP}:443.

Step 6: Wait for certificate activation (managed cert path) and verify HTTPS

If you used a Google-managed certificate, wait until it becomes ACTIVE:

gcloud certificate-manager certificates describe "${CERT_NAME}" \
  --location="${LOCATION}" \
  --format="yaml(managed.state,managed.authorizationAttemptInfo)"

Expected outcome: managed.state: ACTIVE

Now validate from a client.

6.1 Validate TLS and HTTP response

curl -v "https://${DOMAIN}/index.html"

If using the self-managed demo certificate, use:

curl -vk "https://${DOMAIN}/index.html"

Expected outcome: You should receive the HTML page and see a successful TLS handshake.

6.2 Verify certificate details (optional, recommended)

openssl s_client -connect "${DOMAIN}:443" -servername "${DOMAIN}" < /dev/null 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

Expected outcome: Subject/issuer/dates are printed. For Google-managed certs, the issuer will be a public CA chain used by Google at issuance time.

Validation

Use this checklist:

1) Certificate Manager resources exist:

gcloud certificate-manager certificates list --location="${LOCATION}"
gcloud certificate-manager maps list --location="${LOCATION}"
gcloud certificate-manager maps entries list --location="${LOCATION}" --map="${CERT_MAP_NAME}"

2) Target HTTPS proxy uses the certificate map:

gcloud compute target-https-proxies describe "${HTTPS_PROXY_NAME}" --global \
  --format="value(certificateMap)"

3) DNS points to the load balancer IP:

dig +short "${DOMAIN}"

4) HTTPS works:

curl -I "https://${DOMAIN}/index.html"

Troubleshooting

Common issues and fixes:

1) Managed certificate stuck in PROVISIONING – Cause: DNS authorization record is missing/incorrect or not propagated. – Fix: Re-run: bash gcloud certificate-manager dns-authorizations describe "${DNS_AUTH_NAME}" --location="${LOCATION}" Ensure your DNS record matches exactly (name/type/data). Verify with dig.

2) DNS resolves to the wrong IP – Cause: A record not updated, or multiple records exist. – Fix: Ensure ${DOMAIN} points to ${LB_IP} and wait for TTL.

3) TLS handshake fails / connection refused – Cause: Forwarding rule or proxy not created properly. – Fix: Check forwarding rule and proxy: bash gcloud compute forwarding-rules describe "${FORWARDING_RULE_NAME}" --global gcloud compute target-https-proxies describe "${HTTPS_PROXY_NAME}" --global

4) Certificate name mismatch – Cause: You connected by IP or wrong hostname; SNI didn’t match. – Fix: Always connect using the hostname in the map entry: bash curl -v "https://${DOMAIN}/"

5) Public DNS managed zone issues (Cloud DNS) – Cause: Domain not delegated to Cloud DNS name servers. – Fix: Update NS records at your domain registrar to delegate to the Cloud DNS zone (or use your existing DNS provider instead).

6) CAA record blocks issuance – Cause: Your domain has CAA records allowing only certain CAs. – Fix: Update CAA records to allow the CA used for Google-managed certificates (details vary). Verify the correct CAA settings in official docs.

Cleanup

To avoid ongoing costs (especially load balancer costs), delete resources when done.

Delete load balancer resources

gcloud compute forwarding-rules delete "${FORWARDING_RULE_NAME}" --global --quiet
gcloud compute target-https-proxies delete "${HTTPS_PROXY_NAME}" --global --quiet
gcloud compute url-maps delete "${URL_MAP_NAME}" --quiet
gcloud compute backend-buckets delete "${BACKEND_BUCKET_NAME}" --quiet
gcloud compute addresses delete "${ADDRESS_NAME}" --global --quiet

Delete Certificate Manager resources

gcloud certificate-manager maps entries delete "${CERT_MAP_ENTRY_NAME}" \
  --location="${LOCATION}" --map="${CERT_MAP_NAME}" --quiet

gcloud certificate-manager maps delete "${CERT_MAP_NAME}" \
  --location="${LOCATION}" --quiet

gcloud certificate-manager certificates delete "${CERT_NAME}" \
  --location="${LOCATION}" --quiet

gcloud certificate-manager dns-authorizations delete "${DNS_AUTH_NAME}" \
  --location="${LOCATION}" --quiet

Delete storage resources

gcloud storage rm -r "gs://${BUCKET_NAME}"
rm -f index.html cert.pem key.pem

If you created DNS records for the lab, remove them from your DNS provider.

11. Best Practices

Architecture best practices

  • Terminate TLS at a small number of well-managed ingress points (load balancers) rather than distributing certs across many backends.
  • Use certificate maps to support multi-domain hosting cleanly with SNI.
  • Separate environments (dev/stage/prod) by project and/or domain hierarchy:
  • dev.example.com, staging.example.com, example.com

IAM / security best practices

  • Use least privilege:
  • Allow only a small group to upload self-managed private keys.
  • Separate roles for managing certs vs attaching to load balancers.
  • Prefer short-lived, approved change windows for certificate rotations.
  • Use IAM Conditions where appropriate (for example, restrict access by resource name prefix). Verify best practices and feasibility in your org.

Cost best practices

  • Avoid leaving lab load balancers running.
  • Consolidate hostnames behind fewer load balancers where it makes sense.
  • Consider whether you need premium edge features (CDN, WAF, etc.)—those drive cost more than certificates.

Performance best practices

  • Keep TLS at the edge; avoid re-terminating TLS multiple times unless required.
  • Use modern TLS policies/ciphers supported by your load balancer configuration (policy controls may live in load balancer configuration rather than Certificate Manager—verify current controls).

Reliability best practices

  • Monitor certificate expiration even for managed certs (managed renewals are robust but operational visibility is still important).
  • Run regular DNS validation checks for critical domains.
  • Maintain runbooks:
  • “Certificate stuck provisioning”
  • “Unexpected certificate served”
  • “Emergency rotation”

Operations best practices

  • Standardize resource naming, for example:
  • cm-${env}-${app}-cert
  • cm-${env}-map
  • Use labels/tags where supported for cost allocation and ownership.
  • Record domain ownership and DNS provider ownership in your CMDB or internal docs.

Governance best practices

  • Define domain onboarding requirements:
  • Approved DNS zones
  • Required CAA record policy
  • Required contact and escalation path
  • Use change management: PR-based IaC with approvals for certificate map changes.

12. Security Considerations

Identity and access model

  • Certificate Manager uses IAM. Control access to:
  • Create/update/delete certificates
  • Create/update/delete certificate maps and map entries
  • View certificate metadata
  • Treat self-managed certificate upload permissions as highly sensitive because private keys are involved.

Encryption

  • TLS provides encryption in transit for client-to-edge connections.
  • For self-managed certs, protect private keys at rest and in CI/CD systems:
  • Generate keys in controlled environments
  • Limit who can access and upload them
  • Avoid storing private keys in source code repositories

Network exposure

  • Certificates are presented by the load balancer; exposure depends on:
  • Whether the load balancer is external vs internal
  • Firewall and backend access controls
  • Ensure you do not accidentally expose internal services via an external LB.

Secrets handling

  • Do not pass private keys around in chat tools or tickets.
  • Avoid long-lived copies of private keys on developer laptops.
  • Consider using dedicated secure pipelines for key handling and enforce approvals.

Audit / logging

  • Enable and review Cloud Audit Logs for:
  • Certificate Manager admin actions
  • Compute/load balancer configuration changes
  • Keep logs for an appropriate retention period for compliance needs.

Compliance considerations

  • Use managed certificates for standardized public trust and renewal automation where policy allows.
  • For regulated environments requiring private PKI, evaluate Certificate Authority Service plus controlled issuance workflows (and then deploy resulting certs as self-managed, if appropriate).

Common security mistakes

  • Granting broad project Owner to many users “just to get TLS working.”
  • Uploading self-managed private keys without clear ownership and rotation policies.
  • DNS misconfigurations leading to domain takeover risks (e.g., dangling records). Maintain DNS hygiene.

Secure deployment recommendations

  • Prefer managed certificates where possible and allowed.
  • Enforce least privilege and separation of duties.
  • Keep DNS zones secured (registrar lock, MFA, restricted admin access).
  • Monitor for unexpected certificate map changes (alert on audit logs).

13. Limitations and Gotchas

Treat this section as a practical checklist; verify current limits and supported integrations in official docs because they can change.

Known limitations / constraints (common patterns)

  • Not every Google Cloud endpoint can directly use Certificate Manager. Many products manage certificates independently.
  • DNS propagation can delay managed certificate issuance.
  • SNI requires correct hostname: testing by IP can result in mismatched certificates.
  • Quotas apply to certificates, maps, and entries.
  • Location scope matters: Some target proxies are global; some are regional. Resource location must be compatible (verify).

Operational gotchas

  • Deleting a certificate that is still referenced by a map entry can fail or cause outages—plan dependency order.
  • Overlapping hostname entries can cause confusion about which certificate is served—use clear naming and avoid ambiguous patterns.
  • CAA records can unexpectedly block issuance.
  • If you use external DNS providers with proxy/CDN features (e.g., “orange cloud” proxying), ensure the validation and routing requirements are met.

Pricing surprises

  • The load balancer cost can dwarf certificate-related costs.
  • DNS query charges can be significant at scale.
  • Internet egress is often the largest cost for public apps.

Migration challenges

  • Migrating from legacy load balancer certificate attachments to certificate maps may require careful planning:
  • Avoid downtime by attaching maps and verifying SNI behavior before removing legacy attachments.
  • Use staged cutovers by hostname.

14. Comparison with Alternatives

Options to consider

  • Google Cloud legacy SSL certificate attachments (Compute Engine SSL certificates)
    Historically used directly on load balancers; in many architectures, certificate maps are now preferred for scale and manageability. Treat older patterns as legacy if docs recommend migrating.
  • Google Cloud Certificate Authority Service (CAS)
    A private CA / PKI service—different scope than Certificate Manager.
  • AWS Certificate Manager (ACM)
    Similar managed cert service for AWS-integrated endpoints.
  • Azure Key Vault Certificates
    Certificate lifecycle integrated with Key Vault and Azure services.
  • Kubernetes cert-manager (open source)
    Good for Kubernetes-native issuance/renewal, especially inside clusters or with Ingress controllers.

Comparison table

Option Best For Strengths Weaknesses When to Choose
Google Cloud Certificate Manager Centralized TLS cert management for Google Cloud ingress (esp. Cloud Load Balancing) SNI mapping via certificate maps; managed cert lifecycle; IAM + audit integration Limited to supported integrations; DNS validation complexity You terminate TLS on Cloud Load Balancing and want scalable, auditable cert operations
Compute Engine SSL certificates (legacy pattern) Older load balancer setups Simple for single-cert cases Less scalable for many hostnames; may be legacy vs certificate maps (verify current guidance) Existing deployments that haven’t migrated yet; short-term compatibility
Google Cloud Certificate Authority Service Private PKI and internal certificates Managed CA hierarchy, policy, issuance, revocation Different product and cost; still need deployment mechanism You need enterprise/private PKI for internal mTLS or regulated issuance
AWS Certificate Manager (ACM) AWS-native certificate management Tight AWS integration; managed renewals Not usable on Google Cloud endpoints You host workloads primarily on AWS
Azure Key Vault Certificates Azure-native certificate lifecycle Central secrets + certificate lifecycle Not a Google Cloud ingress deployment tool You host workloads primarily on Azure
cert-manager (Kubernetes) Kubernetes-native certificate automation ACME support; integrates with Ingress; GitOps-friendly Operational overhead; cluster-centric; still need edge integration You want cert lifecycle managed in-cluster and accept operating it

15. Real-World Example

Enterprise example: Multi-business-unit shared ingress platform

Problem A large enterprise runs dozens of business-unit applications behind shared global load balancers. Certificates are managed inconsistently, and several teams have experienced outages due to expiration and last-minute renewals.

Proposed architecture – Central “edge ingress” project with: – External HTTPS load balancers – Certificate Manager certificate maps per environment (prod/stage) – Domain ownership and DNS managed by a central DNS team (Cloud DNS or approved provider) – Security team controls managed certificate issuance workflow and certificate maps – Application teams own backends (NEGs, services) and URL map routing (via controlled change process)

Why Certificate Manager was chosen – Centralized certificate lifecycle and SNI mapping across many hostnames. – IAM-based separation of duties. – Easier auditing of changes for compliance.

Expected outcomes – Reduced certificate-related incidents. – Faster onboarding of new domains. – Standardized rotation procedures with clear ownership and audit trails.

Startup / small-team example: SaaS with customer subdomains

Problem A startup runs a SaaS platform where each customer has a subdomain. They need HTTPS across many hostnames without manually issuing/renewing certificates.

Proposed architecture – Single external HTTPS load balancer – Certificate Manager managed certificates (where supported) for customer-facing domains – Certificate map entries created via automation when new customers are provisioned – Observability via LB logs and basic alerting

Why Certificate Manager was chosen – Minimal ops burden: managed renewals and central mapping. – Clean integration with load balancer used as the ingress for multiple backends.

Expected outcomes – Rapid customer onboarding with HTTPS by default. – Lower operational risk of certificate expiry. – Simple scaling model without adding a load balancer per customer.

16. FAQ

1) Is “Certificate Manager” the official Google Cloud product name?
Yes. Google Cloud’s service is called Certificate Manager. Always confirm capabilities and supported integrations in the official docs because related certificate features also exist in other products.

2) What’s the difference between Certificate Manager and Certificate Authority Service?
Certificate Manager focuses on managing and deploying TLS certificates (and mapping them to hostnames) for supported endpoints. Certificate Authority Service is for issuing and operating private CAs (PKI).

3) Do I need to use Cloud DNS with Certificate Manager?
No, but you must be able to publish DNS records for domain authorization and point your domain to the load balancer IP. Cloud DNS is convenient but not required.

4) How does Certificate Manager choose which certificate to present?
Typically via SNI and certificate map entries that match the requested hostname.

5) Can I upload my own certificate?
Yes, using a self-managed certificate workflow where you provide the certificate chain and private key.

6) Who should be allowed to upload self-managed private keys?
A small, trusted group (security/platform). Treat it as a privileged action and enforce least privilege.

7) How long does a Google-managed certificate take to become ACTIVE?
It varies—often minutes to hours—depending on DNS propagation and validation. If it takes too long, check DNS authorization records and A/AAAA records.

8) Why is my certificate stuck in PROVISIONING?
Most commonly: DNS authorization record not published correctly, not propagated, or domain not properly pointed to the load balancer (depending on validation requirements).

9) Can I use Certificate Manager for internal-only services?
It depends on the supported integrations (for example, internal load balancer types). Verify in official docs for your specific internal LB and location constraints.

10) Do certificate maps work with multiple domains on a single IP?
Yes—this is a primary use case. SNI allows the load balancer to present the correct certificate.

11) Can I use wildcard certificates?
Support depends on certificate type and validation method. Verify wildcard support for managed certificates and map entries in the official docs.

12) What happens if I delete a certificate that is referenced by a map entry?
It can fail or lead to service disruption. Always remove references (update map entries) before deletion.

13) Is Certificate Manager a replacement for storing certificates in Secret Manager?
Not exactly. Secret Manager is general secret storage. Certificate Manager is for certificate lifecycle + deployment to supported ingress points.

14) Can I manage Certificate Manager with Terraform?
Often yes, via Google Cloud provider resources, but exact resource coverage can change. Verify current Terraform support and versions.

15) What’s the safest way to rotate a certificate?
Create the new certificate, update the certificate map entry to point to it, validate, then remove the old certificate after a safe window.

16) How do I know which certificate is being served in production?
Use openssl s_client with -servername, browser inspection tools, and monitor logs/metrics for TLS handshake errors.

17) Do I pay for Certificate Manager itself?
Pricing can change; consult the official pricing page: https://cloud.google.com/certificate-manager/pricing. In many setups, load balancer runtime and egress dominate cost.

17. Top Online Resources to Learn Certificate Manager

Resource Type Name Why It Is Useful
Official documentation Certificate Manager docs — https://cloud.google.com/certificate-manager/docs Primary source for current features, supported integrations, and workflows
Official pricing Certificate Manager pricing — https://cloud.google.com/certificate-manager/pricing Authoritative pricing model and SKU details
Pricing tool Google Cloud Pricing Calculator — https://cloud.google.com/products/calculator Helps estimate load balancer + DNS + egress + certificate-related costs
CLI reference gcloud CLI — https://cloud.google.com/sdk/gcloud Practical commands for creating certificates, maps, and DNS authorizations
Load balancing docs Cloud Load Balancing docs — https://cloud.google.com/load-balancing/docs Required to understand target proxies, forwarding rules, and HTTPS LB architecture
DNS docs Cloud DNS docs — https://cloud.google.com/dns/docs How to publish A/AAAA and validation records correctly
Audit logging Cloud Audit Logs — https://cloud.google.com/logging/docs/audit Track configuration changes for security and compliance
Hands-on labs Cloud Skills Boost catalog search — https://www.cloudskillsboost.google/catalog?keywords=certificate%20manager Find up-to-date labs related to certificates and load balancing (availability varies)
Architecture guidance Google Cloud Architecture Center — https://cloud.google.com/architecture Patterns for edge design, multi-domain routing, and security controls
Community learning (verify) Google Cloud community/tutorials — https://cloud.google.com/community Practical posts; validate against official docs before production use

18. Training and Certification Providers

Institute Suitable Audience Likely Learning Focus Mode Website
DevOpsSchool.com DevOps engineers, SREs, platform teams DevOps + cloud operations; may include Google Cloud security and networking basics Check website https://www.devopsschool.com/
ScmGalaxy.com Beginners to intermediate engineers SCM/DevOps tooling; may include cloud fundamentals Check website https://www.scmgalaxy.com/
CLoudOpsNow.in Cloud operations practitioners CloudOps practices, monitoring, reliability, deployments Check website https://www.cloudopsnow.in/
SreSchool.com SREs, operations, platform engineers Reliability engineering, incident response, production readiness Check website https://www.sreschool.com/
AiOpsSchool.com Ops teams exploring AIOps Automation, monitoring analytics, operational tooling Check website https://www.aiopsschool.com/

19. Top Trainers

Platform/Site Likely Specialization Suitable Audience Website
RajeshKumar.xyz DevOps/cloud training content (verify offerings) Engineers seeking practical guidance https://www.rajeshkumar.xyz/
devopstrainer.in DevOps training (verify course catalog) Beginners to intermediate DevOps engineers https://www.devopstrainer.in/
devopsfreelancer.com Freelance DevOps help/training (treat as a platform; verify) Teams needing hands-on assistance https://www.devopsfreelancer.com/
devopssupport.in DevOps support/training (verify scope) Ops teams needing implementation support https://www.devopssupport.in/

20. Top Consulting Companies

Company Likely Service Area Where They May Help Consulting Use Case Examples Website
cotocus.com Cloud/DevOps consulting (verify exact offerings) Cloud architecture, DevOps pipelines, operational readiness TLS termination design, LB standardization, certificate rotation runbooks https://www.cotocus.com/
DevOpsSchool.com DevOps/cloud consulting and training (verify consulting scope) Platform engineering, CI/CD, cloud adoption Implement IaC for Certificate Manager + load balancers, IAM hardening, migration from legacy cert attachments https://www.devopsschool.com/
DEVOPSCONSULTING.IN DevOps consulting (verify service catalog) DevOps process, automation, operations Production readiness reviews, logging/auditing setup for certificate changes, cost optimization https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Certificate Manager

  • TLS basics: certificates, chains, private keys, SNI, SANs
  • DNS basics: A/AAAA, CNAME/TXT, delegation, TTL
  • Google Cloud fundamentals:
  • Projects, IAM, APIs
  • VPC basics (helpful even though Certificate Manager is control plane)
  • Cloud Load Balancing fundamentals:
  • Forwarding rules, target proxies, URL maps, backends

What to learn after Certificate Manager

  • Advanced Cloud Load Balancing:
  • Multi-region designs
  • CDN and caching strategies
  • Security controls around edge routing (WAF/Cloud Armor, where applicable)
  • Incident response for edge systems:
  • Monitoring, alerting, rollback strategies
  • Private PKI:
  • Certificate Authority Service
  • mTLS patterns (service-to-service), where applicable

Job roles that use it

  • Cloud Security Engineer
  • Platform Engineer
  • SRE
  • DevOps Engineer
  • Cloud Network Engineer / Load Balancing Specialist
  • Solutions Architect

Certification path (Google Cloud)

Certificate Manager appears as a supporting skill in broader certifications. Consider: – Associate Cloud Engineer – Professional Cloud Architect – Professional Cloud Security Engineer – Professional Cloud Network Engineer

(Always verify the latest exam guides and skill domains on the official certification pages.)

Project ideas for practice

  • Build a multi-domain HTTPS ingress:
  • 5 hostnames → 1 LB → different backends
  • Automate certificate map entry creation for a “tenant onboarding” workflow
  • Implement a certificate rotation pipeline with pre- and post-validation checks
  • Create an audit report:
  • List all certificates, their domains, and map usage
  • Alert on unexpected changes (audit logs)

22. Glossary

  • TLS (Transport Layer Security): Protocol that encrypts client-server traffic (HTTPS is HTTP over TLS).
  • SSL: Legacy term often used interchangeably with TLS; modern deployments use TLS.
  • Certificate (X.509): Data structure binding a public key to identity (domain name), signed by a CA.
  • Private key: Secret key corresponding to the certificate’s public key; must be protected.
  • Public CA: Certificate authority trusted by browsers/OSes.
  • Domain validation (DV): CA verifies you control the domain (commonly via DNS or HTTP challenge).
  • SNI (Server Name Indication): TLS extension where the client indicates the hostname it wants, enabling multiple certs on one IP.
  • SAN (Subject Alternative Name): List of hostnames a certificate covers.
  • Certificate chain: Leaf certificate + intermediate certificates up to a trusted root.
  • PEM: Common text encoding for certificates and keys (-----BEGIN CERTIFICATE-----).
  • Certificate map: Certificate Manager resource used to select a certificate based on hostname/SNI.
  • Certificate map entry: Rule mapping a hostname to one or more certificates.
  • DNS authorization: Resource representing proof of domain control via a required DNS record.
  • Forwarding rule: Load balancer resource that binds IP:port to a target proxy.
  • Target HTTPS proxy: Load balancer resource that terminates HTTPS and routes requests using a URL map.
  • URL map: Load balancer routing rules (host/path → backend).
  • Backend bucket: Cloud Load Balancing backend that serves content from Cloud Storage.
  • Cloud Audit Logs: Logs of administrative actions affecting Google Cloud resources.

23. Summary

Google Cloud Certificate Manager is a Security service for centralized TLS certificate management and deployment, most commonly used with Cloud Load Balancing. It helps teams deliver HTTPS reliably by supporting Google-managed certificates (automated issuance/renewal where supported) and self-managed certificates, and by routing certificates to hostnames with certificate maps and map entries.

Where it fits best is at the edge of your architecture: a standardized ingress layer that terminates TLS and serves multiple domains safely at scale. Cost-wise, the certificate objects are often not the main expense—load balancer runtime, DNS, and egress typically dominate—so you should optimize around those. From a security perspective, focus on least privilege, careful DNS control, strong private key handling (for self-managed), and auditability.

Use Certificate Manager when you need scalable, auditable HTTPS certificate operations in Google Cloud. Next step: deepen your Cloud Load Balancing knowledge and practice a certificate rotation workflow end-to-end, including validation and rollback.