🚨 GCP Error Guide: 'SslCertificate managed status FAILED_NOT_VISIBLE' Managed Cert Provisioning Failure

Exact Error Message

When you provision a Google-managed SSL certificate on an HTTPS (Application) Load Balancer, the certificate never reaches ACTIVE. Instead gcloud reports:

$ gcloud compute ssl-certificates describe lb-cert-www --global
managed:
  domains:
  - www.example.com
  domainStatus:
    www.example.com: FAILED_NOT_VISIBLE
  status: FAILED_NOT_VISIBLE
name: lb-cert-www
type: MANAGED

In the Cloud Console (Network services > Load balancing > Frontend) the same condition appears as:

Certificate status: Failed (FAILED_NOT_VISIBLE)
Domain www.example.com: FAILED_NOT_VISIBLE — Certificate provisioning failed because the
load balancer's IP is not pointed at by the domain, or the domain is not yet visible to the
certificate authority.

The loadbalancing subsystem emits this state on the SslCertificate resource.

What the Error Means

Google-managed certificates are issued by an ACME-style certificate authority that must validate domain control over HTTP before signing. To do that, the CA resolves your domain’s public DNS records and connects to the IP address on port 80/443. FAILED_NOT_VISIBLE means that validation could not reach your load balancer: when the CA looked up the domain, it did not resolve to the load balancer’s anycast IP, or it resolved to a different IP entirely, so the domain was “not visible” at the expected front door.

This is almost always a DNS or load-balancer-wiring problem, not a certificate problem. The managed certificate object is healthy; it simply cannot complete the domain-authorization challenge because the request never lands on the forwarding rule that owns the certificate. Until the CA can reach the LB IP for that exact hostname, the cert stays in PROVISIONING and then flips to FAILED_NOT_VISIBLE after the validation window expires.

Common Causes

• No A/AAAA record, or the record points elsewhere. The domain resolves to a parking IP, a previous server, or a CDN that is not the load balancer’s reserved IP.
• AAAA record present but no IPv6 frontend. The CA may prefer IPv6; if an AAAA record exists but the LB has no IPv6 forwarding rule (or vice versa), validation fails on that protocol.
• Certificate not attached to a running target proxy / forwarding rule. A managed cert only validates once it is referenced by a target HTTPS proxy that has a global forwarding rule with a reserved IP.
• CAA records that disallow Google’s CA. A CAA record permitting only another issuer blocks pki.goog from signing.
• Apex/wildcard or www mismatch. The cert lists example.com but DNS only points www.example.com, or vice versa.
• DNS propagation lag or low-TTL flapping right after you created the records.
• Domain not yet delegated to the nameservers you edited (registrar still points at old NS).

How to Reproduce the Error

1. Reserve a global static IP and stand up an external HTTPS load balancer with a target HTTPS proxy.
2. Create a managed certificate for a domain whose DNS you do not update: gcloud compute ssl-certificates create lb-cert-www --domains=www.example.com --global.
3. Attach it to the target proxy and create the forwarding rule.
4. Leave the public DNS A record pointing at an old origin (or omit it entirely).
5. Run gcloud compute ssl-certificates describe lb-cert-www --global repeatedly. Within roughly 15-30 minutes the domain status transitions from PROVISIONING to FAILED_NOT_VISIBLE because the CA cannot reach the LB IP for that hostname.

Diagnostic Commands

All of the following are read-only.

# 1. Confirm the managed cert state and per-domain status
gcloud compute ssl-certificates describe lb-cert-www --global \
  --format="yaml(name, managed.status, managed.domainStatus, managed.domains)"

# 2. Find the reserved IP your load balancer actually uses
gcloud compute forwarding-rules list \
  --filter="loadBalancingScheme=EXTERNAL_MANAGED" \
  --global \
  --format="table(name, IPAddress, target, portRange)"

# 3. Confirm the target HTTPS proxy references THIS certificate
gcloud compute target-https-proxies describe https-proxy-www --global \
  --format="yaml(name, sslCertificates, urlMap)"

# 4. Inspect the reserved address by name
gcloud compute addresses describe lb-ip-www --global \
  --format="value(address, addressType, status)"

# 5. Resolve the domain from the public internet (compare to step 2/4)
dig +short www.example.com A
dig +short www.example.com AAAA

# 6. Check for CAA records that might exclude Google's CA (pki.goog)
dig +short example.com CAA

# 7. Confirm nameserver delegation matches where you edited records
dig +short example.com NS

The single most useful check: the IP from step 2/4 must equal the IP returned by dig in step 5. If they differ, that is your root cause.

Step-by-Step Resolution

1. Get the load balancer’s IP from the diagnostics above (e.g. 203.0.113.42).
2. Point DNS at that IP. Create or update the public A record (and AAAA if you advertise IPv6) for the exact hostname on the cert:

   # Example using Cloud DNS; adapt to your registrar
   gcloud dns record-sets create www.example.com. \
     --zone=example-zone --type=A --ttl=300 --rrdatas=203.0.113.42

3. Match IP families. If you created an AAAA record, ensure the LB has an IPv6 forwarding rule and reserved IPv6 address; otherwise remove the AAAA record so the CA only validates over IPv4.
4. Fix CAA if present. Either remove the restrictive CAA record or add one that authorizes Google:

   gcloud dns record-sets create example.com. \
     --zone=example-zone --type=CAA --ttl=300 \
     --rrdatas='0 issue "pki.goog"'

5. Ensure the cert is attached to a target HTTPS proxy that has a live global forwarding rule. Managed certs do not validate while detached.
6. Wait for retry. Once DNS resolves to the LB IP, Google automatically re-attempts validation. Provisioning typically completes within 15-60 minutes; large propagation delays can take a few hours.
7. If it stays failed after DNS is correct, delete and recreate the certificate so a fresh validation cycle starts, then re-attach it to the proxy. A stale FAILED_NOT_VISIBLE object will not always self-heal.

For broader frontend debugging, see /categories/gcp/.

Prevention and Best Practices

• Create DNS records before the certificate. Point the hostname at the reserved LB IP first, then create the managed cert so the very first validation attempt succeeds.
• Reserve a static IP and reference it by name in the forwarding rule so the address never changes underneath your DNS.
• Use low TTLs (300s) during cutover so corrections propagate quickly, then raise them afterward.
• List every hostname the cert must serve (apex and www) and create matching DNS for each.
• Audit CAA records organization-wide and explicitly authorize pki.goog.
• Monitor cert status with a scheduled describe and alert on any value other than ACTIVE. For automated triage of LB and cert alerts, see /dashboard/monitoring-alerts/.

Related Errors

• FAILED_RATE_LIMITED — too many provisioning attempts; the CA throttled you. Wait and reduce churn.
• FAILED_CAA_CHECKING / FAILED_CAA_FORBIDDEN — a CAA record explicitly forbids Google’s CA.
• PROVISIONING that never advances — DNS not yet propagated, or cert not attached to a proxy.
• 502 backend unhealthy — a separate data-path problem once TLS terminates successfully.
• SSL_ERROR / handshake failures at the client — usually a self-managed cert chain issue rather than a managed-cert provisioning failure.

Frequently Asked Questions

Why does it say “not visible” when my site loads fine in a browser? Your browser may be hitting a CDN, an old origin, or a cached IP. The certificate authority resolves public DNS fresh and must reach the load balancer’s exact anycast IP on port 80/443. If DNS points anywhere else, the domain is “not visible” to the CA even though it loads for you.

How long does provisioning take after I fix DNS? Usually 15-60 minutes once the domain resolves to the LB IP, but DNS propagation can extend that to several hours. Google retries automatically; you do not need to recreate the cert unless it stays failed after DNS is confirmed correct.

Do I need to open port 80 for HTTP? The domain-authorization challenge is served by Google’s infrastructure on the load balancer IP, so you do not run your own challenge responder. You do need the global forwarding rule and reserved IP in place so that IP is live and reachable.

Can I use a managed cert with an internal load balancer? Managed certificates require a publicly reachable domain and IP for validation, so they work with external HTTPS load balancers. Internal load balancers must use self-managed (or Certificate Manager) certificates.

My cert has two domains and only one shows FAILED_NOT_VISIBLE — why? Each domain is validated independently. The whole cert cannot go ACTIVE until every domain validates. Fix DNS for the failing hostname; the domainStatus map tells you exactly which one is blocking.

Should I delete and recreate, or just wait? Wait first if DNS was just corrected. Recreate only when DNS resolves to the LB IP, the cert is attached to a live proxy, and the status is still FAILED_NOT_VISIBLE after an hour, to force a fresh validation cycle.