This page discusses how to create and use Compute EngineGoogle-managed SSL certificates.

To create Google-managed certificates using Certificate Manager, seeDeployment overview.

Google-managed SSL certificates are Domain Validation (DV) certificates thatGoogle Cloud obtains and manages for your domains. They support multiplehostnames in each certificate, and Google renews the certificates automatically.

Google-managed certificates are supported with the following load balancers:

• Global external Application Load Balancer
• Classic Application Load Balancer
• External proxy Network Load Balancer (with a target SSL proxy)

Compute Engine Google-managed SSL certificates aren't supported forregional external Application Load Balancers, regional internal Application Load Balancers, orcross-region internal Application Load Balancers. For these load balancers, you caneither useCompute Engine self-managed SSLcertificates orconsider usingCertificate Managerinstead.

You can also use managed SSL certificates with Google Kubernetes Engine. For moreinformation, seeUsing Google-managed SSLcertificates.

You can create a Google-managed certificate before, during, or after creatingyour load balancer. This page assumes that you're creating theCompute Engine certificate before or after creating the load balancer,not during. To create the certificate while creating your load balancer,see the load balancer how-to pages.

Before you begin

• Make sure that you are familiar with theSSL certificates overview.
• Make sure that you have the domain names that you want to use for yourGoogle-managed SSL certificate. If you're usingCloud Domains, seeRegister a domain.

• Make sure that you've enabled the Compute Engine API for your project.

  Enable the Compute Engine API

Permissions

To follow this guide, you must be able to create and modify SSL certificates inyour project. You can do this if one of the following is true:

• You are a projectOwner orEditor (roles/owner orroles/editor).
• You have both theCompute Security Admin role(compute.securityAdmin) and theCompute Network Admin role(compute.networkAdmin) in the project.
• You have a custom role for the project that includes thecompute.sslCertificates.* permissions and one or both ofcompute.targetHttpsProxies.* andcompute.targetSslProxies.*, depending onthe type of load balancer that you are using.

Step 1. Create a Google-managed SSL certificate

You can create a Google-managed certificate before, during, or after creatingyour load balancer. During the process of creating a load balancer in theGoogle Cloud console, you can use the Google Cloud console to create yourcertificate. Alternatively, you can create your certificate before or aftercreating your load balancer. This step shows you how to create a certificatethat you can later add to one or more load balancers.

If you have already created your Google-managed SSL certificate, you can skipthis step.

gcloud compute ssl-certificates createCERTIFICATE_NAME \    --description=DESCRIPTION \    --domains=DOMAIN_LIST \    --global

resource "google_compute_managed_ssl_certificate" "lb_default" {  provider = google-beta  name     = "myservice-ssl-cert"  managed {    domains = ["example.com"]  }}

POSThttps://compute.googleapis.com/compute/v1/projects/<var>PROJECT_ID</var>/global/sslCertificates{"name":"ssl-certificate-name","managed":{"domains":["www.example.com"]},"type":"MANAGED"}

Check the status of a Google-managed SSL certificate

gcloud compute ssl-certificates list \   --global

gcloud compute ssl-certificates describeCERTIFICATE_NAME \   --global \   --format="get(name,managed.status, managed.domainStatus)"

At this point, the certificate status and the domain status arePROVISIONING.After you complete the steps on this page, the statuses change toACTIVE.

For more information about the statuses, see thetroubleshootingpage.

Step 2: Create or update your load balancer

To becomeACTIVE, the Google-managed SSL certificate must be associatedwith a load balancer, specifically the load balancer's target proxy.

After you've created your SSL certificate and it's in thePROVISIONING state,you can use it during the creation of your load balancer, as described in thefollowing how-to guides:

• Set up a global external Application Load Balancer with a Compute Enginebackend
• Set up a classic Application Load Balancer with a Compute Enginebackend
• Set up an external proxy Network Load Balancer with an SSL proxy

Or you can use it to update an existing load balancer, as described here:

gcloud compute target-https-proxies updateTARGET_PROXY_NAME \    --ssl-certificatesSSL_CERTIFICATE_LIST \    --global-ssl-certificates \    --global

gcloud compute target-ssl-proxies updateTARGET_PROXY_NAME \    --ssl-certificatesSSL_CERTIFICATE_LIST

resource "google_compute_target_https_proxy" "lb_default" {  provider = google-beta  name     = "myservice-https-proxy"  url_map  = google_compute_url_map.lb_default.id  ssl_certificates = [    google_compute_managed_ssl_certificate.lb_default.name  ]  depends_on = [    google_compute_managed_ssl_certificate.lb_default  ]}

Each target HTTPS proxy or target SSL proxy must reference at least one SSLcertificate. A target proxy can reference more than one SSL certificate.For details, seeTarget pools andtarget proxies inthe load balancing resource quotas and limits.

If you don't already know the name of the target proxy, use thegcloud compute target-https-proxies listandgcloud compute target-ssl-proxies listcommands to list the target proxies in your project.

Verify association between the SSL certificate and the target proxy byrunning the following command.

For global external Application Load Balancers:

gcloud compute target-https-proxies describeTARGET_HTTPS_PROXY_NAME \    --global \    --format="get(sslCertificates)"

For external proxy Network Load Balancers:

gcloud compute target-ssl-proxies describeTARGET_SSL_PROXY_NAME \    --format="get(sslCertificates)"

At this point, your Google-managed certificate status might still bePROVISIONING. Google Cloud is working with the Certificate Authority toissue the certificate. Provisioning a Google-managed certificate might take upto 60 minutes.

Step 4: Update the DNS A and AAAA records to point to the load balancer's IP address

Your DNS records might be managed at your registrar's site, DNS host, or ISP.

While managing your records, note the following:

• Ensure that DNS A records (for IPv4) and DNS AAAA records (for IPv6)for your domains and any subdomains point to the IP address associated withthe load balancer's forwarding rule or rules.

  To provision SSL certificates, ensure that A and AAAA records point to the load balancer's IP address at a public DNS.

• If you're usingCloud DNS,set upyour domains andupdate your nameservers.

• If you have multiple domains in a Google-managed certificate, add or updateDNS records for all domains and subdomains to point to your load balancer'sIP address. The certificate validation fails if the domains and subdomains in a Google-managed certificate point to another IP than the load balancer's forwarding rule IP address.

• Ensure that your DNS provider responds consistently to all theglobal domainvalidation requests.

Managed certificates provision successfully when the following are true:

• Your domain's DNS records use a CNAME record that points to another domain.
• The other domain contains an A or AAAA record that points to your loadbalancer's IP address.

dig www.example.com

;<<>> DiG 9.10.6<<>> www.example.com;; global options: +cmd;; Got answer:;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31748;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1;; OPT PSEUDOSECTION:; EDNS: version: 0, flags:; udp: 512;; QUESTION SECTION:;www.example.com.           IN  A;; ANSWER SECTION:www.example.com. 1742    IN      CNAME   example.net.example.net.      12     IN      A       34.95.64.10;; Query time: 43 msec;; SERVER: 8.8.8.8#53(8.8.8.8);; WHEN: Wed Jun 03 16:54:44 PDT 2020;; MSG SIZE  rcvd: 193

DNS resolvers on the internet are outside the control ofGoogle Cloud. They cache your resource record sets according to theirtime to live (TTL), which means that adig ornslookup command might returna cached value. If you are using Cloud DNS, seePropagation ofchanges.

gcloud compute ssl-certificates describeCERTIFICATE_NAME \    --format="get(managed.domainStatus)"

For detailed information, see theGoogle-managed SSLcertificate domain status section on the Troubleshootingpage.

Multi-perspective domain validation

Google Cloud periodically renews your Google-managed certificates by requestingthem from certificate authorities (CAs). The CAs thatGoogle Cloud works with to renew your certificates use a multi-perspectivedomain validation method known asMulti-Perspective Issuance Corroboration(MPIC).As part of this process, the certificate authorities verify domain control bychecking the domain's DNS settings and attempting to contact the serverbehind the domain's IP address.These verifications are conducted from multiple vantage points across theinternet. If the validation process fails, Google-managed certificates fail torenew. As a result, your load balancer serves an expired certificate to clients,causing browser users to encounter certificate errors and API clients toexperience connection failures.

To prevent multi-perspective domain validation failures for misconfigured DNSrecords, note the following:

• Your DNS A records (IPv4) and DNS AAAA (IPv6) records for your domains and any subdomains pointonly to the IP address (or addresses) associated with the load balancer's forwarding rule (or rules). The existence of any other addresses in the record can cause validation to fail.
• The CA, which performs validation of DNS records, queries DNS records from multiple locations. Ensure that your DNS provider responds consistently to all the global domain validation requests.
• Using GeoDNS (returning different IP addresses based on the request location) or location-based DNS policies can lead to inconsistent responses and cause validation to fail. If your DNS provider uses GeoDNS, disable it, or ensure that all regions return the same load balancer's IP address.
• You must explicitly specify the IP addresses of your load balancer in your DNS configuration. Intermediate layers, such as a CDN, can cause unpredictable behavior. The IP address needs to be directly accessible without any redirects, firewalls, or CDNs in the request path. To learn more, see theLoad balancers behind a CDN section in this document.
• We recommended that you use a DNS global propagation checker of your choice to verify that all the relevant DNS records resolve correctly and consistently across the globe.

Verify configuration changes

After you have configured your DNS records, you can verify that they are correctby creating a new certificate and connecting it to your load balancer along withthe existing certificate. This step forces an immediate certificate provisioningcheck with the CA, letting you verify your configurationchanges within minutes. Without this, automatic renewals of the existingcertificate can take days or weeks, leaving uncertainty about your setup.

If thecertificate status becomesACTIVE, it indicates thatthe certificate has been issued, thereby confirming that your DNS configurationis correct. At this point, we recommend that you remove the earlier certificateto avoid having two separate certificates for the same domain. This processdoesn't interrupt traffic to your load balancer.

The new certificate serves as a validation tool—its creation confirms thatmulti-perspective domain validation using MPIC works correctly for your setup.

Load balancers behind a CDN

For load balancers that have CDN enabled, some third-party CDN providers in therequest path might prevent validation requests from succeeding. This can happenif the CDN provider is actively proxying HTTP(S) traffic.

In such cases, we recommendmigrating your certificates toCertificate Manager and using theDNS authorizationmethod to provision Google-managed certificates. The latter approach doesn'trequire the CA to contact your load balancer.

Step 5: Test with OpenSSL

After thecertificate and domain statuses areactive, it can take up to 30 minutes for yourload balancer to begin using your Google-managed SSL certificate.

To test, run the following OpenSSL command, replacingDOMAIN withyour DNS name andIP_ADDRESS with the IP address of yourload balancer.

echo | openssl s_client -showcerts -servernameDOMAIN -connectIP_ADDRESS:443 -verify 99 -verify_return_error

This command outputs the certificates that the load balancer presentsto the client. Along with other detailed information, the output shouldinclude the certificate chain andVerify return code: 0 (ok).

Additional procedures

This section contains additional procedures for managing your certificates.

Support multiple domains with a Google-managed SSL certificate

Multiple subject alternative names are supported. Each Google-managedSSL certificate supports up tothe maximum number of domains perGoogle-managed SSL certificate.

If you have more than the maximum number of domains, you must request multipleGoogle-managed certificates. For example, if you try to create a Google-managedcertificate with (the maximum +1) domains, Google doesn't issue any certificates. Instead, you must create twoor more Google-managed certificates and explicitly state which domains areassociated with each certificate.

Google Cloud implements Server Name Indication (SNI), as defined inRFC 6066.

To help ensure that your certificates don't fail the domain validation step ofthe renewal process, review therequirements for your DNS A and AAAArecords.

You cannot modify the list of domain names on an existing Google-managedSSL certificate. If you need to add or remove a domain, you must create a newcertificate that includes all the domains you want to secure, and then use thereplacement process described in this document.

Renew a Google-managed SSL certificate

Google Cloud provisions managed certificates valid for 90 days. About onemonth before expiry, the process to renew your certificate automatically begins.For this, a Certificate Authority (CA) is chosen that's both in your domain'sCertification Authority Authorization (CAA) DNS record and inthe list ofCAs.

The CA used for renewal might be different from the CA used to issue a previousversion of your Google-managed certificate. You can control the CA thatGoogle Cloud uses for renewal by ensuring that your domain's CAA DNSrecord specifies a single CA from the list of CAs that Google-managedcertificates use.

To help ensure that your certificates don't fail the domain validation step ofthe renewal process, review therequirements for your DNS A and AAAArecords.

Specify the CAs that can issue your Google-managed certificate

In your DNS software, we recommend that you explicitly authorize the CAs thatyou want to allow to issue your Google-managed certificate. While not requiredin every scenario, this is necessary in certain situations.

For example, if you're using an external DNS service and your Google-managedcertificate is revoked, the service might only validate a new certificate issuedby one or more specific CAs.

To do this, create or modify a CAA record to includepki.goog orletsencrypt.org or both. If you don't have a CAA record, the default behavioris to allow bothpki.goog andletsencrypt.org.

DOMAIN. CAA 0 issue "pki.goog"DOMAIN. CAA 0 issue "letsencrypt.org"

Support forletsencrypt.org certificates is provided on a best-effortbasis. For best reliability, allow bothpki.goog andletsencrypt.org. If youspecify just one of the CAs, only that CA is used to create and renew yourcertificate. This approach isn't recommended.

When you first create your certificate, Google Cloud selects eitherpki.goog orletsencrypt.org and uses it to issue your certificate. WhenGoogle renews your certificate, your certificate might be issued by the other CA,depending on the CAs that you have specified in the CAA record (if you created one).Your certificate might be renewed by a different CA in either of the followingcases:

• You don't have a DNS CAA record for your domain.
• You have included both the CAs in the DNS CAA record.

For more information, see the RFC,CAA DNSrecord.

letsencrypt.org issuesInternationalized Domain Names(IDNs).pki.googdoesn't currently support IDNs.

If you're using Cloud DNS, learn how toadd a record, and make sure to setthe--type flag toCAA.

Replace an existing SSL certificate

To replace an existing SSL certificate:

1. Start the process for creating the replacement Google-managed SSL certificate.This certificate does not become ACTIVE at this point.

2. Update the target proxy so that the list of referenced certificates includesthe replacement SSL certificate along with the current SSL certificates. Thesteps to update the target proxy vary, as follows:

   • Update a target HTTPS proxy
   • Update a target SSL proxy
   Note: To keep serving traffic, the target proxy must continue referencingthe current SSL certificates. For the replacement certificate to completeits provisioning process, the target proxy must reference the replacementcertificate as well.

3. Wait for the replacement SSL certificate to complete provisioning.Provisioning might take up to 60 minutes. When provisioning is complete, thecertificate status becomesACTIVE.

   Note: Provisioning a Google-managed certificate might take up to60 minutes from the moment your DNS and load balancer configuration changes have propagated across the internet. If you have updated your DNS configuration recently, it can take a significant amount of time for the changes tofully propagate. Sometimes propagation takes up to 72 hours worldwide, although it typically takes a few hours. For more information on DNS propagation, seePropagation of changes.

4. Wait an additional 30 minutes to ensure that the replacement certificate isavailable to all Google Front Ends (GFEs).

5. Update the target proxy to remove the SSL certificate that you're replacingfrom the list of referenced certificates. The steps to update a target proxyvary, as follows:

   • Update a target HTTPS proxy
   • Update a target SSL proxy

6. Wait 10 minutes, and confirm that the load balancer is using the replacementSSL certificate instead of the old one.

7. Update the target proxy again, removing the old SSL certificate resource. Youcandelete the SSL certificate resource if it's no longerreferenced by any target proxy.

If you don't delete the old SSL certificate, it remains ACTIVE until it expires.

Migrate from self-managed SSL certificates to Google-managed SSL certificates

When you migrate a load balancer from using self-managed SSL certificates toGoogle-managed SSL certificates, you must perform the following steps in thissequence:

1. Create a new Google-managed certificate.
2. Associate new Google-managed certificate with the correct targetproxy while maintaining the target proxy'sassociation with the existing self-managed certificate.
3. Wait until theGoogle-managed certificatestatus isACTIVE.
4. Wait 30 minutes to allow the new certificate to propagate to serving GoogleFront Ends (GFEs)
5. Update the target proxy again, removing the self-managed certificateresource. You candelete the self-managed SSL certificateresourceif it's no longer referenced by any target proxy.

• Delete the target proxies that reference this certificate.

• Update the target proxies that reference this certificate to exclude it. The stepsvary, as follows:

  • Update an HTTPS target proxy.
  • Update an SSL target proxy.

To delete one or more SSL certificates:

gcloud compute ssl-certificates deleteCERTIFICATE_NAME \    --global

What's next

• To troubleshoot SSL certificates, seeTroubleshooting SSLcertificates.
• To use a Terraform script that creates a Google-managed certificate, seetheCloud Runexampleon theTerraform module examples for external Application Load Balancer page.