Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

Chapter 15. Enabling SSL/TLS on Overcloud Public Endpoints

By default, the overcloud uses unencrypted endpoints for its services. This means that the overcloud configuration requires an additional environment file to enable SSL/TLS for its Public API endpoints. The following chapter shows how to configure your SSL/TLS certificate and include it as a part of your overcloud creation.


This process only enables SSL/TLS for Public API endpoints. The Internal and Admin APIs remain unencrypted.

This process requires network isolation to define the endpoints for the Public API.

15.1. Initializing the Signing Host

The signing host is the host that generates new certificates and signs them with a certificate authority. If you have never created SSL certificates on the chosen signing host, you might need to initialize the host so that it can sign new certificates.

The /etc/pki/CA/index.txt file stores records of all signed certificates. Check if this file exists. If it does not exist, create an empty file:

$ sudo touch /etc/pki/CA/index.txt

The /etc/pki/CA/serial file identifies the next serial number to use for the next certificate to sign. Check if this file exists. If it does not exist, create a new file with a new starting value:

$ echo '1000' | sudo tee /etc/pki/CA/serial

15.2. Creating a Certificate Authority

Normally you sign your SSL/TLS certificates with an external certificate authority. In some situations, you might aim to use your own certificate authority. For example, you might aim to have an internal-only certificate authority.

For example, generate a key and certificate pair to act as the certificate authority:

$ sudo openssl genrsa -out ca.key.pem 4096
$ sudo openssl req  -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem

The openssl req command asks for certain details about your authority. Enter these details.

This creates a certificate authority file called ca.crt.pem.

15.3. Adding the Certificate Authority to Clients

For any external clients aiming to communicate using SSL/TLS, copy the certificate authority file to each client that requires access your Red Hat OpenStack Platform environment. Once copied to the client, run the following command on the client to add it to the certificate authority trust bundle:

$ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
$ sudo update-ca-trust extract

For example, the undercloud requires a copy of the certificate authority file so that it can communicate with the overcloud endpoints during creation.

15.4. Creating an SSL/TLS Key

Run the following commands to generate the SSL/TLS key (server.key.pem), which we use at different points to generate our undercloud or overcloud certificates:

$ openssl genrsa -out server.key.pem 2048

15.5. Creating an SSL/TLS Certificate Signing Request

This next procedure creates a certificate signing request for the overcloud. Copy the default OpenSSL configuration file for customization.

$ cp /etc/pki/tls/openssl.cnf .

Edit the custom openssl.cnf file and set SSL parameters to use for the overcloud. An example of the types of parameters to modify include:

distinguished_name = req_distinguished_name
req_extensions = v3_req

countryName = Country Name (2 letter code)
countryName_default = AU
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Queensland
localityName = Locality Name (eg, city)
localityName_default = Brisbane
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = Red Hat
commonName = Common Name
commonName_default =
commonName_max = 64

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

IP.1 =
DNS.1 =
DNS.2 =

Set the commonName_default to one of the following:

  • If using an IP to access over SSL/TLS, use the Virtual IP for the Public API. Set this VIP using the PublicVirtualFixedIPs parameter in an environment file. For more information, see Section 14.4, “Assigning Predictable Virtual IPs”. If you are not using predictable VIPs, the director assigns the first IP address from the range defined in the ExternalAllocationPools parameter.
  • If using a fully qualified domain name to access over SSL/TLS, use the domain name instead.

Include the same Public API IP address as an IP entry and a DNS entry in the alt_names section. If also using DNS, include the hostname for the server as DNS entries in the same section. For more information about openssl.cnf, run man openssl.cnf.

Run the following command to generate certificate signing request (server.csr.pem):

$ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem

Make sure to include the SSL/TLS key you created in Section 15.4, “Creating an SSL/TLS Key” for the -key option.

Use the server.csr.pem file to create the SSL/TLS certificate in the next section.

15.6. Creating the SSL/TLS Certificate

The following command creates a certificate for your undercloud or overcloud:

$ sudo openssl ca -config openssl.cnf -extensions v3_req -days 3650 -in server.csr.pem -out server.crt.pem -cert ca.crt.pem -keyfile ca.key.pem

This command uses:

This results in a certificate named server.crt.pem. Use this certificate in conjunction with the SSL/TLS key from Section 15.4, “Creating an SSL/TLS Key” to enable SSL/TLS.

15.7. Enabling SSL/TLS

Copy the enable-tls.yaml environment file from the Heat template collection:

$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.

Edit this file and make the following changes for these parameters:


Copy the contents of the certificate file (server.crt.pem) into the SSLCertificate parameter. For example:

  SSLCertificate: |
    -----END CERTIFICATE-----

If you have an intermediate certificate, copy the contents of the intermediate certificate into the SSLIntermediateCertificate parameter:

  SSLIntermediateCertificate: |
    -----END CERTIFICATE-----

The certificate contents require the same indentation level for all new lines.


Copy the contents of the private key (server.key.pem) into the SSLKey parameter. For example:

  SSLKey: |
    -----END RSA PRIVATE KEY-----

The private key contents require the same indentation level for all new lines.


Change the resource path for OS::TripleO::NodeTLSData: to an absolute path:

  OS::TripleO::NodeTLSData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/tls-cert-inject.yaml

15.8. Injecting a Root Certificate

If the certificate signer is not in the default trust store on the overcloud image, you must inject the certificate authority into the overcloud image. Copy the inject-trust-anchor.yaml environment file from the heat template collection:

$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/inject-trust-anchor.yaml ~/templates/.

Edit this file and make the following changes for these parameters:


Copy the contents of the root certificate authority file (ca.crt.pem) into the SSLRootCertificate parameter. For example:

  SSLRootCertificate: |
    -----END CERTIFICATE-----

The certificate authority contents require the same indentation level for all new lines.


Change the resource path for OS::TripleO::NodeTLSCAData: to an absolute path:

  OS::TripleO::NodeTLSCAData: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/tls/ca-inject.yaml

If you want to inject multiple CAs, you can use the inject-trust-anchor-hiera.yaml environment file. For example, you can inject the CA for both the undercloud and overcloud simultaneously:

      content: |
        -----BEGIN CERTIFICATE-----
        ... cert content ...
        -----END CERTIFICATE-----
      content: |
        -----BEGIN CERTIFICATE-----
        ... cert content ...
        -----END CERTIFICATE-----

15.9. Configuring DNS endpoints

If using a DNS hostname to access the overcloud through SSL/TLS, you will need to copy the custom-domain.yaml file into /home/stack/templates. You can find this file in /usr/share/tripleo-heat-templates/environments/predictable-placement/.

  1. Configure the host and domain names for all fields, adding parameters for custom networks if needed:


    It is not possible to redeploy with a TLS-everywhere architecture if this environment file is not included in the initial deployment.

    # title: Custom Domain Name
    # description: |
    #   This environment contains the parameters that need to be set in order to
    #   use a custom domain name and have all of the various FQDNs reflect it.
      # The DNS domain used for the hosts. This must match the overcloud_domain_name configured on the undercloud.
      # Type: string
      CloudDomain: localdomain
      # The DNS name of this cloud. E.g.
      # Type: string
      CloudName: overcloud.localdomain
      # The DNS name of this cloud's provisioning network endpoint. E.g. ''.
      # Type: string
      CloudNameCtlplane: overcloud.ctlplane.localdomain
      # The DNS name of this cloud's internal_api endpoint. E.g. ''.
      # Type: string
      CloudNameInternal: overcloud.internalapi.localdomain
      # The DNS name of this cloud's storage endpoint. E.g. ''.
      # Type: string
      # The DNS name of this cloud's storage_mgmt endpoint. E.g. ''.
      # Type: string
      CloudNameStorageManagement: overcloud.storagemgmt.localdomain
  2. Add a list of DNS servers to use under parameter defaults, in either a new or existing environment file:

      DnsServers: [""]

15.10. Adding Environment Files During Overcloud Creation

The deployment command (openstack overcloud deploy) uses the -e option to add environment files. Add the environment files from this section in the following order:

  • The environment file to enable SSL/TLS (enable-tls.yaml)
  • The environment file to set the DNS hostname (cloudname.yaml)
  • The environment file to inject the root certificate authority (inject-trust-anchor.yaml)
  • The environment file to set the public endpoint mapping:

    • If using a DNS name for accessing the public endpoints, use /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml
    • If using a IP address for accessing the public endpoints, use /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-ip.yaml

For example:

$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml

15.11. Updating SSL/TLS Certificates

If you need to update certificates in the future:

  • Edit the enable-tls.yaml file and update the SSLCertificate, SSLKey, and SSLIntermediateCertificate parameters.
  • If your certificate authority has changed, edit the inject-trust-anchor.yaml file and update the SSLRootCertificate parameter.

Once the new certificate content is in place, rerun your deployment command. For example:

$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml