GCP Certificate Manager is Google Cloud’s native tool for provisioning and attaching TLS certificates to load balancers, and it handles a lot of the manual work that used to trip up teams running classic SSL certs on GCLB. But “Google manages it” and “you don’t need to watch it” are two very different statements, and conflating them is how certificates end up expiring in production despite being fully automated on paper.
This article covers how GCP Certificate Manager actually provisions and renews certificates, where the automation quietly breaks, and what a practical external monitoring setup looks like for teams running HTTPS load balancers on Google Cloud.
How GCP Certificate Manager Provisions and Renews Certificates
Certificate Manager, the product that replaced the older “classic” SSL certificate resource around 2022, supports two certificate types: Google-managed and self-managed. Google-managed certificates are the default choice for most teams — you point them at a domain, GCP handles the ACME-style issuance through its internal CA, and it attempts renewal automatically as the cert nears expiration.
Renewal for Google-managed certs typically kicks off around 30 days before expiry, assuming the underlying authorization is still valid. That’s the catch. A Google-managed certificate isn’t just “issued once and refreshed forever” — it depends on either DNS authorization (a TXT or CNAME record proving domain control) or load-balancer authorization staying intact the entire time the certificate exists. Break that chain and the renewal silently fails, even though the resource still shows as “Google-managed” in the console.
Why “Google-Managed” Doesn’t Mean “Unmonitored”
There’s a common assumption on infrastructure teams that once a certificate is Google-managed, it drops off the operational radar entirely — no expiration tracking needed, no alerts to configure, because Google “handles it.” That’s the myth worth busting here.
In practice, a Google-managed certificate can get stuck in PROVISIONING or FAILED_NOT_VISIBLE state for weeks without anyone noticing, because nothing in Cloud Monitoring pages you by default when that happens. A realistic scenario: a team migrates its authoritative DNS from Cloud DNS to a different registrar’s nameservers during a domain consolidation project, and the DNS authorization record backing a Certificate Manager cert gets dropped in the process. The certificate keeps serving on the existing valid cert for months — right up until the 90-day-ish window closes and renewal can’t complete because the authorization check fails. Users start seeing NET::ERR_CERT_DATE_INVALID on a Friday afternoon, and the on-call engineer discovers the cert has been silently failing to renew since the DNS cutover.
Nothing about that failure mode is unique to GCP — AWS Certificate Manager has the same DNS-validation dependency, discussed in SSL certificate management on AWS Certificate Manager — but GCP’s UI makes it particularly easy to glance at a green “Active” status on the load balancer’s frontend and assume everything downstream is fine when it isn’t.
Common Mistakes Teams Make with Certificate Manager
A few patterns show up repeatedly in postmortems involving GCP TLS outages. First, teams leave the deprecated classic SSL certificate resource attached to a target proxy alongside a newer Certificate Manager resource, creating ambiguity about which cert is actually being served — and nobody notices the classic one is the one nearing expiry. Second, Terraform refactors that recreate the google_dns_record_set for a DNS authorization token without an explicit dependency on the certificate resource can orphan the authorization, breaking renewal on the next cycle. Third, and most common: relying on Cloud Monitoring’s default metrics, which report certificate status changes but don’t proactively warn you 30 or 14 days ahead of expiration the way a dedicated monitoring workflow would.
A seasoned SRE managing a fleet of GCLB frontends treats “Active” as a snapshot, not a guarantee, and checks provisioning state on a schedule rather than only after a user complaint.
Setting Up External Monitoring for GCP SSL Certificates
Checking certificate health directly is straightforward with the gcloud CLI:
gcloud certificate-manager certificates describe CERT_NAME –format=”value(managed.state,managed.provisioningIssue)”
That surfaces the provisioning state and, critically, the reason field when something’s wrong — expired authorization, DNS mismatch, or a CA rate limit. Running this against every certificate in a project weekly is a reasonable baseline for small setups, but it doesn’t scale past a handful of domains and it’s still a manual pull rather than a push alert.
A more durable setup layers three things: Cloud Monitoring alerting policies on the certificatemanager.googleapis.com resource for state-change events, a scheduled Cloud Function or Cloud Run job that runs the gcloud check above and posts to Slack or PagerDuty, and independent external monitoring that checks the certificate as it’s actually served over TLS — not just what GCP’s control plane reports internally. That last piece matters because it catches mismatches between what Certificate Manager thinks is attached and what the load balancer is actually presenting, which happens after misconfigured URL maps or when a certificate map entry points at the wrong hostname. For teams running load balancers across GCP alongside other infrastructure, the same external-check approach applies regardless of cloud, as covered in how to monitor SSL certificates on load balancers right.
Organizations running workloads split across GCP, AWS, and on-prem — which describes most companies past the 50-engineer mark — benefit from a single monitoring layer that doesn’t care which cloud issued the cert, rather than three separate dashboards each showing a different provider’s idea of “healthy.” That approach is covered in more depth in how to monitor SSL certificates across multi-cloud environments.
Frequently Asked Questions
Does GCP Certificate Manager send email alerts before a certificate expires?
No, not by default. Certificate Manager itself doesn’t email or notify anyone proactively — you have to build that on top of Cloud Monitoring alerting policies or use an external monitoring service that checks certificate expiration and issuer status independently.
What happens if DNS authorization breaks after a Google-managed certificate is already issued?
The existing certificate keeps working until its expiration date, but the automatic renewal fails silently. The certificate will show a provisioning issue in its status field, though nothing forces that into your alerting pipeline unless you’ve configured it.
Can classic SSL certificates and Certificate Manager resources coexist on the same load balancer?
Technically yes during a migration window, but it’s a common source of confusion about which certificate is actually serving traffic. It’s worth auditing target proxies to confirm only the intended certificate resource is attached before decommissioning the older one.
Certificate Manager removes a lot of manual certificate handling from GCP operations, but the automation has dependencies — DNS records, authorization tokens, correct target proxy attachments — that can fail without triggering any default alert. Treating “Google-managed” as equivalent to “fully monitored” is the gap that turns a routine DNS cleanup into a weekend outage.