GCP SSL Certificates Explained: Google-Managed, Self-Managed, and Certificate Manager

SSL certificates in GCP in simple terms

A TLS certificate does two things: it encrypts the connection between a browser and your application, and it proves to the browser that your server genuinely controls the domain it claims to. Without a valid certificate, modern browsers refuse to load the page without a security warning.

In GCP, certificates live on the external load balancer, specifically on its target HTTPS proxy. When a user visits your application, their browser connects to the load balancer, which presents the certificate and completes the TLS handshake. The load balancer then decrypts the request and forwards it to your backend VM or service over plain HTTP within your private VPC. Your VMs are never involved in the certificate process.

Beginners often get confused here because they try to install certificates on VMs, as you would with a traditional NGINX or Apache server. In GCP, you do not do that. If you are using HTTP(S) load balancing, you attach the certificate to the proxy, and TLS is handled entirely at the edge.

How SSL certificates work in GCP

Here is what happens on each HTTPS request to a GCP-hosted application:

1. The client connects to your load balancer’s IP on port 443.
2. The load balancer presents its TLS certificate. The browser checks it is valid, signed by a trusted CA, and matches the domain name.
3. A TLS handshake completes. The connection is encrypted from the client to the load balancer, not from the client to your VM.
4. The load balancer decrypts the request and forwards it to a backend VM or service, typically over plain HTTP within your VPC. This is standard practice: your VPC is a private network not accessible from the internet.
5. Optionally, you can configure the load balancer to re-encrypt traffic to the backend over HTTPS. This is called backend HTTPS. It is required in some compliance scenarios but adds operational complexity and is not necessary for most applications.

The practical result: your backend VMs receive plain HTTP traffic from GCP’s internal proxy IP ranges, not directly from the internet. There is no certificate to manage on the VM itself, and your VMs are not exposed to public TLS traffic.

When to use Google-managed, self-managed, or Certificate Manager

Use Google-managed certificates when:

• You have a public website or app with standard domain names (e.g., example.com, www.example.com)
• You want zero certificate management overhead: no renewals to track, no private keys to store
• You are using a global Application Load Balancer
• All your domains can resolve to the load balancer IP (HTTP-01 validation must reach port 80 at that IP)

Use self-managed certificates when:

• You need a wildcard certificate (*.example.com) without the Certificate Manager setup
• Your domain is private or internal and cannot be publicly resolved from the internet
• You have a compliance requirement specifying a particular CA or EV certificates
• You are using a regional load balancer, which does not support Google-managed certificates

Use Certificate Manager when:

• You need wildcard certificates with automatic renewal (DNS authorisation supports this; HTTP-01 does not)
• You manage many certificates across multiple load balancers and want centralised control
• Your domain does not yet serve HTTP traffic but you still need to provision a certificate
• You want certificate maps to route different certificates to different domains on the same proxy

Google-managed vs self-managed vs Certificate Manager

Google-managed certificates

Google-managed certificates are the default choice for most public applications. You specify one or more domain names and GCP handles everything: requesting the certificate from a CA, proving domain ownership via HTTP-01 challenge, installing it on the load balancer, and renewing it automatically before expiry.

You never see the private key. You never set a renewal reminder. The only thing you must ensure is that the domain resolves to your load balancer IP before or at the same time you create the certificate. GCP validates ownership by sending an HTTP request to port 80 at that IP, so the domain needs to point there first.

# Create a Google-managed certificate for one or more domains
gcloud compute ssl-certificates create my-managed-cert \
  --domains=example.com,www.example.com \
  --global

# Check provisioning status — look for ACTIVE vs PROVISIONING
gcloud compute ssl-certificates describe my-managed-cert \
  --global \
  --format="table(name, managed.status, managed.domainStatus)"

The status will show PROVISIONING until domain validation succeeds. Once DNS points to the load balancer and GCP completes validation, the status moves to ACTIVE. This typically takes a few minutes after DNS propagates, but can take up to 30 minutes.

Limitations of Google-managed certificates

• No wildcard domain support: each domain must be listed explicitly
• Maximum of 100 domains per certificate
• HTTP-01 validation requires the domain to be publicly reachable on port 80 at the load balancer IP
• Only works with global Application Load Balancers, Cloud CDN, and GKE Ingress

Self-managed certificates

With self-managed certificates, you obtain the certificate from any CA (Let’s Encrypt, DigiCert, your own internal CA) and upload it to GCP along with the private key. GCP installs it on the load balancer. You are entirely in control of the lifecycle, which means you are also responsible for tracking the expiry date and renewing before it lapses.

A practical example: a company with internal services on private DNS that cannot be publicly resolved. Their domains will never pass HTTP-01 challenge, so they use certificates issued by their internal CA and upload them manually using this approach.

# Upload a certificate and private key from local files
gcloud compute ssl-certificates create my-self-managed-cert \
  --certificate=/path/to/certificate.crt \
  --private-key=/path/to/private.key \
  --global

The certificate file should be the full chain: your domain certificate first, followed by any intermediate certificates. GCP validates at upload time that the private key matches the certificate’s public key.

# Swap to a renewed certificate on the proxy — non-disruptive
gcloud compute target-https-proxies update web-https-proxy \
  --ssl-certificates=my-renewed-cert \
  --global

Updating the proxy reference is non-disruptive. Existing TLS sessions complete with the old certificate; new handshakes begin using the new one. Once you confirm the new certificate is active, delete the old resource to remove the stale private key from GCP.

When to choose self-managed

• You need wildcard certificates (*.example.com)
• Your domain is private or internal and cannot be publicly resolved
• You have a compliance requirement for a specific CA or EV certificates
• You are using a regional load balancer

Certificate Manager

Certificate Manager is GCP’s dedicated service for managing TLS certificates at scale. It supports both Google-managed and self-managed certificates, but its key advantage over the basic approach is DNS authorisation: you prove domain ownership by adding a CNAME record to your DNS rather than relying on HTTP-01 challenge. This is what unlocks wildcard certificate support.

A typical scenario: you run a SaaS product where each customer gets a subdomain like customer.yourapp.com. You want a single wildcard cert for *.yourapp.com that renews automatically. Certificate Manager with DNS authorisation is the correct tool. The DNS CNAME proves ownership of the parent domain, which satisfies wildcard validation requirements that HTTP-01 cannot meet.

# Step 1: Create a DNS authorisation for your domain
gcloud certificate-manager dns-authorizations create example-auth \
  --domain=example.com

# Step 2: Get the CNAME record details — add this to your DNS provider
gcloud certificate-manager dns-authorizations describe example-auth \
  --format="get(dnsResourceRecord)"

# Step 3: Create a managed certificate using DNS auth (supports wildcards)
gcloud certificate-manager certificates create example-cert \
  --domains=example.com,*.example.com \
  --dns-authorizations=example-auth

# Step 4: Create a certificate map and add a hostname entry
gcloud certificate-manager maps create example-cert-map

gcloud certificate-manager maps entries create example-map-entry \
  --map=example-cert-map \
  --certificates=example-cert \
  --hostname=example.com

# Step 5: Attach the certificate map to your HTTPS proxy
gcloud compute target-https-proxies update web-https-proxy \
  --certificate-map=example-cert-map \
  --global

Once the CNAME record is in place and DNS propagates, GCP issues and manages the certificate without any further input. Renewal happens automatically and the CNAME record stays in place permanently for as long as Certificate Manager is managing that domain.

If you use GKE Ingress controllers, Certificate Manager certificates can be referenced via annotations, letting you manage certificates centrally outside the cluster and share them across multiple services.

Attaching multiple certificates

A single HTTPS proxy can hold multiple SSL certificates. This is useful when you serve both an apex domain and a subdomain under different certificates, or when transitioning between certificates during a renewal. You can attach both old and new simultaneously without any downtime.

# Attach multiple certificates to a proxy at once
gcloud compute target-https-proxies update web-https-proxy \
  --ssl-certificates=cert-primary,cert-secondary \
  --global

GCP uses Server Name Indication (SNI) to select the correct certificate for each incoming connection based on the domain the client requests. SNI is supported by all modern browsers and TLS clients. Attaching multiple certificates to one proxy does not affect performance or request handling.

Handling private keys securely

For self-managed certificates, you must provide the private key to GCP. A few practices that matter here:

• Do not store private keys in version control, not even in a private repository
• Use Secret Manager to store private keys and retrieve them in a CI/CD pipeline during certificate upload, rather than keeping key files on developer machines
• Restrict the compute.sslCertificates.create IAM permission to infrastructure roles only
• Delete old certificate resources after switching to renewed ones; stale resources with private keys are an unnecessary attack surface
• Rotate certificates and keys on a regular schedule, not only when they approach expiry

# Check a certificate's expiry date for audit or renewal planning
gcloud compute ssl-certificates describe my-self-managed-cert \
  --global \
  --format="get(selfLink, expireTime)"

It is worth including certificate expiry checks in your broader network security runbook alongside firewall reviews and IAM audits.