Retirement of the Service

The 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

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 domain and DNS service was created to give an out of the box solution to this problem. By using the 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 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

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 Generally people use a subdomain of their corporate domain (such as 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 CloudStack would create an FQDN of and for it would be  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 You’re going to replace that with

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 *. 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.

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:

  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
  5. 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. -> before you make the switchover

Now that you’re ready to make the change you’ll need to do the following steps

  1. Update the CloudStack settings to use your new certificate
  2. Upload the new certificate to the management server
  3. Reboot the system VMs to use the new certificates
  4. Verify the new certificate is working

These steps are well documented with additional help also on the CloudStack Wiki

Procedure to Replace with Your Own Domain Name

Things you should consider while changing the Realhost domain to custom Domain.

Troubleshooting – uploading custom domain certificate instead of using

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


In this article we looked at what the service does and how its retirement will effect CloudStack/CloudPlatform clouds. We also gave information on the steps required to replace the 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.


Related Posts:

Explore the new release and discover Apache CloudStack 4.19 as a full-featured VMware alternative.