Google Cloud HTTPS load balancer certificate expired

gcp load balancer ssl certificate expired on the target HTTPS proxy stops every client on your global or regional front end—even when Compute Engine VMs behind the backend service renewed certs locally.

Google Cloud external HTTPS load balancers terminate TLS on target HTTPS proxies referencing SSL certificate resources. Certificate Manager and classic compute SSL certificate objects both feed those proxies. Backends may speak HTTP to the load balancer while clients see only the proxy certificate.

Google-managed certificates auto-renew when DNS and HTTP validation records stay correct; self-managed certs expire on your operations calendar. Teams renew Apache on VMs while the proxy still lists an expired selfManaged certificate resource.

You will list certificates and proxies, renew or recreate resources, update proxy bindings, and openssl the customer hostname on the load balancer IP or DNS record users resolve.

FinOps dashboards that track only Compute Engine spend miss certificate objects—they are inexpensive until an outage costs revenue. Treat each customer DNS name on a target HTTPS proxy as a monitored asset with the same priority as the database tier behind it.

What to check

Map forwarding rules → target HTTPS proxy → sslCertificates list. Global external HTTPS and regional external HTTPS use similar objects with different console navigation.

For Google-managed certs, read status ACTIVE with renewal timestamps in Certificate Manager or compute API. PROVISIONING_FAILED often traces to wrong A/AAAA records on validation URLs.

For self-managed, confirm PEM uploaded includes full chain and matches private key material stored in the SSL certificate resource.

Customer DNS may be A/AAAA to the static IP or A to a global anycast IP. Always openssl with the public hostname and correct SNI.

See load balancer presenting an expired certificate when multi-cloud edges stack in front of GCP.

Shared VPC and folder hierarchy can hide which project owns the SSL certificate resource versus the forwarding rule. During incidents, paste project ID, proxy name, and certificate name into the ticket before attempting cross-project updates. Google-managed renewals send email to project owners when provisioning fails—treat those messages as early warning, not noise.

Step-by-step

External verification

HOST=shop.example.com
echo | openssl s_client -connect "${HOST}:443" -servername "${HOST}" 2>/dev/null \
  | openssl x509 -noout -dates -serial -subject

List SSL certificates and proxies

gcloud compute ssl-certificates list --format="table(name,type,managed.status,expireTime)"
gcloud compute target-https-proxies list --format="table(name,sslCertificates)"

Note proxy name tied to your URL map for the service.

Renew Google-managed certificate

When validation fails or cert nears expiry:

gcloud compute ssl-certificates create shop-managed-2026 \
  --domains=shop.example.com,www.example.com \
  --global

Certificate Manager (newer estates):

gcloud certificate-manager certificates list --location=global
gcloud certificate-manager certificates describe CERT_NAME --location=global

Attach updated cert to proxy:

gcloud compute target-https-proxies update PROXY_NAME \
  --ssl-certificates=shop-managed-2026,other-existing-cert \
  --global

Use --region=REGION for regional proxies.

Upload self-managed renewal

gcloud compute ssl-certificates create shop-uploaded-2026 \
  --certificate=fullchain.pem \
  --private-key=privkey.pem \
  --global
gcloud compute target-https-proxies update PROXY_NAME \
  --ssl-certificates=shop-uploaded-2026 \
  --global

Remove obsolete cert names from the comma-separated list to avoid serving stale SNI matches.

Console path

Network services → Load balancing → select forwarding rule → Frontend configuration → edit HTTPS proxy → add new certificate resource → remove expired → Save. Propagation is usually minutes for global L7.

Screenshot the certificate list in console only after openssl confirms dates—console UI can lag behind live edge presentation during propagation.

Verify

curl -vI --connect-timeout 10 "https://${HOST}/" 2>&1 | grep -Ei 'expire|SSL'

Re-run openssl from outside GCP; serial and notAfter must advance.

Map forwarding rule to proxy (when inventory is unclear)

gcloud compute forwarding-rules describe RULE_NAME --global \
  --format="get(target)"
gcloud compute target-https-proxies describe PROXY_NAME --global \
  --format="get(sslCertificates)"

Regional load balancers drop the --global flag. Matching rule to proxy prevents updating a certificate that production never referenced.

Log expireTime from list output beside openssl notAfter in closure notes. Auditors ask for both when regulated workloads sit behind Google-managed certs.

How to read the output

gcloud ssl-certificates list expireTime applies to managed and self-managed resources; compare with openssl because proxy attachment is authoritative for clients.

target-https-proxies may reference multiple certs for multi-domain SNI; one expired cert breaks only hostnames mapped to that cert if routing uses cert selection rules.

PROVISIONING_FAILED on managed certs includes domain status messages—fix DNS at the registrar, not instance groups.

Cloud Armor, IAP, and Cloud CDN settings on the same load balancer do not refresh certificates—operators sometimes burn hours tuning security policies while openssl still shows last year’s notAfter on the customer hostname.

After proxy updates, re-run synthetic checks that mobile apps use. gcp load balancer ssl certificate expired incidents often report first from app stores while desktop browsers still hold HSTS state from a prior valid week.

Common mistakes

Renewing on backend instances while HTTPS proxy still references last year’s selfManaged resource.

Creating a new managed cert but forgetting to update proxy sslCertificates list—GCP keeps serving old binding.

Omitting www when managed cert domains list only apex—marketing CNAME fails despite shop.example.com working.

Mixing global and regional proxy flags in gcloud—commands fail silently or update wrong scope.

Deleting expired cert before attaching replacement—brief total TLS outage on shared proxies.

Assuming Certificate Manager and classic compute certs auto-sync without proxy update after migration projects.

Running gcloud against the wrong project context—certificate list empty while customers still hit expired material in another project.

Deleting managed certificate resources to force renewal without updating DNS validation records—provisioning loops until DNS is repaired.

When to use automation

URL maps and certificate objects sprawl across folders and Shared VPC attachments. Monitor live TLS on customer DNS names, not only gcloud expireTime columns.

ssldays presents issuer, SANs, chain trust, and expiry from the public internet and alerts at 30, 14, 7, and 1 days. RDAP on the domain supports validation when registrar records lapse. Email on all plans; Slack and Discord on Starter and Pro.

Use /check after proxy updates, then /register for each hostname on the certificate. Compare listener workflows with AWS ALB listener certificate expired in hybrid estates.

Label Google-managed certificates in monitoring with the proxy name they serve so alerts route to the team that owns URL maps, not only the team that owns backend instance groups.