Google Cloud Load Balancer Managed SSL Certificates and Cloud DNS: How Long Before PROVISIONING Fails?

Answer to the core question

Google‑managed certificates stay in the PROVISIONING state until the Certificate Authority (CA) can confirm domain control. Google does not publish a fixed timeout for this state – the period is governed by an internal back‑off schedule that is the same for both DNS‑based and load‑balancer‑based authorizations.

In practice, a correctly configured certificate usually becomes ACTIVE within 10–60 minutes. If the state persists for several hours, it is almost always due to a DNS or configuration issue, and the CA will eventually return FAILED_NOT_VISIBLE.

1. Maximum time in PROVISIONING

There is no publicly documented maximum. Empirical observations from many customers suggest that, when the A/AAAA records resolve to the load balancer’s frontend IP, the CA retries for up to a few hours before giving up. The retry window does not differ between DNS and load‑balancer authorizations; both rely on the same internal validation loop.

2. What happens after FAILED_NOT_VISIBLE?

Once the certificate resource reports FAILED_NOT_VISIBLE, the resource cannot be re‑validated in place. The standard recovery path is to delete the certificate and create a new one (or to modify the configuration so that a new validation request is issued). Re‑creating the certificate is inexpensive but does require the certificate to be re‑attached to the HTTPS proxy.

3. Post‑ACTIVE propagation window

Transition to ACTIVE only indicates that the CA has issued the certificate. The certificate is then distributed asynchronously to Google Front End (GFE) edge nodes. During this propagation period – typically a few minutes up to an hour – some edge locations may still serve the previous certificate or a default fallback, which can cause intermittent TLS handshake failures.

What to verify before relying on the timing

• Confirm that the A/AAAA records for the domain resolve to the load balancer’s frontend IP from multiple public resolvers.
• Check the certificate status with gcloud compute ssl-certificates describe [CERT_NAME] --global --format="get(managed.status, managed.domainStatus)" to see which domain, if any, is blocking issuance.
• After the certificate becomes ACTIVE, test handshakes from a few geographic locations (e.g., openssl s_client -connect [IP]:443 -servername [DOMAIN]) to detect any edge‑specific failures.

Uncertainty

Because the internal retry timers are not publicly documented, the exact “maximum” duration is best inferred from observed behavior in your own environment. If you notice a certificate lingering beyond a few hours, it is a strong indicator of a DNS or configuration problem rather than a normal timeout.

Missing diagnostic detail that could change the recommendation

Do you have evidence that the A/AAAA records resolve to the load balancer’s frontend IP from at least two distinct global resolvers? If not, verifying this could clarify whether the delay is due to DNS propagation or a different issue.