Creating and Using 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 SSL certificate information.

SSL certificate resources are used only with load balancing
proxies such as a
target HTTPS proxy or
target SSL proxy.
See that documentation for when and how to use SSL certificate resources.

Note: SSL certificate resources are not used on individual VM instances. On an
instance, install the normal SSL certificate as described in your application
documentation. You do not need to create an SSL certificate resource to use with
SSL certificates on a VM.

Using multiple SSL certificates

You can configure the target proxy of your HTTPS or SSL proxy load balancer with
up 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
RFC 6066, 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)

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)

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 server name 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:

Caution: The above command is provided for testing purposes only. Self-signed
certificates are not suitable for public sites. While a self-signed certificate
implements full encryption, it will cause most browsers to present a warning or
error when visitors try to access your site.

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.

Google Cloud Platform only validates that all certificates in a chain have
valid PEM encoding.
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.

Note: Your private key is stored securely at Google and cannot be viewed.

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 command, in which you can specify
up to ten SSL certificate resources:

gcloud

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

Troubleshooting

Error message when uploading an SSL certificate

You might see the following error message when you try to upload an SSL
certificate:

The SSL certificate could not be parsed.

Google Cloud Platform requires certificates in PEM format.
If the certificate is PEM formatted, it might be invalid.

To validate the certificate, run the following command on a Linux command line,
or on your Cloud Shell:

openssl x509 -in certificate.crt -text -noout

If you see the following response, the certificate is invalid:

unable to load certificate

Expecting: TRUSTED CERTIFICATE

If the invalid file is from a self-generated certificate, you may want to
generate a new certificate using the instructions in
Obtaining a private key and signed certificate.
If it is a certificate supplied by a certificate authority (CA), contact that
CA for help.

Error message when uploading an SSL key

You might see the following error message when you try to upload an SSL
key: