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.
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
foo.example.com, but not
example.com. When the load balancer selects a certificate, it always prefers
to match a hostname to certificates without wildcards over certificates with
Certificates with wildcard fragments, such as
f*.example.com, are not
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.
The hostnames are:
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:
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:
$ 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 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 (
[KEY_FILE_PATH]: the path and filename of your 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:
- In the left panel of the Edit HTTP(S) load balancer page, click Frontend configuration.
- In the right panel, click the X next to the certificate resource you want to delete.
- Click Done.
gcloud compute ssl-certificates delete [SSL_CERT_1][,[SSL_CERT_2],...]
[SSL_CERTIFICATE]: the name of the SslCertificate resource you are deleting.