Minimizing downtime is a top priority for cloud architects and DevOps teams migrating workloads from third-party clouds or on-premises environments to Google Cloud. A critical phase of this transition is securing communications by provisioning SSL/TLS certificates.
Google Cloud’s Certificate Manager simplifies certificate provisioning and management at scale. However, when migrating thousands of services under tight constraints, standard authorization paths can present challenges.
This post details a hybrid migration pattern that combines Certificate Manager and Google Public CA to achieve seamless, zero-downtime certificate migration—even when DNS access is limited.
What it is
In Google Cloud, Certificate Manager handles the lifecycle of SSL/TLS certificates for your external load balancers. To request a Google-managed certificate, you must first authorize domain ownership. Certificate Manager supports two primary native authorization methods:
-
DNS authorization: Verifies domain ownership by requiring you to add a specific CNAME record to your DNS configuration.
-
Load balancer (LB) authorization: Verifies domain ownership by checking if the DNS-resolved IP address of your domain points directly to a Google Cloud Load Balancer.
While DNS authorization allows you to provision certificates in advance (enabling zero-downtime migrations), teams often have restricted or slow access to DNS registries. On the other hand, LB authorization is exceptionally simple but creates a “chicken-and-egg” dilemma: the Google Cloud Load Balancer must be actively serving traffic for the domain before a Google-managed certificate can be issued. If you switch your DNS to Google Cloud before the certificate is ready, your clients will experience SSL/TLS handshake errors during the provisioning window.
The Solution: A hybrid workflow utilizing Google Public CA (via ACME HTTP-01 challenges) alongside Certificate Manager’s certificate maps to bridge the gap and achieve a 100% zero-downtime cutover.
Why it matters
When managing complex migrations with thousands of public endpoints, executing changes smoothly and avoiding coordination bottlenecks is vital.
Here is how the hybrid migration pattern compares to traditional methods:
| Authorization Method | Zero Downtime? | DNS Access Required? | Best For |
|---|---|---|---|
| DNS Authorization | Yes | Yes (Requires temporary CNAME records) | Standard migrations where you have direct, rapid access to edit DNS records. |
| Load Balancer Authorization | No (Without this workaround) | No | Simple, new deployments where a short initial setup window is acceptable. |
| Hybrid Migration (Our Method) | Yes | No (Until the final cutover) | Large-scale migrations with restricted DNS access or complex approval workflows. |
Key benefits
-
Zero handshake failures: Production traffic transitions smoothly from your legacy provider to Google Cloud without any SSL/TLS negotiation errors.
-
No DNS bottlenecks: Eliminates the need to coordinate thousands of pre-migration CNAME additions with external DNS teams.
-
Automated lifecycle management: Post-migration, the system seamlessly transitions to Google-managed certificates, eliminating the long-term operational overhead of manual renewals.
How it works
This hybrid pattern uses Google Public CA to issue an ephemeral, trusted certificate “in-flight” while the domain still points to your legacy hosting provider. Once the load balancer is secure and traffic is routed to Google Cloud, we transition seamlessly to a Google-managed certificate.
The following architecture diagram outlines the 5-step migration lifecycle:
1. Request a public certificate from Google Public CA
Using an ACME client, you request a public certificate from Google Public CA using the ACME HTTP-01 challenge. Because your production traffic still points to your legacy environment, your legacy servers can easily host the ACME challenge file to prove domain ownership. Google Public CA issues a trusted, public certificate without any changes to your DNS infrastructure.
2. Upload to Certificate Manager and attach to the load balancer
Upload this new certificate to Certificate Manager as a self-managed certificate. Add the certificate to a certificate map and attach this map to your newly configured Google Cloud Load Balancer. The load balancer is now fully staged and ready to serve secure traffic using a valid, trusted SSL/TLS certificate.
3. Switch production traffic to the load balancer
Update your public DNS (A/AAAA/CNAME records) to point to the external IP address of your Google Cloud Load Balancer. Since the load balancer is already serving your valid Public CA certificate, incoming user requests are securely established without any disruption or handshake errors.
4. Request a Google-managed certificate with LB authorization
Now that traffic points to Google Cloud, the domain resolves directly to your Google Cloud Load Balancer. Request a fully Google-managed certificate using the straightforward load balancer authorization method. Once requested, add this new certificate entry to your existing Certificate Map.
5. Remove the self-managed certificate
Once Certificate Manager successfully provisions and activates the Google-managed certificate, safely remove the self-managed certificate entry from the Certificate Map. Your traffic is now secured by an automatically renewed, fully Google-managed certificate.
How to implement
Below is a step-by-step implementation guide using the Google Cloud CLI (gcloud).
Step 1: Upload the temporary certificate to Certificate Manager
After obtaining the certificate from Google Public CA using your preferred ACME client (e.g., Letsencrypt), upload it:
gcloud certificate-manager certificates create migration-cert \
--certificate-file="cert.pem" \
--private-key-file="key.pem"
Step 2: Create a certificate map and associate the certificate
Create a certificate map and bind it to your domain:
# Create the map
gcloud certificate-manager maps create migration-map
# Create a map entry for the self-managed certificate
gcloud certificate-manager maps entries create migration-entry \
--map="migration-map" \
--certificates="migration-cert" \
--hostname="example.com"
(At this stage, you would attach the migration-map to your target HTTPS proxy on your Google Cloud Load Balancer and perform your DNS cutover).
Step 3: Authorize and request the Google-managed certificate
Once the DNS points to your Google Cloud Load Balancer, request the managed certificate using Load Balancer authorization:
# Create a Google-managed certificate with LB authorization
gcloud certificate-manager certificates create managed-cert \
--domains="example.com" \
--scope="all-regions"
# Add the managed certificate as an entry to the same map
gcloud certificate-manager maps entries create managed-entry \
--map="migration-map" \
--certificates="managed-cert" \
--hostname="example.com"
Step 4: Clean up
After verification that the managed certificate status is ACTIVE, clean up the temporary resource:
# Delete the temporary self-managed certificate entry
gcloud certificate-manager maps entries delete migration-entry \
--map="migration-map"
Call to action
Ready to plan your migration? Explore the resources below to implement secure, zero-downtime migrations in your environment: