You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

 

Introduction

 This is a document for replacing realhostip.com to your custom domain.

Functionality Impacted

  • Console view of virtual machines available through Console Proxy virtual machine (CPVM)
  • Copy Template available through Secondary Storage virtual machine (SSVM)
  • Download Template/ISO/Volume (SSVM)

Known Issues

Issue Description Notes
1.Self signed certificates are not supported. 
2.Once the certificate for custom domain is uploaded, it cant be reverted
back to using realhostip.com		Refer FAQ section for creating custom root CA and certificates

Prerequisites

  1. A publicly resolvable DNS server for your domain

    1. To replace realhostip.com with your own domain name first you need to setup your own domain in your DNS server. For this example we will assume you are using BIND. But any DNS server will work. In this example we will use yourhostip.com as the new domain name. The way realhostip.com is utilized is for every public IP that is entered into CloudStack it converts that name into a DNS name such as 77.88.99.11 maps to 77-88-99-11.realhostip.com. This is needed for SSL, when the browser connects to this name it matches the wildcard cert *.realhostip.com. So for your environment you need to mimic this setup.

      1) Set up your zone (if it is not already) in your DNS server. In BIND 9 it would look something like this:

      zone "yourhostip.com" IN { 
            type master; 
            file "yourhostip.com.zone"; 
            allow-update { none; }; 
      };

      2) Now you need to populate an A record for every public IP you have entered into CloudStack, that the console proxy could allocate. So lets say you have a range such as 55.66.77.100 to 55.66.77.200. Then in your zone file, you need something like this:

      55-66-77-100      IN      A      55.66.77.100 
      55-66-77-101      IN      A      55.66.77.101 
      55-66-77-102      IN      A      55.66.77.102 
      55-66-77-103      IN      A      55.66.77.103 

      etc.. 

      55-66-77-200      IN      A      55.66.77.200

  2. A signed wildcard certificate for your domain. This certificate may be obtained from any CA like VeriSign etc. You will need the following handy
    1. Public certificate of root CA in PEM format
    2. Public certificate(s) of intermediate CA(s) (if any) in PEM format
    3. Wildcard domain certificate in PEM format
    4. Private key in PKCS8 format (Note - steps are documented in Admin Guide section "Changing the Console Proxy SSL Certificate and Domain")

Installation Procedure

    1. Backup existing systemvm.iso (copy systemvm.iso under /usr/share/cloudstack-common/vms to a temporary location)
    2. Upgrade to the Patch build by following Patch install instructions included in the Release Notes or Patch Tar file. 

    3. Once MS and Agents are  upgraded successfully. Change the following global configuration parameters and restart the Management Server. .   
      Global settings

      • Change secstorage.encrypt.copy = true (By default, this value set to  true. If not true, change it to true)
      • Change secstorage.ssl.cert.domain = *.yourdomain.com. Eg - *.xyz.com
      • Change consoleproxy.url.domain = *.yourdomain.com. Eg - *.xyz.com
    4. Follow the "Uploading Custom Certificates" to replace realhostip with your OWN domain name.

Uploading Custom Certificates

Note:  

  • For Uploading Customer Certificates, please ignore the step for uploading the "intermediate certificate".
  • For Uploading Custom Chained Certificates, uploading intermediate certificate is required.
  • Use the uploadCustomCertificate API to upload root and intermediate certificate. Server certificate and private key will be uploaded through the UI.

 

Verification Procedure

  • CPVM - Check console view of user VMs and it should work. They should show the embedded iframe's source URL with HTTP  / HTTPS protocol as configured
  • SSVM -
    • CopyTemplate - Try copying  a template from one zone to the other see whether it works.
    • Download template/volume/iso - The download URL should show the URL with HTTP / HTTPS protocol as configured, and you should be able to download the entity.

Implementation Details

  • CPVM acts as a server only and uses Java HTTP server. Hence, it needs a server Java keystore. This is a dynamic in-memory keystore
  • SSVM acts as a server for download template/volume/iso operations and during copyTemplate if it is in the source zone. It uses a Apache webserver when acting as server.
  • SSVM acts as a client during copyTemplate operation if it is in the destination zone. SSVM uses a Java client when acting as client. It uses "realhostip.keystore" file to store entries. This is different from the place where Java stores the Well-Known CA certificate files by default.

TroubleShooting

  1. Download urls point to the old domain.
    1. Reduce the expiration duration of the urls by changing global config extract.url.expiration.interval 
    2. And change the frequency for cleanup thread through extract.url.cleanup.interval restart MS. 
    3. Wait for the cleanup thread duration and try downloading again. See whether the url is deleted.
  2. CopyTemplate giving the exception - PKIX certification error
    1. Via browser or any client, check whether Apache Webserver for SSVM is sending the entire chain
    2. Check whether the realhostip.keystore (Java keystore) on SSVM has the root CA certificate : keytool -list -keystore realhostip.keystore -storepass vmops.com
  3. Download urls are not working. 
    1. Via browser or any client, check whether Apache Webserver for SSVM is sending the entire chain
  4. I changed CPVM to work on HTTPS from HTTP, or vice-versa. It does not change.
    1. You may need to destroy and recreate your CPVM when switching between HTTP and HTTPS protocols
  5. Certificate encoding - 
    1. Make sure you have correctly url encoded the certificates. To do this you can check cloud database and check the entries in keystore table and match them with the original certificates you had.
  6. Uploaded wrong certificate -
    1. In case you uploaded wrong certificates for root/intermediate, you can undo that by calling the api with same name and domainsuffix. In case you uploaded wrong server certificate upload the right one through the UI keeping the same domain suffix.
  7. Any other issues with ssvm -  
    1. Check logs - Check MS logs (/var/log/cloudstack/management ) and ssvm logs (under /var/log/cloud/) to see if you can find any exceptions in programming the certificate.
    2. Destroy ssvm - If nothing is apparent from the logs try destroying ssvm as one of the last resorts. Try this in one of the zones and see if the new ssvm which comes up solves the issues.
  8. I have already uploaded certificate and chain in a prior CCP version. Am I all good?
    1. Unfortunately, no. You will need to re-upload the whole chain using the same API parameters (name, id etc.)

 FAQ

How to generate my custom root CA and certificate?

In essence, the process is to :

  1. Create your own root CA
  2. Create your own intermediate CA, who is signed by the root CA
  3. Create your domain specific certificate request, and sign it using the intermediate CA
  4. Optionally, you will need to add the root CA and intermediate CA in your browser. NOTE that if you created the above using openssl on your machine, they would exist in the OS as well. Hence, a good way to test it is to create the above on a different machine.

For step 1 : https://jamielinux.com/articles/2013/08/act-as-your-own-certificate-authority/

For step 2: https://jamielinux.com/articles/2013/08/create-an-intermediate-certificate-authority/   (BEWARE of a typo in the blog. Refer to the comments section below it)

For step 3: https://jamielinux.com/articles/2013/08/create-and-sign-ssl-certificates-certificate-authority/

For step 4 : Follow your browser / OS specific steps.

  • No labels