The realhostip.com service will be switched off on the 1st October 2014. Paul Angus looks at what it did, what effect the retirement will have and what you need to do to carry on working if you’re affected.
What is realhostip.com?
When you connect to the Console Proxy system VM or download a disk or ISO from the secondary storage VM you connect over a secure (https) connection. This is particularly important when you put in your password. In order for this to be secure you need to connect to a URL which has a FQDN and have a certificate to go with it.
The realhostip.com domain and DNS service was created to give an out of the box solution to this problem. By using the realhostip.com domain and a clever bit of magic, with hostnames and a dynamic DNS script, the data transmitted is encrypted.
The problem is that anyone can use this system, which means that just because a VM has a certificate that doesn’t mean you can trust it. Also, someone could extract the certificate from a CloudStack environment and then use that to decrypt others’ traffic. Its very unlikely but technically possible.
So that’s why the use of a publicly available certificate is being retired.
Who will this affect?
For clean installs of CloudStack 4.3 and later do not use realhostip and instead use HTTP (unencrypted) communications to the public interfaces – so you have to arrange the certificate yourself from the get go. So if you’re using 4.3 or later then the switching off of the service won’t affect you. However if you are using 4.3 or later and haven’t installed a certificate then you should install one for the security of your users. Now.
For users of CloudStack 4.3 environments which have been upgraded from earlier versions, you have the additional option of switching HTTPS off for the console proxy and secondary storage but you do so at your own risk and I can’t recommend it for anything which is public facing or not in the most isolated of test environments.
So for versions of CloudStack pre v4.3 or environments which have been upgraded from a previous version, admins need to replace realhostip.com with their own domain and certificate otherwise the console proxy service and downloading from the secondary storage VM will stop working on 1st October 2014.
What to do to replace realhostip.com
There a number of sources which explain how to use your own domain for secure console proxy and secondary storage, so I’ll point you to the various sources and add some extra depth to the references.
The first thing you need is a domain to use to replace realhostip.com. Generally people use a subdomain of their corporate domain (such as console.supercloud.com) so that it can be managed separately from the parent domain. You don’t have to use a subdomain by any means, but I’m going to assume you have for the purposes of this blog. Then you need a DNS server or two which will act as the resolvers for your subdomain. The resolvers need to resolve all addresses in your public ranges. Part of the cleverness of the realhostip solution is in the way CloudStack creates FQDNs for the secondary storage VMs and console proxy VMs which are easy to work with. For example, for the IP address 1.2.3.4 CloudStack would create an FQDN of 1-2-3-4.realhostip.com and for 4.3.2.1 it would be 4-3-2-1.realhostip.com. It makes creating the zone files easy and even makes it possible to create a DNS server that will resolve anything that’s thrown at it in this format. Indeed that’s what the realhostip DNS servers did (source code is here https://github.com/ke4qqq/RHIP). You’re going to replace that with 1-2-3-4.console.supercloud.com
Things get trickier if your DNS is hosted by a 3rd party and you have a lot of public IPs which the system VMs could use. Creating the entries for a zone file in a spreadsheet is easy, but if you had to fill in a web form for your ISP for each IP address it’s going to be a long, boring and error-prone task, so you’d probably look at creating your own DNS servers for your subdomain or trying to get your ISP to do the heavy lifting.
So we have a domain to use and some DNS servers to resolve it with, now we need a certificate to secure things with. You’ll need a wildcard certificate for the subdomain as you need it to work for multiple hosts *. console.supercloud.com. A quick search for ‘wildcard certificate’ will bring back a bucket load of vendors of wildcard certificates. I’ve found that large enterprises will likely have a system in place for obtaining certificates, so a call to corporate IT may save your credit card and a load of time.
To get a certificate you need to generate a private key and then a certificate signing request (CSR) which is used by the certificate provider to generate a certificate based on the private key. A procedure for doing this is documented in the CloudStack documentation – you need openssl installed which is easy enough, but your CloudStack management server(s) will have it installed so you can always do it from there. http://docs.cloudstack.apache.org/en/latest/administration_guide.html#changing-the-console-proxy-ssl-certificate-and-domain
You can now go to the certificate vendor and request your wildcard certificate.
Once you get your wildcard certificate you’ll need the public certificate of root certificate authority (CA) and the public certificate(s) of intermediate CA(s) (if any). They may be sent with your wildcard certificate or you may need to go to the website of your certificate provider to download them. You need the whole chain so that a client can see that the certificate is bona fide.
Now is the most complicated bit – getting the everything in the correct format. Why this process always ends up being such a pain is beyond me, but anyone who’s tried to add a certificate to a NetScaler, IIS, RDS or CloudStack will testify that it’s rarely simple – the certificate and/or private key you have never seem to be in quite the right format or you’re missing an intermediate certificate, so stick with it – you’re not alone.
The openssl tool is pretty good for converting between formats.
So in all you should have the following:
- 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
- It should sound obvious but you must make sure that from the public internet your public IP addresses get resolved i.e. 1-2-3-4. console.supercloud.com -> 1.2.3.4 before you make the switchover
Now that you’re ready to make the change you’ll need to do the following steps
- Update the CloudStack settings to use your new certificate
- Upload the new certificate to the management server
- Reboot the system VMs to use the new certificates
- Verify the new certificate is working
These steps are well documented with additional help also on the CloudStack Wiki
Procedure to Replace realhostip.com with Your Own Domain Name
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Procedure+to+Replace+realhostip.com+with+Your+Own+Domain+Name
Things you should consider while changing the Realhost domain to custom Domain.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=43188254
Troubleshooting – uploading custom domain certificate instead of using realhostip.com
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Troubleshooting+-+uploading+custom+domain+certificate+instead+of+using+realhostip.com
An extra pointer from our experience is that the system VMs should be stopped, then started, both from CloudStack management server, otherwise the new certificate will not be applied.
Chip Childers wrote this article a while back and the system for importing certificates has been improved since them but it may provide additional help
http://www.chipchilders.com/blog/2013/1/2/undocumented-feature-using-certificate-chains-in-cloudstack.html
Summary
In this article we looked at what the realhostip.com service does and how its retirement will effect CloudStack/CloudPlatform clouds. We also gave information on the steps required to replace the realhostip.com service if you need to secure your cloud.
About the Author
Paul Angus is a Cloud Architect at ShapeBlue, The Cloud Specialists. He has designed and implemented numerous CloudStack environments for customers across 4 continents, based on Apache Cloudstack ,Citrix Cloudplatform and Citrix Cloudportal.
When not building Clouds, Paul likes to create scripts that build clouds……..and he very occasionally can be seen trying to hit a golf ball.
Steve Roles is ShapeBlue’s COO and is responsible for all day to day administrative and operational functions of the business, including the consulting, programme management, and support functions. Involved with CloudStack since 2012, Steve has led several large customer engagements including a number of major public and private cloud deployments; co-ordinated and developed worldwide teams and helped implement and deliver an enterprise grade support product.
Away from work, Steve is a music lover and semi-professional musician. Although he doesn’t speak at many technology conferences, he can sometimes be heard providing the evening entertainment.
