1. Create a directory for your CA Root pair:

              # ssh root@crowbar
              # mkdir -p ~/ssl/root/ca

2. Create a directory structure and add index.txt and serial files to act as flat database of all signed certificates:

              # cd ~/ssl/root/ca
              # mkdir certs crl newcerts private csr
              # chmod 700 private
              # touch index.txt
              # echo 1000 > serial

This procedure takes you through the full set up. Note that when you setup the crowbar server, there is a structure already setup under /etc/ssl. This is where SUSE Linux typically contains the CA cert bundle created through YaST when the SMT server is set up. However, if you are using an external SMT server you will not have this.

1. Copy /etc/ssl/openssl.cnf file to your setup. We can use this since it is completely annotated.

              # cp /etc/ssl/openssl.cnf ./

2. Edit the file and change the location variable:

              dir = /root/ssl/root/ca
              # Where everything is kept

   

   Note

   Make sure dir is the directory where we created /root/ssl/root/ca.

1. Create the root key encrypted with AES 256-bit encryption and a password, using 4096 bits for the creation.

             # cd ~/ssl/root/ca
             # openssl genrsa -aes256 -out private/cakey.pem 4096

2. You will be asked to enter a password here and then verify it.

             # chmod 400 private/cakey.pem

• Use the root key (cakey.pem) to create the root certificate (cacert.pem). Its important to give it a long expiration since all the certificates signed from it will become invalid when it expires.

             # cd ~/ssl/root/ca
             # openssl req -config openssl.cnf -key private/cakey.pem -new -x509 -days 10950 -sha256 -extensions v3_ca -out cacert.pem
             Enter pass phrase for cakey.pem: enteryourpassword
             You are about to be asked to enter information that will be incorporated
             into your certificate request.
             -----
             Country Name (2 letter code) [AU]:US
             State or Province Name []:Idaho
             Locality Name []:Meridian
             Organization Name []:SUSEDojo
             Organizational Unit Name []:dojo
             Common Name []:susedojo.com
             Email Address []:admin@susedojo.com
  
             # chmod 444 cacert.pem

• Verify the certificate has the correct dates of validity and the algorithm used, Issuer, Subject, and x509v3 extensions. The issuer and subject are the same since it is self signed.

            # cd ~/ssl/root/ca
            # openssl x509 -noout -text -in cacert.pem

1. Modify the penssl.cnf config file and add a line to the [ v3_req ] section:

             # cd ~/ssl/root/ca
             # vi openssl.cnf
             find v3_req
             Add the following line:
             subjectAltName = DNS:public.your_server_name.your_domain.com, DNS: cluster-control.your_domain.com
             At the bottom of the file create section server_cert with the follwing:
             [ server_cert ]
             subjectAltName = subjectAltName = DNS:public.your_server_name.your_domain.com, DNS: cluster-control.your_domain.com

2. The first DNS name would be used if you only have a single node controller as you need the public URL for that server in your cluster. For example, public.db8-ae-ed-77-14-9e.susedojo.com. If you have a haproxy setup for your cluster or pacemaker, you have a cluster URL. For example, you may have public.cluster.your_domain.com and you need to have cluster.your_domain.com and public.cluster.your_domain.com as Alternative DNS names. This public URL can be used for all endpoints unless you have multiple High Availability Clusters for your control plane.

3. Save and close the file after you have those entered correctly.

• Create a key minus the -aes256 option so that you are not presented with a password each time you restart a service. (i.e. Apache service) also in 2048 bit so it is quicker to decrypt.

             # cd ~/ssl/root/ca
             # openssl genrsa -out private/susedojo-com.key.pem 2048
             # chmod 400 private/susedojo-com.key.pem

1. Use the private key we just created to create a certificate signing request (CSR). The common name must be a fully qualified domain name (i.e. www.susedojo.com) The Organization Name must be the same as the Organization Name in the CA.

               # cd ~/ssl/root/ca
               # openssl req -config openssl.cnf -key private/susedojo-com.key.pem -new -sha256 -out csr/susedojo-com.csr.pem
               You are about to be asked to enter information that will be incorporated
               into your certificate request.
               -----
               Country Name (2 letter code) [XX]:US
               State or Province Name []:Idaho
               Locality Name []:Meridian
               Organization Name []:SUSEDojo
               Organizational Unit Name []:dojo
               Common Name []:susedojo.com
               Email Address []:admin@susedojo.com

   

   Note

   You may be prompted for a challenge password and company name. This can be left blank.

2. Create the certificate using the CA to sign the CSR, using the server_cert extension as this will be used on a server. We will give it one year of validity.

               # cd ~/ssl/root/ca
               # openssl ca -config openssl.cnf -extensions server_cert -days 365 -notext -md sha256 -in  csr/susedojo-com.csr.pem -out certs/susedojo-com.cert.pem
                 Using configuration from openssl.cnf
                 Enter pass phrase for /root/ssl/root/ca/private/cakey.pem:
                 Check that the request matches the signature
                 Signature ok
                         Serial Number: 4096 (0x1000)
                         Validity
                           Not Before: Aug  8 04:21:08 2018 GMT
               	          Not After: Aug  8 04:21:08 2019 GMT
                        Subject:
                             countryName               = US
                             stateOrProvinceName       = Idaho
                             organizationName          = SUSEDojo
                             organizationalUnitName    = dojo
                             commonName                = susedojo.com
                             emailAddress              = admin@susedojo.com
                        X509v3 extensions:
                            X509v3 Basic Constraints:
                               CA:FALSE
                           X509v3 Key Usage:
                                 Digital Signature, Non Repudiation, Key Encipherment
                            X509v3 Subject Alternative Name:
                                DNS:public.db8-ae-ed-77-14-9e.susedojo.com
               Certificate is to be certified until Aug  8 04:21:08 2019 GMT (365 days)
               Sign the certificate? [y/n]:y
   
               1 out of 1 certificate requests certified, commit? [y/n]y
               Write out database with 1 new entries
               Data Base Updated
   
               # chmod 444 certs/susedojo-com.cert.pem

3. The index.txt file should now contain a line referring to the new certificate that has been created. For example, the output should look like the following:

               V       190808042108Z           1000    unknown
               /C=US/ST=Idaho/O=SUSEDojo/OU=dojo/CN=susedojo.com/emailAddress=admin@susedojo.com

1. Enter the following in your terminal:

                # openssl x509 -noout -text -in certs/susedojo-com.cert.pem

2. You will notice the Issuer is the CA and you can also see the Subject Alternative Name as well in the extensions section.

                # openssl verify -CAfile cacert.pem certs/susedojo-com.cert.pem
                certs/susedojo-com.cert.pem: OK

1. Now you are ready to copy the newly created certificate and key to the control node or controllers in the cluster.

            # scp newcerts/1000.pem control:/root/
            # scp private/susedojo-com.key control:/root/

2. Copy them into the right location on the controller host:

            # cp susedojo-com.key.pem /etc/keystone/ssl/private
            # cp 1000.pem /etc/keystone/ssl/certs
            # cd /etc/keystone/ssl/certs
            # mv signing_cert.pem signing_cert.pem.todays_date
            # cp 1000.pem signing_cert.pem
            # cd /etc/keystone/ssl/private
            # old signing_key.pem
            # cp susedojo-com.key.pem signing_key.pem

3. Rerun the Barclamp for keystone in order to apply this change to the cluster.

1. Login to your crowbar/admin server change to the root directory.

2. Create a new directory for letsencrypt and clone the acme.sh repo:

            # mkdir letsencrypt
            # cd letsencrypt
            # git clone https://github.com/Neilpang/acme.sh.git
            # cd acme.sh

3. The system is prepared for installing acme.sh.

4. Install socat:

            # export BRANCH=2 #this makes sure you are using the v2 api version of letsencrypt
            # zypper in -y socat

5. Install acme.sh:

            # ./acme.sh --install

6. After the install of acme.sh is finished, you should see a new directory /root/.acme.sh/ where acme.sh lives and all of its environment, account info, and certificates are stored. We recommend using this as a backup location if you are using a backup tool.

OpenStack and wildcard SSL uses the DNS validation method by validating your domain using a TXT record that can either be added manually or using the many (over 3 dozen) available DNS API’s.

Note

It is important to a wildcard certificate as you have the ability to use the same one for all of your public API endpoints in the OpenStack Cloud environment. Additional Cloud Native services like Kubernetes can also take advantage of it.

1. The manual DNS mode is a method that displays the DNS records that have to be created in your DNS servers. It is beneficial to automate the injection of DNS records as the maximum days a certificate is viable is 60 days. In order to issue your wildcard certificate, the command without optional settings is:

           # acme.sh --issue -d yourdomain.com -d *.yourdomain.com --dns

2. To debug or test, add the following optional settings:

           # acme.sh --debug --test –issue -d yourdomain.com -d *.yourdomain.com --dns

3. A message returns. For example:

           Add the following TXT record:
           Domain: '_acme-challenge.yourdomain.com'
           TXT value: 'KZvgq3MpOCjUNW7Uzz5nE5kkFdplNk66WGfxE9-H63k'
           Please be aware that you prepend _acme-challenge. before your domain
           so the resulting subdomain will be: _acme-challenge.yourdomain.com

4. Using this information, you are ready to insert this TXT record into your DNS.

   

   Note

   When setting this up for SUSE OpenStack Cloud with Crowbar, you need to have your external DNS server appended to /etc/resolv.conf in order to resolve as crowbar has its own internal DNS. It is not enough to change it in the barclamp as you need the DNS server entry to be at the top of the list in resolv.conf. Crowbar returns to the default after a period of time. Keep in mind that if you want to automate this step every 90 days then you need to ensure the resolv.conf changes every time to bypass the local crowbar DNS Server.

5. In order to set up TXT record in bind DNS, edit the zone file so it looks like the following example:

           yourdomain.com.     IN NS           admin.yourdomain.com.
           _acme-challenge.yourdomain.com. IN TXT "xxxx...your TXT value string here"

6. Restart your named services for bind.

7. Issue the acme-challenge verification of the previous step with the following command:

           # acme.sh --renew -d yourdomain.com

8. If the DNS validation is okay, acme.sh issues a wildcard certificate and displays the certificate and private-key path. For example:

           Your cert is in:  /root/.acme.sh/susedojo.com/susedojo.com.cer  
           Your cert key is in:  /root/.acme.sh/susedojo.com/susedojo.com.key  
           v2 chain.
           The intermediate CA cert is in:  /root/.acme.sh/susedojo.com/ca.cer  
           And the full chain certs is in:  /root/.acme.sh/susedojo.com/fullchain.cer_on_issue_success

9. Notice the location of your certificate and key. These are now ready to be used by OpenStack Cloud.

10. To automate the process of setting up the TXT record in your DNS servers and prepare it for automated validation, the file account.conf holds account information for the DNS Provider. After exporting the authentication variables, it stores them automatically after the command is executed for later use. To issue your wildcard certificate, the command without optional settings is:

            # export LUA_Key=”your_API_token_from_account”
            # export LUA_Email=”cameron@yourdomain.com”
            # acme.sh -d yourdomain.com -d *.yourdomain.com --dns dns_lua

11. You can now view your DNS records and you will see a new TXT record available. When it is finished and the DNS validation is okay, acme.sh issue your wildcard certificate and displays your certificate and private-key path just as before.

            Your cert is in:  /root/.acme.sh/susedojo.com/susedojo.com.cer  
            Your cert key is in:  /root/.acme.sh/susedojo.com/susedojo.com.key  
            v2 chain.
            The intermediate CA cert is in:  /root/.acme.sh/susedojo.com/ca.cer  
            And the full chain certs is in:  /root/.acme.sh/susedojo.com/fullchain.cer_on_issue_success

1. Create a shared location for all Certificates on the control nodes. Execute these commands on all control nodes and compute nodes:

           mkdir -p /etc/cloud/ssl/certs
           mkdir -p /etc/cloud/ssl/private

2. Copy all certificates to their shared locations on the control nodes and compute nodes:

           # scp /root/.acme.sh/susedojo.com/susedojo.com.cer \ root@control:/etc/cloud/ssl/certs
           # scp /root/.acme.sh/susedojo.com/ca.cer root@control:/etc/cloud/ssl/certs
           # scp /root/.acme.sh/susedojo.com/fullchain.cer root@control:/etc/cloud/ssl/certs
           # scp /root/.acme.sh/susedojo.com/susedojo.com.key \ root@control:/etc/cloud/ssl/private

1. Set your Certificate File and Key File to the proper location, and set the CA Certificates File to the /etc/ssl/ca-bundle.pem in the distribution. Make sure Generate (self-signed) certificates is false, and Certificate is insecure is false.

   

   Figure 18.1: Database Barclamp #

2. Click Apply. Your changes will apply in a few minutes.

3. Set your Certificate File and Key File to the proper location, and set the CA Certificates File to the /etc/ssl/ca-bundle.pem in the distribution. Make sure Generate (self-signed) certificates is false, and Certificate is insecure is false.

   

   Figure 18.2: RabbitMQ Barclamp #

4. Click Apply. Your changes will apply in a few minutes.

5. Set your Certificate File and Key File to the proper location, and set the CA Certificates File to the /etc/ssl/ca-bundle.pem in the distribution. Make sure Generate (self-signed) certificates is false, and Certificate is insecure is false.

   

   Figure 18.3: Keystone Barclamp #

6. Click Apply. Your changes will apply in a few minutes.

7. Set your Certificate File and Key File to the proper location, and set the CA Certificates File to the /etc/ssl/ca-bundle.pem in the distribution. Make sure Generate (self-signed) certificates is false, and Certificate is insecure is false, and Require Client Certificates is true.

   

   Figure 18.4: Glance Barclamp #

8. Click Apply. Your changes will apply in a few minutes.

9. Set your Certificate File and Key File to the proper location, and set the CA Certificates File to the /etc/ssl/ca-bundle.pem in the distribution. Make sure Generate (self-signed) certificates is false, and Certificate is insecure is false, and Require Client Certificates is false.

   

   Figure 18.5: Cinder Barclamp #

10. Click Apply. Your changes will apply in a few minutes.

11. Set your Certificate File and Key File to the proper location, and set the CA Certificates File to the /etc/ssl/ca-bundle.pem in the distribution. Make sure Generate (self-signed) certificates is false, and Certificate is insecure is false, and Require Client Certificates is false.

    

    Figure 18.6: Neutron Barclamp #

12. Click Apply. Your changes will apply in a few minutes.

13. Set your Certificate File and Key File to the proper location, and set the CA Certificates File to the /etc/ssl/ca-bundle.pem in the distribution. Make sure Generate (self-signed) certificates is false, and Certificate is insecure is false, and Require Client Certificates is false.

    

    Figure 18.7: Nova Barclamp #

14. Click Apply. Your changes will apply in a few minutes.