Installing SSL Certificates on View Connection Brokers
When working with VMware View (or any VDI solution for that matter), you’ll eventually have to deal with certificates. Hopefully your organization has a skilled web or security team who can help you install the certificate onto the Connection Servers and Security Servers… but I find that that’s not usually the case. Usually, someone either just downloads the certificate from GoDaddy (or whatever authority they use) or gives me the credentials so that I can download it myself.
The problem is, what you download from GoDaddy isn’t going to work, at least not by itself. There basically two parts of a certificate: the public key and the private key. When you go to GoDaddy and launch their interface and download your certificate, you’re downloading the public key (and any intermediate certificates that are required to establish a chain of trust). In order to install and use that certificate, you’ll need to provide the corresponding private key (which was used in the initial certificate signing request). GoDaddy assumes that you still have your private key stored somewhere safe. You do, don’t you?
Well, if needed, you can re-key your certificate… but if you do that, you should probably update any systems that use that certificate to use the new one. And hold onto your private key this time!
Often, that doesn’t end up being necessary. Why is that? Wildcard certificates! When you’re requesting a certificate, you can certify a specific server (myserver.mydomain.com) or you can just certify everything under a specific domain (*.mydomain.com). The latter is a wildcard cert. Wildcard certs are less secure, but they’re a whole heckuva lot easier, as they can certify your web server (www.mydomain.com) your mail server (mail.mydomain.com) your vdi solution (vdi.mydomain.com)… they can apply to anything that lives under your domain – hence the wildcard.
Many of my customers own and use wildcard certificates. Even if they can’t find their private key (a whole new layer of security through obscurity!), they usually know of several servers in their environment that are using that certificate. If you have sufficient permissions, you can just export the certificate from one of those servers. To get to the point where those instructions start, just do the following:
1) Run mmc.exe
2) Go to File -> Add/Remove Snap-ins…
3) Double click on Certificates
4) Select the Computer Account option and Finish the wizard
5) Press OK to get back to the management console, which now has the certificate management panel in place
The certificate installation instructions from VMware assume that you’ve got a PKCS #12 file (it’ll have a .PFX extension), so make sure that you use that format during the export. In step 5 of the export process, those instructions tell you to select “No, do not export the private key”… the whole point of this exercise is to get your private key, so you should instead select “Yes, export the private key”. It’ll prompt you to create a password.
What if “Yes, export the private key” isn’t available? That probably means that, when the certificate was installed on that server, the “mark this key as exportable” option was not set. In that case, try another one of your servers… and failing that, you’re probably back to square one, which means redoubling your effort to find your private key and then, as a worst case scenario, you can re-key your cert.
So, now you’ve got a .pfx file with a password that you created. Simply copy that onto your View Connection servers and Security Servers, then follow VMware’s certificate installation instructions. That should get you going.
One last thing to bear in mind – in order to have a trusted SSL connection, the server must have a valid certificate installed (along with any needed intermediate authorities, depending on the certificate) for the server name that the client is requesting. So, if you install your *.mydomain.com wildcard cert but have your customers accessing the server through your internal namespace at vdi.mydomain.local… well, that’s not going to work. The server does not have a certificate for the mydomain.local domain. Instead, you might have to get a little tricky with DNS in order to make those internal servers accessible from the seemingly public namespace of vdi.mydomain.com.
The problem is, what you download from GoDaddy isn’t going to work, at least not by itself. There basically two parts of a certificate: the public key and the private key. When you go to GoDaddy and launch their interface and download your certificate, you’re downloading the public key (and any intermediate certificates that are required to establish a chain of trust). In order to install and use that certificate, you’ll need to provide the corresponding private key (which was used in the initial certificate signing request). GoDaddy assumes that you still have your private key stored somewhere safe. You do, don’t you?
Well, if needed, you can re-key your certificate… but if you do that, you should probably update any systems that use that certificate to use the new one. And hold onto your private key this time!
Often, that doesn’t end up being necessary. Why is that? Wildcard certificates! When you’re requesting a certificate, you can certify a specific server (myserver.mydomain.com) or you can just certify everything under a specific domain (*.mydomain.com). The latter is a wildcard cert. Wildcard certs are less secure, but they’re a whole heckuva lot easier, as they can certify your web server (www.mydomain.com) your mail server (mail.mydomain.com) your vdi solution (vdi.mydomain.com)… they can apply to anything that lives under your domain – hence the wildcard.
Many of my customers own and use wildcard certificates. Even if they can’t find their private key (a whole new layer of security through obscurity!), they usually know of several servers in their environment that are using that certificate. If you have sufficient permissions, you can just export the certificate from one of those servers. To get to the point where those instructions start, just do the following:
1) Run mmc.exe
2) Go to File -> Add/Remove Snap-ins…
3) Double click on Certificates
4) Select the Computer Account option and Finish the wizard
5) Press OK to get back to the management console, which now has the certificate management panel in place
The certificate installation instructions from VMware assume that you’ve got a PKCS #12 file (it’ll have a .PFX extension), so make sure that you use that format during the export. In step 5 of the export process, those instructions tell you to select “No, do not export the private key”… the whole point of this exercise is to get your private key, so you should instead select “Yes, export the private key”. It’ll prompt you to create a password.
What if “Yes, export the private key” isn’t available? That probably means that, when the certificate was installed on that server, the “mark this key as exportable” option was not set. In that case, try another one of your servers… and failing that, you’re probably back to square one, which means redoubling your effort to find your private key and then, as a worst case scenario, you can re-key your cert.
So, now you’ve got a .pfx file with a password that you created. Simply copy that onto your View Connection servers and Security Servers, then follow VMware’s certificate installation instructions. That should get you going.
One last thing to bear in mind – in order to have a trusted SSL connection, the server must have a valid certificate installed (along with any needed intermediate authorities, depending on the certificate) for the server name that the client is requesting. So, if you install your *.mydomain.com wildcard cert but have your customers accessing the server through your internal namespace at vdi.mydomain.local… well, that’s not going to work. The server does not have a certificate for the mydomain.local domain. Instead, you might have to get a little tricky with DNS in order to make those internal servers accessible from the seemingly public namespace of vdi.mydomain.com.
Comments
Post a Comment
Sorry guys, I've been getting a lot of spam recently, so I've had to turn on comment moderation. I'll do my best to moderate them swiftly after they're submitted,