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.

If you are using an HTTPS connection from the target proxy to the backend instances, each VM instance must have its own SSL certificate.

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. 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.

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 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

Note: This example uses RSA-2048 encryption. Currently, only RSA-2048 and ECDSA P-256 encryption are supported.

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

Caution: 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. The above command is provided for testing purposes only.

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.

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. Use these instructions when your certificate is new or when you replace an expiring certificate with a renewed certificate.

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.

Troubleshooting

Error message when uploading an SSL certificate

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

{"ResourceType":"compute.v1.sslCertificate","ResourceErrorCode":"SSL_CERTIFICATE_COULD_NOT_PARSE_CERT","ResourceErrorMessage":"The SSL certificate could not be parsed."}

The SSL certificate might not be PEM encoded, which is required by Google Cloud Platform, or it might otherwise be invalid.

To obtain more information about the certificate, run the following command on the local host command line:

    openssl x509 -in certificate.crt -text -noout

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

unable to load certificate 140052259522208:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: TRUSTED CERTIFICATE

To obtain more information about the key, run the following command:

    openssl rsa -in privateKey.key -check

If you see the following responses, the key is invalid:

unable to load Private Key 140663224432288:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:703:Expecting: ANY PRIVATE KEY

RSA key error: n does not equal p q RSA key error: d e not congruent to 1 RSA key error: dmp1 not congruent to d RSA key error: dmq1 not congruent to d RSA key error: iqmp not inverse of q

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.