How to deal with Horizon Workspace 1.5 FQDN and certificates
August 17, 2013 8 Comments
In the past I’ve written about how to install Horizon Workspace 1.0 and one of the tricky parts was about the decision of Workspace FQDN.
In version 1.0 you couldn’t change it afterwards so you had to do it right from the start, in version 1.5 you can change it but it’s still pretty tricky so you should still know in advance how it should look in the end. It’s not mandatory but it would help a lot.
In Horizon Workspace 1.5 during setup you won’t be asked for the FQDN but it will be automatically set as the name you’ve chosen for your gateway-va when you’ve created DNS entries for the VApp.
After deploying and configuring Horizon Workspace just as it used to be, you can go here and change the FQDN and/or certificates:
In this screen you are able to:
- Configure an external load balancer
- Install custom certificates
- Change Horizon Workspace FQDN
- Regenerate self-signed certificates
A lot of people reported errors when trying to change the FQDN, the most common is this:
Invalid IDP host/port
The reason for the above is that during the change of FQDN a check is performed on the SSL certificate for the new hostname to confirm that its common name matches the new FQDN. Here’s what i get in the configurator-va logs when i experience the issue:
ERROR [tomcat-http–29] com.vmware.horizon.configurator.vm.remote.impl.ConnectorRemoteImpl – Error when updating Connector “connector_va” with new IDP Url. Response from server: “Hostname is invalid or not reachable”. Could not connect to the URL. hostname in certificate didn’t match: “old_workspace_fqdn” != “new_workspace_fqdn”
This would mean that if we are just changing the FQDN but hosts remain the same we would have to replace certificates before actually making the change, a lot like during version 1.0 installation, but the same procedure doesn’t seem to help because even if the new certificate gets applied it still exposes the old one at least in one page that gets checked and this generates the error above.
At the end of the day we want to get the job done in the best way possible, so i can share the 2 ways i found to take over this task. The goal i am setting to myself as final result include the following:
- Making sure self-signed certificates are replaced
- Every virtual machine has numbered hostname naming convention based on role to help scaling (eg. gateway01, data01, etc.)
- Horizon Workspace FQDN is set as i wish
- Horizon Workspace FQDN is not the hostname of one of the virtual machine
So here’s my two cents on how to do that.
Method 1
In this method we create DNS records in our internal DNS so that the FQDN is pointing at a load balancer:
192.168.110.20 cofigurator-15.vsphere.lab 192.168.110.21 service-15.vsphere.lab 192.168.110.22 connector-15.vsphere.lab 192.168.110.23 data-15.vsphere.lab 192.168.110.24 gateway-15.vsphere.lab 172.16.110.2 workspace-15.myvirtualife.net
My FQDN is “workspace-15.myvirtualife.net” since this is testing version 1.5.
My load balancer is configured to redirect all requests for “workspace-15.myvirtualife.net” to “192.168.110.24” and i’ve installed a certificate on it with the common name “workspace-15.myvirtualife.net” as it should be. To generate certificates i’ve used my internal Microsoft CA.
Complete deploy and configuration, accepting default for FQDN and certificates; the FQDN now is “gateway-15.vsphere.lab”.
Now log in to “https://gateway-15.vsphere.lab/admin” and reach the screen where you can change the FQDN and configure it as follows:
I pasted the certificate of my internal Microsoft CA since that is what i used to generate the cert for the load balancer.
Clicking save will change FQDN on all virtual machines plus adding my internal Microsoft CA as a trusted CA. This is a nice improvement since in version 1.0 it was a manual process where you had to SSH all VMs one by one… go read previous posts to see how much fun that was. Thank you VMware for this improvement.
In the end it should all look like this:
Now, given that your users can access your load balancer, just connect to “https://workspace-15.myvirtualife.net/admin” and you should be good to go.
If you need users to access from outside the network, like from the internet, just publish the load balancer and create a DNS record with the Workspace FQDN that points to the public IP used to publish the load balancer.
Method 2
In this method we create DNS records so that the FQDN is actually the name of our gateway-va:
192.168.110.25 cofigurator-15-2.vsphere.lab 192.168.110.26 service-15-2.vsphere.lab 192.168.110.27 connector-15-2.vsphere.lab 192.168.110.28 data-15-2.vsphere.lab 192.168.110.29 workspace-15-2.myvirtualife.net
My FQDN is “workspace-15-2.myvirtualife.net” since this is method 2 for version 1.5.
You can proceed with the installation as you did for 1.0 version.
During configuration just accept all default when it comes to FQDN and certificates.
If you haven’t generated certificates for “workspace-15-2.myvirtualife.net” do it now.
Now reach the “FQDN & SSL” section in the configurator-va as we did for method 1 and set it like this:
The certificate you are pasting needs to be a chain of certificates including the CA certificate as well.
As the documentation states, the certificate chain has to look as follows:
-----BEGIN CERTIFICATE----- SSL Cert - Workspace SSL cert -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Intermediate/Issuing CA Cert -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- Root CA Cert -----END CERTIFICATE-----
Clicking save will change FQDN on all virtual machines plus adding my internal Microsoft CA as a trusted CA. I already stated how annoying that was to do this manually so once more thank you VMware.
After a few minutes you should find yourself back at the “FQDN & SSL” screen. Don’t expect any successful confirmation because you won’t get any but if you get no error it’s all good. Close your browser and connect back to your Workspace FQDN and you should see no SSL warning no more.
Now since i don’t want my gateway-va hostname to be the same as the FQDN let’s open the console, login as root and fire up yast to change it:
We also need to create a DNS record that points “gateway-15-2.vsphere.lab” to gateway-va IP address. Make sure the PTR for that IP points to the new record and not to the FQDN record.
Reboot the gateway-va and go back to the “FQDN & SSL”:
Since the gateway-va and the Horizon Workspace FQDN are not the same, the configurator-va assumes there will be a load balancer. You still have DNS pointing the Horizon Workspace FQDN to the gateway-va and your internal users should not have the warning for the self-signed certificate anymore. You can add a reverse proxy/load balancer if you want for outside access. This is a good way if you don’t want multiple gateway-va but you can still add more if you also add a load balancer and point the Workspace FQDN to that.
This should take you where you want to go. Comment section is open if you have doubts about the procedure i described I’ll try to answer fast enough and help if I can.
MyVirtuaLife.Net 
Pingback: How to replace Horizon Workspace 1.0 self-signed certificates with Microsoft CA certificates | MyVirtuaLife.Net
nice stuff, fixed the issue of importing a cert that didnt match the original gateway-va hostname
If any post i write helps even one single person, i’m happy.
You have no idea how long it took me to figure out the best way for me to deal with it, i so much wished i found someone who wrote an article about it when i needed it, so this is why i wrote this one.
Hello,
I’m having the exact same issue. I really need help with changing the FQDN. I’m using nginx as the load balancer and when I try to update the FQDN and upload the rootCA (Comodo), it’s not working with the message “host cannot be reached. ”
Any help will be greatly appreciated
I don’t know a lot about nginx but i know this is what the gatway-va is using too so it might be a problem between the two even if in theory if you configure it right it shoud just work.
I would need a lot more details about your environment to help but in general it usuallty means that weather you can’t resolve the hostname correctly or that your cert doesn’t match that hostname.
Try to check those and read this tutorial together with 1.0 install tutorial and see if you are doing something wrong there.
Hope it helps.
Hi, thank you for your great post!
I’m currently using method 2 right now, and I’m having problems generating certificates for my new FQDN. I installed a Microsoft Windows CA in the vsphere.lab domain, followed the steps in your other article and ended up with the following three items.
key.pem (private key)
horizon.pem (the horizon workspace certificate)
ca.pem (the certification authority certificate)
However, I seem to be missing the Intermediate/Issuing CA Cert. Could you point me in the right direction on what this is?
Thanks in advance.
Hi,
it really depends on how you installed your Microsoft CA environment, you might not even have an intermediate CA.
Just put all certificates in your chain, if you don’t have an intermediate just don’t put it.
Pingback: Horizon Workspace: FQDN and SSL certificates in access from the Internet. | Piszki Lab | EN