Introduction
This is a document for replacing realhostip.com to your custom domain. IMPORTANT: You have to do this. The realhostip.com DNS resolver is being retired soon.
*********** See this announcement : http://s.apache.org/jwe ***************************
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)
NOTE - In case you don't want SSL communication for the impacted functionalities you may disable SSL completely by setting secstorage.encrypt.copy to "false", and changing consoleproxy.url.domain to empty.
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
- A publicly resolvable DNS server for your domain
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
- A signed wildcard certificate for your domain. This certificate may be obtained from any CA like VeriSign etc. You will need the following handy
- Public certificate of root CA in PEM format
- Public certificate(s) of intermediate CA(s) (if any) in PEM format
- Wildcard domain certificate in PEM format
- Private key in PKCS8 format (Note - steps are documented in Admin Guide section "Changing the Console Proxy SSL Certificate and Domain")
Installation Procedure
- 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 false. If not true, change it to true to enable SSL. You may choose not to use SSL for SSVM)
- Change secstorage.ssl.cert.domain = *.yourdomain.com. Eg - *.xyz.com. NOTE - Remember to put the '*'
- Change consoleproxy.url.domain = *.yourdomain.com. Eg - *.xyz.com (By default, this is empty. You may keep it empty and choose not to use SSL for CPVM). NOTE - Remember to put the '*'
- Follow the "Uploading Custom Certificates" to replace realhostip with your OWN domain name. This should be just xyz.com without '*'
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.
|
- Understanding parameters:
- Make sure the certificates are URL encoded. One way is to use Google chrome - Advanced Rest Client to url encode your certificate (basically it converts the newline into %0A so the certificate becomes 1 line rather than multiple lines ).
- Make sure the certificates are in PEM format.
- API invocation has to be in order ie first the root certificate with id=1 then zero or more intermediate certificates with id =2, 3, 4 etc.
- There is no convention for the name parameter but it would help to name the root certificate as "root", intermediate certificates as "intermediate1", "intermediate2" etc. NOTE - Keep the names always unique.
- domainsuffix should be same as the global config secstorage.ssl.cert.domain/consoleproxy.url.domain = yourdomain.com and for all the API invocations below.
- Uploading root certificate API call. This is a mandatory step.
- Uploading Intermediate certificate API call. This is an optional step in case you have intermediate certificates.
- Go to UI --> Infastructure –> Upload SSL certificate to upload the server certificate, private key and the same domain name and press OK. You will get the "Update SSL certificate succeeded" as a response once its successfully uploaded. (Note - this should not be URL encoded certificate and key)
- SSVM and CPVM get rebooted to get programmed with the certificates.
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
- Detailed information can be found in the wiki
- CPVM acts as a server only and uses Java HTTP server
- 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.
Troubleshooting
Detailed information can be found on wiki
FAQ
How to generate my custom root CA and certificate?
In essence, the process is to :
- Create your own root CA
- Create your own intermediate CA, who is signed by the root CA (optional step)
- Create your domain specific certificate request, and sign it using the intermediate CA (or root CA)
- 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.
Getting a certificate from a reputed Certificate Authority say Verisign
In essence the steps are as follows. Use the openssl tool. Exact steps documented in Admin guide
• Generate the private key for your certificate in PKCS#8 format.
• Generate a certificate signing request (CSR)
• Head to your favorite trusted Certificate Authority, purchase an SSL certificate, and submit the CSR. You should receive a valid certificate in return.