VMware Horizon Community
VMMikeC
Enthusiast
Enthusiast
Jump to solution

View External URLs and Certs

Hi,

Just looking for some clarification on some things. This is not how my environment is setup today, but this is how I am planning to make it

View Connection Servers:

viewconn1.mydomain.com - 192.168.200.10

viewconn2.mydomain.com (replica) - 192.168.200.20

View Security Servers:

viewsec1.mydomain.com (paired with viewconn1) - 192.168.100.10

viewsec2.mydomain.com (paired with viewconn2) - 192.168.100.20

All of these servers would have IP addresses in the 192.168.x.x range. All servers in my DMZ servers are also in this range and I use a firewall to handle any type of NAT.

I plan to load balance all of these servers For my internal users, I'd like all view clients/zero clients to connect via the address  view.mydomain.com . I'd really prefer that my internal and external(internet) users connect via view.mydomain.com

When it comes to certificates, what's the best way to handle this. I'll need a 3rd party CA for my security servers, that way my users connecting with their personal computers do not get any certificate warnings. Can I just buy a SSL cert for view.mydomain.com and install it on all 4 servers?

As for the PCoIP Security Gateway, can the external IPs be the internal dmz IP such as 192.168.100.10, since I'm having my firewall NAT, or does it need to be the public address provided by my ISP?

I've gone through the documentation already but it's still not 100% clear to me.

thanks,

Mike

Reply
0 Kudos
1 Solution

Accepted Solutions
schmidtl
Enthusiast
Enthusiast
Jump to solution

Depending on which external CA you choose, you have 3 Options. (Not all are Supported by every CA, the rep. of your CA can help).

  1. Get a wildcart certificate, *.mycompany.com. So you can use this on all View Components and you're done. Two issues may arrise:
    1. If you adress your Servers via IP or some Name like 'view.local.domain' -> cert warning
    2. Some clients may behave in a strange way or generate warnings when they see wildcard certificates. In a View Environment i never had such issues (I'm using wildcard Certs issued by Rapidssl, and Wiew Software Clients, PCoIP Hardware Clients and Browsers in their latest Version.
  2. Some CA's offer the ability to add 'alternate Names' to your cert, so you get 1 (!) Certificate that fits for 'view.mycorp.com' as well as for lets say 'View-01.mycorp.com and 'view-2.domain.local', sometimes even IP Adresses are allowed. The good thing: you dont't get a certificate Warning, even if you bypass the loadbalancer (view.mycorp.com) and talk directly to a connection Server (view-01.mycorp.com)
    1. Note that this should work in theory, I have done this, but never with View. Not sure if the View Server likes that.
  3. As discussed in earlier Threads, you can get a certificate 'view.mycorp.com' and slam it to every server in the Party. I whould avoid that, because:
    1. As soon as you contact a Connection Server directly, you get a cert warning, because the name does not match the cert. This is not so dramatic for users, but more so for the VMWare components that talko to each other (may it be a Orchestrator, vCops or whatever)

As for your PCoIP Gateway Configuration: you have to configure the public IP (that is known to the World) in the server settings, regardless if the server has that IP or is behind a NAT device that forwards the requests.

View solution in original post

Reply
0 Kudos
7 Replies
VMMikeC
Enthusiast
Enthusiast
Jump to solution

The more I think about this, the more I realize I'm confusing myself :smileyconfused:. I was thinking for the connection servers, I can use my Internal CA and also import a 3rd party certificate with the name of view.mydomain.com. However, this will not work, because only 1 certificate can have the vdm friendly name. I don't know what I was thinking

It seems like a Wildcard or UC certificate would be necessary for what I'm trying to accomplish, which is fine. I'm still curious to how everyone else is providing a single URL for both internal and external (security server) users.

Reply
0 Kudos
mittim12
Immortal
Immortal
Jump to solution

I use an internal cert for our inside connection brokers and a third part for the external, while utilizing a singole URL.    The internal network points to the internal connection brokers via DNS and then the external clients are pointed to the external servers via DNS.   The only time I've ever heard problems with this is when a user brings in their own device such as an IPAD and somehow ends up on the internal network.

VMMikeC
Enthusiast
Enthusiast
Jump to solution

are you using a UC(SAN) cert internal? If you have a single url, such as view.yourdomain.com, and you go to the admin page of one of the connection brokers, you are going to get a cert warning, because the name doesnt match what's on the cert. Unless you go to https://view.yourdomain.com/admin instead of https://viewconn1.yourdomain.com/admin

I may be overcomplicating this lol

I actually have a lot of iPAD users that bring their devices into the office.

Reply
0 Kudos
schmidtl
Enthusiast
Enthusiast
Jump to solution

Depending on which external CA you choose, you have 3 Options. (Not all are Supported by every CA, the rep. of your CA can help).

  1. Get a wildcart certificate, *.mycompany.com. So you can use this on all View Components and you're done. Two issues may arrise:
    1. If you adress your Servers via IP or some Name like 'view.local.domain' -> cert warning
    2. Some clients may behave in a strange way or generate warnings when they see wildcard certificates. In a View Environment i never had such issues (I'm using wildcard Certs issued by Rapidssl, and Wiew Software Clients, PCoIP Hardware Clients and Browsers in their latest Version.
  2. Some CA's offer the ability to add 'alternate Names' to your cert, so you get 1 (!) Certificate that fits for 'view.mycorp.com' as well as for lets say 'View-01.mycorp.com and 'view-2.domain.local', sometimes even IP Adresses are allowed. The good thing: you dont't get a certificate Warning, even if you bypass the loadbalancer (view.mycorp.com) and talk directly to a connection Server (view-01.mycorp.com)
    1. Note that this should work in theory, I have done this, but never with View. Not sure if the View Server likes that.
  3. As discussed in earlier Threads, you can get a certificate 'view.mycorp.com' and slam it to every server in the Party. I whould avoid that, because:
    1. As soon as you contact a Connection Server directly, you get a cert warning, because the name does not match the cert. This is not so dramatic for users, but more so for the VMWare components that talko to each other (may it be a Orchestrator, vCops or whatever)

As for your PCoIP Gateway Configuration: you have to configure the public IP (that is known to the World) in the server settings, regardless if the server has that IP or is behind a NAT device that forwards the requests.

Reply
0 Kudos
VMMikeC
Enthusiast
Enthusiast
Jump to solution

Thanks.

I was leaning towards wildcard cert but I'm not sure if my company will allow it.

For my home lab, I ordered a UCC (SAN) cert (your option #2) from GoDaddy to test it out. I'm use to these certs from Exchange Server. GoDaddy UCC cert is $89 a year, but their wildcard cert is 199, so I opted the UCC for my lab lol

In your option #2, you mention "The good thing: you dont't get a certificate Warning, even if you bypass the loadbalancer (view.mycorp.com) and talk directly to a connection Server (view-01.mycorp.com)"  <!!---- I would not have this problem with a wildcard cert either, even if passing through a load balancer, correct?

#3 I would avoid for the reasons you mentioned.

Thanks for the info on the Security Server, I thought that was the case, but I was not sure. I'm going to have a load balancer for security servers too. They will have the same public IP

Thanks!

Reply
0 Kudos
mittim12
Immortal
Immortal
Jump to solution

Mike,  I saw where schmidtl has already answered your questions but I did want to let you know that we do use the SAN option on our internal certs which include the loadbalanced url, the fqdn of the CB, and the shortname of the CB.   

VMMikeC
Enthusiast
Enthusiast
Jump to solution

Thanks Tim. That makes perfect sense. That's also what I was trying to make sure of. If I use internal certs for my CB, but a 3rd party for Security Server, then my external clients won't need any certificate installed manually. I know companies that do that, I just find it annoying. I don't want to have to send my users an attachment with a cert, just so they can use their home pc.

Reply
0 Kudos