Enthusiast
Enthusiast

Error creating admin user – hostname in certificate didn’t match

We have a working installation of Horizon Workspace but installed another one since we want the gateway-va to have a more user friendly name that will be the same as the outside address for when it’s in production.

I noticed that the VM name has to be gateway-va (or at least don’t see how to change it) but the FQDN can be whatever you choose in the setup so I named it horizon.xxxx.com to match what we want to use on the outside. I also have the other VMs with the same xxxx.com but kept the default names.

Everything seems to be fine until I got to the configurator part where it’s doing the database setup (internal for us). When I choose Next after selecting Internal Database it thinks for a while then gives me an error that says “Error creating admin user – hostname in certificate didn’t match: != OR OR”.

Could this have to do with having 2 Horizon vApps running even though they are use different IP addresses and don’t use the same prefix on the host?

0 Kudos
14 Replies
Enthusiast
Enthusiast

On configurator-va, as root
cd /usr/local/horizon/lib/menu/secure
./wizardssl.hzn --makesslcert gateway-va  <FQDN>

./wizardssl.hzn

0 Kudos
Enthusiast
Enthusiast

It says no such file or directory when running the command even though wizardssl.hzn is there under secure. For the gateway-va  <FQDN> part do I want to put the name that I chose during setup for the FQDN I assume?

So the command would look like

./wizardssl.hzn --makesslcert horizon.xxxx.com since I changed the name of the gateway-va during the initial setup.

0 Kudos
Enthusiast
Enthusiast

./wizardssl.hzn --makesslcert gateway-va horizon.xxxx.com


then run ./wizardssl.hzn

0 Kudos
Enthusiast
Enthusiast

I still get the same error when trying to do Step 2a: Database Connection Setup.

wizardssl2.jpg

0 Kudos
Enthusiast
Enthusiast

So let me get this straight.  You currently have a working Workspace install in your environment which is up and running?

And you are trying to add another or did you tear down the other one already?

0 Kudos
Enthusiast
Enthusiast

The other one is still running but has different IPs of course and a different DNS suffix for each installation. I just have the working\original installation up just in case people are still using it. Once I get the new one up and running I will get the data off the old one and then shut it down. We are only using the data sharing feature at the moment.

0 Kudos
Enthusiast
Enthusiast

Do you have the first installation tied to a .local domain as opposed to this new one?  You said the different dns suffix for each installation.  How were you able to  get different dns suffixes for all the vms in the vApp.  Each piece should be named as xxxx-va.whateveryourlocaldomain is no matter if you named the external fqdn a domain.com on the new installation.

0 Kudos
Enthusiast
Enthusiast

The first one is tied to a local\internal domain for all the VMs and the second one was setup using our external domain for all the VMs. I just setup the VMs IP addresses (internal) in DNS in our external zone. Then we will use a public DNS name which will be the same FQDN as the gateway-va VM for external access.

So yes all the VMs have the same domain name for this installation.

0 Kudos
Enthusiast
Enthusiast

Without knowing your exact DNS set up, it seems to me that the setup wizard is still trying to tie back to your original installation of Workspace.  If the only thing you have changed is the fqdn of your external and all of your other xxxx-va machines all end in your local.domain then that is for sure what is happening.  I also am assuming you have all of your forward and reverse lookups set up in DNS.  Workspace is extremely picky about DNS.

0 Kudos
Enthusiast
Enthusiast

All the VMs for the new install have a different FQDN than the other install and all have reverse lookups configured.

I think I may try to shut off the other one and see what happens or I may just delete it since its not being widely used at the moment.

0 Kudos
Enthusiast
Enthusiast

I shut down the first Horizon instance and rebooted the new vApp. When I run the database setup this time I get a different message. It says:

Error creating admin user.

No route to host

I found another post on it but with no real solution.

Database Connection Setup - Error creating admin user. No Route to host

0 Kudos
Enthusiast
Enthusiast

That says to me that it is still looking for your old Workspace vApp because you shut it down and it says "no route to host".

0 Kudos
Enthusiast
Enthusiast

I removed and then redeployed the vApp with the old one still shut down and got the same error. Do you think if I removed the DNS records for the original installation that would do the trick?

0 Kudos
Enthusiast
Enthusiast

I even tried shutting off the working Horizon and installing a new one with the same IP addresses and DNS names so it would match the working one. The only thing I changed is the FQDN to a different one during setup besides gateway-va.xxxx.com and still get the same error.

0 Kudos