SSL Certificates

To use HTTPS or SSL load balancing, you must create at least one SSL certificate that can be used by the target proxy for the load balancer. You can configure the target proxy with up to ten SSL certificates. For each SSL certificate, you first create an SSL certificate resource. The SSL certificate resource contains the certificate information.

Using multiple SSL certificates

You can configure the target proxy of your HTTPS or SSL proxy load balancer with up to to ten SSL certificates. Use multiple SSL certificates when you are serving from multiple domains using the same load balancer IP address and port, and you want to use a different SSL certificate for each domain. Google Cloud Platform implements Server Name Indication (SNI), as defined in RFC6066, for this purpose.

SSL certificates are used with target HTTPS proxy (TargetHttpsProxy) and target SSL proxy (TargetSslProxy) resources. You must specify at least one SSL certificate for each of these resources and you can specify up to ten. When you specify more than one, the first certificate in the list of SSL certificates is considered the primary SSL certificate associated with the load balancer.

When a client sends a request, the load balancer uses the SNI hostname specified by the client to select the certificate to use in negotiating the client SSL connection. Whenever possible, the load balancer selects a certificate whose common name (CN) or subject alternative name (SAN) matches the SNI hostname specified by the client and which is compatible with the client's ability to use RSA or ECDSA for digital signatures. If none of the available certificates can be selected or if the client does not specify an SNI hostname, the load balancer negotiates SSL using the primary certificate, which is the first certificate in the list.

Multiple SSL certificates (click to enlarge)
Multiple SSL certificates (click to enlarge)

Wildcards in common names

Your SSL certificates can use a wildcard in the common name. For example, a certificate with the common name *.example.com. matches the hostnames www.example.com and foo.example.com, but not a.b.example.com or example.com. When the load balancer selects a certificate, it always prefers to match a hostname to certificates without wildcards over certificates with wildcards.

Certificates with wildcard fragments, such as f*.example.com, are not supported.

Multiple SSL certificate example

Here is an example of how multiple SSL certificates work with HTTPS load balancing. The example assumes that you have three hostnames and three SSL certificates.

How multiple SSL certificates work with HTTPS load balancing (click to enlarge)
How multiple SSL certificates work with HTTPS load balancing (click to enlarge)

The hostnames are:

  • www.example.com
  • www.example.org
  • www.example.net

You are serving content from www.example.com, www.example.org, and www.example.net using the HTTPS load balancer at IP address 203.0.113.1. You want to configure the SSL certificates so that the load balancer uses cert-1 for www.example.com, cert-2 for www.example.org, and cert-3 for www.example.net. You also want the load balancer to use cert-1 when clients do not use SNI or when the client-provided servername does not match any of the available certificates.

The SSL certificates are cert-1, cert-2, and cert-3. SSL certificate cert-1 is the primary certificate. When you create the certificates, you associate each of them with a hostname. In this example, the result is:

  • cert-1:www.example.com
  • cert-2:www.example.org
  • cert-3:www.example.net

If the client uses SNI to provide a hostname during the TLS (SSL) handshake, the load balancer uses the certificate associated with that hostname. For instance, as shown in the illustration above, when user-2’s client provides www.example.org as the SNI hostname during the TLS handshake, the load balancer serves cert-2. If a user’s client does not provide an SNI hostname, or provides one that does not match any of the load balancer’s certificates, the load balancer uses the primary certificate, cert-1.

When you use the primary certificate as a fallback for clients that do support SNI, the client typically reports certificate validation errors when the fallback occurs. This is preferable to failing the handshake on the server side, because it makes debugging easier. However, while users can ignore certificate warnings, intentionally serving requests with a fallback certificate is a poor security practice.

Creating an SSL certificate resource

Obtaining a private key and signed certificate

you need an unencrypted private key and a certificate generated using that key. If you already have a private key and a certificate from a certificate authority, you can skip ahead to Creating an SSL certificate resource. If not, you can create a new private key and generate a self-signed certificate that can be used to create an SSL certificate resource.

To create a new private key, first create a new folder to store your key and certificate, then use openssl to generate the key:

gcloud

$  mkdir ssl_cert
$ cd ssl_cert
$ openssl genrsa -out example.key 2048

To generate a signed certificate, you will need a certificate signing request (CSR). Run the following command to create one:

    $ openssl req -new -key example.key -out example.csr

You can use your new CSR to obtain a valid certificate from a certificate authority. Alternatively, you can generate a self-signed certificate by running the following:

    $ openssl x509 -req -days 365 -in example.csr -signkey example.key -out example.crt

Creating an SSL certificate resource from existing certificate files

You can create an SSL certificate resource by running the following command. You must already have a certificate to run this command.

gcloud

gcloud compute ssl-certificates create [SSL_CERTIFICATE] \
    --certificate [CRT_FILE_PATH] \
    --private-key [KEY_FILE_PATH]

  • [SSL_CERTIFICATE]: the name you want to give the certificate resource.
  • [CRT_FILE_PATH]: the path and filename of your certificate file (.crt file).
  • [KEY_FILE_PATH]: the path and filename of your key file (.key file).

GCP only validates that all certificates in a chain have valid PEM formats. It does not validate whether all certificates are chained in a legitimate way. It is your responsibility to provide valid certificate chains.

If you are configuring a load balancer with multiple SSL certificates, make sure that you create an SslCertificate resource for each certificate.

Viewing SSL certificate resource properties

To see information about your SSL certificate resource, run the following command:

gcloud compute ssl-certificates describe [SSL_CERTIFICATE]
  • [SSL_CERTIFICATE]: the name of the SSL certificate resource.

Listing SSL certificate resources

To view a list of all of your SSL certificate resources, run the following command:

gcloud compute ssl-certificates list

Updating a proxy to use a different SSL certificate resource

To update the certificates associated with a target HTTPS proxy or target SSL proxy, first create any new SSL certificate resources, then update the proxy using the appropriate command.

For target HTTPS proxies, use the following, in which you can specify up to ten SSL certificate resources:

gcloud compute target-https-proxies update [PROXY_NAME] \
    --ssl-certificates [SSL_CERT_1][,[SSL_CERT_2],...]
  • [PROXY_NAME]: the name of the target-https-proxies resource you are updating.
  • [[SSL_CERT_1][,[SSL_CERT_2],...]: the full list of up to ten names of the SslCertificate resources.

For target SSL proxies, use the following, in which you can specify up to ten SSL certificate resources:

gcloud compute target-ssl-proxies update  [PROXY_NAME] \
    --ssl-certificates [SSL_CERT_1][,[SSL_CERT_2],...]
  • [PROXY_NAME]: the name of the target-ssl-proxies resource you are updating.
  • [SSL_CERT_1][,[SSL_CERT_2],...]: the full list of up to ten names of the SslCertificate resources.

Deleting an SslCertificate resource

To delete one or more SslCertificate resources:

Console


  1. In the left panel of the Edit HTTP(S) load balancer page, click Frontend configuration.
  2. In the right panel, click the X next to the certificate resource you want to delete.
  3. Click Done.

gcloud

gcloud compute ssl-certificates delete [SSL_CERT_1][,[SSL_CERT_2],...]

  • [SSL_CERTIFICATE]: the name of the SslCertificate resource you are deleting.

Monitor your resources on the go

Get the Google Cloud Console app to help you manage your projects.

Send feedback about...

Compute Engine Documentation