Using self-managed SSL certificates

Self-managed SSL certificates are certificates that you obtain, provision, and renew yourself. You can use this resource to secure communication between clients and your load balancer.

Self-managed certificates can be any combination of the following certificate types:

  • Domain Validation (DV)
  • Organization Validation (OV)
  • Extended Validation (EV)

This page describes the process of obtaining a valid certificate and then uploading your certificate to create a Google Cloud SSL certificate resource.

Before you begin

Make sure that you are familiar with the SSL certificates overview.

Permissions

To perform the tasks in this guide, you must be able to create and modify SSL certificates in your project. You have these rights if you have one of the following roles or permissions:

  • You are a project owner or editor.
  • You have the compute.securityAdmin role in the project.
  • You have a custom role for the project that includes the compute.sslCertificates.* permissions.

Load balancers

An SSL certificate is required for certain types of Google Cloud load balancers, including:

Creating a private key and certificate

If you already have a private key and a certificate from a certificate authority (CA), skip this section and go to Creating an SSL certificate resource.

Select or create a private key

A Google Cloud SSL certificate includes both a private key and the certificate itself, both in PEM format. Your private key must meet the following criteria:

  • It must be in PEM format.
  • It cannot be protected by a passphrase. Google Cloud stores your private key in its own encrypted format.
  • Its encryption algorithm must be either RSA-2048 or ECDSA P-256.

You can create a new private key with RSA-2048 encryption in the PEM format using the following OpenSSL command.

openssl genrsa -out private-key-file 2048

Replace private-key-file with the path and filename for the new private key file.

Create a CSR

After you have a private key, you can generate a certificate signing request (CSR) in the PEM format using OpenSSL. Your CSR must meet the following criteria:

  • It must be in PEM format.
  • It must have a common name (CN) or a subject alternative name (SAN) attribute. Practically speaking, your certificate should contain both CN and SAN attributes, even if it is for a single domain—modern clients, like the current versions of macOS and iOS don't rely on just the CN attribute.
  1. Create an OpenSSL configuration file. In the following example, subject alternative names are defined in the [sans_list].

    cat <<'EOF' >config-file
    [req]
    default_bits              = 2048
    req_extensions            = extension_requirements
    distinguished_name        = dn_requirements
    
    [extension_requirements]
    basicConstraints          = CA:FALSE
    keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
    subjectAltName            = @sans_list
    
    [dn_requirements]
    countryName               = Country Name (2 letter code)
    stateOrProvinceName       = State or Province Name (full name)
    localityName              = Locality Name (eg, city)
    0.organizationName        = Organization Name (eg, company)
    organizationalUnitName    = Organizational Unit Name (eg, section)
    commonName                = Common Name (e.g. server FQDN or YOUR name)
    emailAddress              = Email Address
    
    [sans_list]
    DNS.1                     = subject-alternative-name-1
    DNS.2                     = subject-alternative-name-2
    
    EOF
    
  2. Run the following OpenSSL command to create a certificate signing request (CSR) file. The command is interactive; you are prompted for attributes except for the subject alternative names, which you defined in the [sans_list] of the config-file in the previous step.

    openssl req -new -key private-key-file \
        -out csr-file \
        -config config-file
    

For both steps, replace the placeholders with valid values:

  • config-file: The path, including the file name, for the OpenSSL configuration file. (You can delete the file after you complete this procedure.)
  • subject-alternative-name-1 and subject-alternative-name-2: Subject Alternative Names for your certificate. If your certificate is only for one host name, you should only define a single subject alternative name that matches the Common Name. If you need more than two subject alternative names, add them to the configuration file, incrementing the number after DNS (DNS.3, DNS.4, etc.).
  • private-key-file: The path to the private key file
  • csr-file: The path, including the file name, for the CSR

Sign the CSR

When a Certificate Authority (CA) signs your CSR, it uses its own private key to create a certificate:

Using a publicly-trusted CA

  • If you request a publicly-trusted CA to sign your CSR, the resulting certificate is trusted by all clients that trust that public CA.
  • To produce a signed certificate, the public CA only needs your CSR.

Managing your own CA

  • If you manage your own CA, you can use it to sign your CSR. This creates an internally-trusted certificate. This creates an internally-trusted certificate when your clients have also been configured to trust your own CA.

Using a self-signed certificate

  • If you use the same private key that you used to create the CSR to sign the CSR, you create a self-signed certificate. Self-signed certificates are not trusted by any client unless the client is configured to skip certificate validation. For example, a web browser client displays a message asking you if you want to trust a self-signed certificate. You should only use self-signed certificates for testing.

If you manage your own CA, or if you want to create a self-signed certificate for testing, you can use the following OpenSSL command:

openssl x509 -req \
    -signkey private-key-file \
    -in csr-file \
    -out certificate-file \
    -days term

Replace the placeholders with valid values:

  • private-key-file: The path to the private key for your CA; if creating a self-signed certificate for testing, this private key is the same as the one used to create the CSR.
  • csr-file: The path to the CSR
  • certificate-file: The path to the certificate file to create
  • term: The number of days, from now, during which the certificate should be considered valid by clients that verify it

Wildcards in common names

Your self-managed 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, aren't supported.

Creating a self-managed SSL certificate resource

Before you can create a Google Cloud SSL certificate resource, you must have a private key and certificate. Refer to Creating a private key and certificate if you have not already created or obtained them.

Console

You can work with SSL certificates on the Certificates tab on the Load Balancing page.

  1. Go to the Certificates page in the Google Cloud Console.
    Go to the Certificates page
  2. Click Create SSL certificate.
  3. Enter a name and an optional description for the certificate.
  4. Select Upload my certificate.
  5. Paste in your certificate or click Upload to navigate to your certificate file.
    You can choose to include the CA certificate chain in the same file as the certificate. Google Cloud does not validate the certificate chain for you – validation is your responsibility.
  6. Paste in your private key or click Upload to navigate to your private key file.
  7. Click Create.

gcloud

To create a global SSL certificate that can be used for external HTTP(S) load balancers or SSL proxy load balancers, use the gcloud compute ssl-certificates create command with the --global flag:

gcloud compute ssl-certificates create certificate-name \
    --certificate=certificate-file \
    --private-key=private-key-file \
    --global

To create a regional SSL certificate that can be used for internal HTTP(S) load balancers, use the gcloud compute ssl-certificates create command with the --region flag:

gcloud compute ssl-certificates create certificate-name \
    --certificate=certificate-file \
    --private-key=private-key-file \
    --region=region

Replace the placeholders with valid values:

  • certificate-name: The name of the global certificate resource to create
  • certificate-file: The path to a PEM-formatted certificate file. You can choose to include the CA certificate chain in the same file as the certificate. Google Cloud does not validate the certificate chain for you — validation is your responsibility.
  • private-key-file: The path to a PEM-formatted private key. The private key cannot be protected by a passphrase.
  • region: If applicable, the region for the regional SSL certificate. If this certificate resource is for an internal HTTP(S) load balancer, the region must be the same as the region of the internal HTTP(S) load balancer.

api

For external HTTPS and SSL proxy load balancers, use the sslCertificates.insert API method.

For internal HTTPS load balancers, use the regionSslCertificates.insert API method.

Before you can use these methods, you must first read the certificate and private key files because the API request must send the contents of the files. For code samples, see the API reference page.

Associating an SSL certificate with a target proxy

You must associate at least one SSL certificate with each target HTTPS or SSL proxy. You can configure the target proxy with up to the maximum number of SSL certificates per target HTTPS or target SSL proxy. You can reference multiple self-managed certificates on the same target proxy.

Console

When you use the Google Cloud Console to edit an existing load balancer, you automatically associate the SSL certificate with the appropriate target proxy.

gcloud

To associate a global SSL certificate with a target HTTPS proxy for an external HTTP(S) load balancer, use the gcloud compute target-https-proxies update command with the --global and --global-ssl-certificates flags:

gcloud compute target-https-proxies update target-proxy-name \
    --global \
    --ssl-certificates=certificate-list \
    --global-ssl-certificates

To associate a global SSL certificate with a target SSL proxy for an SSL proxy load balancer, use the gcloud compute target-ssl-proxies update command with the --global and --global-ssl-certificates flags:

gcloud compute target-ssl-proxies update target-proxy-name \
    --global \
    --ssl-certificates=certificate-list \
    --global-ssl-certificates

To associate a regional SSL certificate with a target HTTPS proxy for an internal HTTP(S) load balancer, use the gcloud compute target-https-proxies update command with the --region and --ssl-certificates-region flags:

gcloud compute target-https-proxies update target-proxy-name \
    --region=region \
    --ssl-certificates=certificate-list \
    --ssl-certificates-region=region

Replace the placeholders with valid values:

  • target-proxy-name: The name of the load balancer's target proxy
  • certificate-list: A comma-delimited list of Google Cloud SSL certificate names
  • region: If applicable, the region for the regional target proxy and regional SSL certificate.

Working with self-managed SSL certificates

The following sections describe how to list, view, and delete SSL certificate resources.

Listing SSL certificates

Console

You can check the status of your SSL certificates on the Certificates tab on the Load Balancing page.

  1. Go to the Certificates page in the Google Cloud Console.
    Go to the Certificates page
  2. (Optional) Filter the list of SSL certificates.

gcloud

To list global SSL certificates that can be used for external HTTP(S) load balancers or SSL proxy load balancers, use the gcloud compute ssl-certificates list command with the --global flag:

gcloud compute ssl-certificates list \
   --global

To list regional SSL certificates that can be used for internal HTTP(S) load balancers, use the gcloud compute ssl-certificates list command with the region filter:

gcloud compute ssl-certificates list \
   --filter="region:(region ...)"

Replace the placeholders with valid values:

  • region: A Google Cloud region. Include multiple regions as a space-separated list.

Describing SSL certificates

Console

You can view additional details about your SSL certificates on the Certificates tab on the Load Balancing page.

  1. Go to the Certificates page in the Google Cloud Console.
    Go to the Certificates page
  2. (Optional) Filter the list of SSL certificates.
  3. To view more details, click the certificate name.

gcloud

To describe a global SSL certificate (for external HTTP(S) load balancers or SSL proxy load balancers), use the gcloud compute ssl-certificates describe command with the --global flag:

gcloud  compute ssl-certificates describe certificate-name \
   --global

To describe a regional SSL certificate (for internal HTTP(S) load balancers), use the gcloud compute ssl-certificates describe command with the --region flag:

gcloud compute ssl-certificates describe certificate-name \
   --region=region

Replace the placeholders with valid values:

  • certificate-name: The name of the SSL certificate
  • region: A Google Cloud region

Deleting SSL certificates

To delete one or more SSL certificates:

Console

You can delete SSL certificates on the Certificates tab on the Load Balancing page.

  1. Go to the Certificates page in the Google Cloud Console.
    Go to the Certificates page
  2. Select the SSL certificate that you want to delete.
  3. Click Delete.
  4. To confirm, click Delete again.

gcloud

To delete a global SSL certificate (for external HTTP(S) load balancers or SSL proxy load balancers), use the gcloud compute ssl-certificates delete command with the --global command:

gcloud compute ssl-certificates delete certificate-name \
    --global

To delete a regional SSL certificate (for internal HTTP(S) load balancers), use the gcloud compute ssl-certificates delete command with the --region command:

gcloud compute ssl-certificates delete certificate-name \
    --region=region

Replace the placeholders with valid values:

  • certificate-name: The name of the SSL certificate
  • region: A Google Cloud region

What's next