vCenter 5.0 & View 5.1 Certificate extravaganza - the OpenSSL way

With the release of View 5.1, VMware got strict on forcing people to be more secure. When installing 5.1, you have to make the view server fully trust in vCenter's own certificate, let it be a self signed or a real one. Now, getting a real certificate shouldn't be much trouble, or, if you are (or have) a demanding AD administrator, you should already have an own root certificate pushed by domain policies. In this case, you can quit reading this article.

If you don't have one, you could still make View to believe in vCenter's own certificate, accepting it's thumbprint.

For a more demanding solution, you could generate a root certificate (own CA), distribute it with an AD policy and chain vCenter's and View's certificates after it. That's more serious business.

We'll do this with OpenSSL now, of course MS CA services could be used as well.

1. First, download OpenSSL (apt-get or yum it, or here it is for windows).
2. Generate a new key file, this will be used everywhere: openssl genrsa -out rui.key 1024 - we don't encrypt it on purpose.
3. Generate a new root certificate (CA): openssl req -new -x509 -extensions v3_ca -key rui.key -out myroot.crt -days 3650 -config openssl.cnf



How do you make these things larger?

4. Bind the generated root certificate (myroot.crt in the above example) to a Domain Policy. Put it in the  Trusted Root Certification Authorities container, to have it pushed to all domain member computers (see this MS TechNet article, this is called gpmc.msc). Use gpupdate after that for a policy refresh on Windows machines (even on the DC!). This makes our root CA to be trusted on all domain computers. You can use certmgr.msc on domain members to check if the push was successful.

After this step, you shall have a trusted, domain wide root CA for yourself. Now we should start making special certificates for vCenter, View & any other host that needs one. For vCenter (on Windows platform):

1. Generate a new certificate request (there is a whole lot of material about vCenter & certificates on the web, see this kb, or this, even this excellent blog post collection): openssl req -new -key rui.key -out rui.csr -config openssl.cnf - Remember, Common Name wants to have the FQDN of the machine the certificate will be used on (i.e. vcenter1.yourdomain.com).
2. (Optional) If you want to make it really choosy, you can create a new file (ext.txt) that tells OpenSSL,that this key will only be used for Server Authentication, has a CRL and can serve multiple domain names. The file shall include these lines:
   extendedKeyUsage=serverAuth - limit cert usage
   crlDistributionPoints=URI:<http://someserver/mycrl> - link to CRL
   subjectAltName=DNS:<FQDN1>,DNS:<FQDN2>,DNS:<etc> - aliases
   Please note that, that I did not create a CRL file, so if you want to use one, you'll have to dig yourself into the <openssl ca> commands.
3. Sign the request with the Root CA: openssl x509 -req -in rui.csr -CA myroot.crt -CAkey rui.key -CAcreateserial -out rui.crt -days 3650 <-extfile ext.txt> - The last parameter is only required if step 2 was done.
4. Export the signed vCenter certificate into PKCS12: openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx - testpassword must be used, if you don't want to fall into the vpxd -p trap.
5. Copy over the newly generated files rui.key, rui.crt & rui.pfx onto your vCenter's C:\ProgramData\VMware\VMware VirtualCenter\SSL directory. Back up the 3 files there before overwriting.
6. On your vCenter, navigate to http://localhost/mob/?moid=vpxd-securitymanager&vmodl=1, login with a vC administrator, click reloadSslCertificate then Invoke Method. If you see Result: void, then you're done! Based on VMware KB #2009857.

Congratulations! You have a distributed CA and a vCenter that's using the cert chain.

As stated in VMware View 5.1 Installation guide on page 81, View will always try to check for revoked certs, and automatically won't trust any cert, that does not have a CRL linked or it's revocation URL can not be reached. To circumvent the extreme paranoid behaviour, there is a registry switch to turn this off (if you did not take the optional step, you'll need this).

Fire regedit on the View server, then create a string named "CertificateRevocationCheckType" under "HKLM\Software\VMware, Inc.\VMware VDM\Security" and set it's value to 1.

If you add your vCenter now, it's certificate shall be accepted without hassle.

But if you want to make View trust in itself (no red square on the dashboard for the connection servers in View Administrator), you still have to replace it's certificate too:

1. Generate a request for the View cert: openssl req -new -key rui.key -out view.csr -config openssl.cnf. As before, use FQDN as the Common Name.
2. (Optional) You can modify ext.txt if you created and used it as above.
3. Sign the csr: openssl x509 -req -in view.csr -CA myroot.crt -CAkey rui.key -out view.crt -days 3650 <-extfile ext.txt>
4. Export PKCS12: openssl pkcs12 -export -in view.crt -inkey rui.key -name vdm -passout pass: -out view.pfx
5. From here, see the View 5.1 Install guide pg. 75-77. Digested below:
6. Open the Local Computer Certificates on the View server. Run mmc, click on File->Add/Remove Snap-in..., click on Certificates, Add. Choose Computer Account->Next->Local Computer->Finish. Press OK.
7. Expand Certificates->Personal->Certificates. You shall see View's default generated certificate here. First, right-click on it, choose Properties. Change it's Friendly name to something. Press OK.
8. Right-click on the lower Certificates item, choose All-Tasks->Import...
9. Browse for view.pfx. It's password shall be empty. Enable the Mark this key as exportable checkbox! Next-next-finish.
10. The new key's Friendly name shall already be set to vdm, because of the PKCS12 export parameter -name, but double check it.
11. Stop and start the VMware View Connection Server service (wait for all depending services to stop) or reboot the computer (it is a windows after all).

After login, another nice green square shall await you. What a reward...

If you gone this far, than you probably already hate SSL Certificates. At least I did. Sorry for the long post. Over & out.

VMware View 5.1 - changing vCenter's address in the ADAM

So, if you have a View 5.1 (possibly upgraded from 4.x or 5.0) server, sometimes you are in the not-so-enviable position of having a vCenter registered by IP address, and unable to change it or remove it because of a certificate mismatch - you can't even validate a normal certificate for an IP. In this case, you can start deep diving into ADAM - The Active Directory Application Mode - the own embedded LDAP/AD service of View.
Here is where to change a registered vCenter's address inside View, without any impact on the pools, etc.

• First, you have to stop all services of View on it's own server. These should be everything that starts with VMware View in services.msc:

• See this VMware KB about how to connect to ADAM.
• Choose OU=Properties -> OU=VirtualCenter in the tree.
• There can be several Common Names at this point, all referring to the Virtual Centers that are connected to View.
• Right click on any CN to investigate it's properties. The attribute named pae-VCURL holds the address of the particular vCenter, that View is using to reach it. You have to change it only here.

View keeps virtually everything in ADAM, so in rare cases you will have to hunt in it for a particular setting. I recommend reading this KB about orphaned linked clones too. Now it may look old, but who knows when you have to use it with 5.1?

Also, if you want to revoke your trust in this VC's self-signed cert, you can simply clear the pae-VCSslCertThumbprint & pae-VCSslCertThumbprintAlgorithm attributes. Use the clear button to revert them to  of course.

That is all, go and explore ADAM on your own. Don't forget to ruin some enterprise system also.

Get some Jeos!

JeOS is the abbreviation (pronounced "juice") for Just Enough Operating System as it applies to a software appliance (source: Wikipedia).

Jeos is an idea implemented by VMware to create even more compact purpose driven VMs. Although didn't got too mainstream, JeOS is available with VMware Studio since the 2.5 release.
See this VMware blog entry about the idea, or here you can find the not-so-complete documentation...
With this feature, you can create a RedHat or Centos based VM (either 32 or 64 bit) with an unbelievable size of 15 megs!
Okay, so we have space and memory in our servers, why should we create micro-sized VMs? Because wastefulness should be considered a sin in Cloud environments. And you may run hundreds of these if needed in the place of one bloatware VM - the VM that has every single package of it's OS in it, although it's only using Apache for example. Think about a grid computing example with on demand node provisioning...


Jeos is still experimental in Studio, and I'll be honest, I don't think it will develop too rapidly. It's just too complex to use for some peeps - most people won't bother to use it. Basically, after the build you got a stripped down Linux without most of it's daemons. This means you are on your own - you have to hunt down library dependencies one by one for your program, using strace or something. I really loved it all the time, it reminded me on developing embedded systems again...


A few helpful hints for Jeos in Studio 2.6:

• DHCP is enabled by default in every JeOS VM. While I see the point in this, I consider it sometimes a bit unnecessary. To disable it (stop auto-starting it with the VM), you have to manually edit the file /opt/vmware/etc/jeos/default/initrd.xml and comment out line 102 on the Studio VM. Then the line shall look like # /bin/busybox udhcpc -b -s /etc/udhcp/node -i $iface - the # in the front makes it go away :) After this, building a JeOS VM won't imply using DHCP.
• Also, the DHCP client service is bugged - it's name resolution won't work as expected. It has a typo in it's init script. Edit /opt/vmware/etc/jeos/busybox/node file to fix it. Line 68 should look like if [ -n "$RESOLV_CONF" ] instead of RESOLVE.CONF. See this forum post at communities.vmware.com.
• /etc/inittab is generated when the "mkjeosvm" program is run at build time. If you want a custom inittab in your JeOS VM, you will have to edit Studio's /opt/vmware/etc/jeos/default/rootfs.xml. The inittab definition should start at about line 35.
• mkjeosvm is a python script in /opt/vmware/bin. You can still hack it, if you want a different GRUB timeout for example. It's value is at #652.
• Always make a backup before playing around with these files. It can hurt your building process or the built VM may have errors in it.

As always, no warranty, etc. Have fun!

Workstation 8 with Studio 2.5

...does work, with some assumptions. The new Workstation 8 literally merges the Server product-line (ex-GSX) with the Workstation product line, that's called VMware Workstation-Server service. It supports autostart features and finally a usable remote management interface, by using another workstation as client. It also supports the workstation as a client of ESXi5 or vSphere5, but that's off-topic now.
So, this server-service runs on Linux64 at my box, and I'm using it as a build-host for my Studio 2.5 projects. On WKS7, You had to run the Workstation with #/usr/bin/vmware all the time You wanted to run a VM. That called for a vncserver of course. Now, WKS8 supports running VMs as a service. The issue is: if You try to build a Studio VM, You still have to run the Workstation GUI (on the vncserver for example), otherwise the build will fail. This limitation will probably disappear in the next version of Studio. Also, old build VMs stay in the WKS library, even after deleting their files, this worked in WKS7 better.

Studio updater

I am playing with VMware Studio 2.5 now (great stuff btw), and seem I found a strange bug.
I am using Workstation 7 on Linux64 as the build host, and I try to create an update repository. It builds the VM, but when updating the repo the following error message appears in the build log:

Unable to create directory at manifest
; shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
pushd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
mkdir: cannot create directory `manifest': No such file or directory
It only occurs, when I choose not to build the ZIP archive, only OV*. Should test it on WKS8, but I guess it's a Studio problem. More to come later.

3D in Linux Workstation

The VMware Workstation on Linux does support 3D, however certain distributions (including Slack 13.37) does not ship with the S3 - now who remembers that company? - Texture Compression libraries, because of some licensing issues (see http://dri.freedesktop.org/wiki/S3TC). This occurs as an error message when running the VM "3D graphics acceleration will be disabled. This computer does not have a 3D graphics system supported by VMware Workstation.". In the VM's vmware.log file, in the same directory as the .vmx You should find some lines like "mks| VMGL: Extension missing, GL_EXT_texture_compression_s3tc", and "mks| GLManager: Required extension GL_EXT_texture_compression_s3tc is missing." and "mks| msg.glBackend.initFailed] 3D graphics acceleration will be disabled. This computer does not have a 3D graphics  system supported by VMware Workstation.". This means exactly as stated, You miss a .so file from You /usr/lib or /usr/lib64 respectively. You should just simply download the libtxc from the site above (direct link is http://cgit.freedesktop.org/~mareko/libtxc_dxtn/snapshot/libtxc_dxtn-1.0.1.zip), compile and place the .so in Your libs dir. That's all, next run, Windows 7 should enable Aero effects in Workstation on Linux!

KIES in Workstation

It is possible to run Samsung KIES (Galaxy family) in VMware Workstation on linux. You need to disable 3D acceleration in the vmx file (a black window occurs if it is enabled when starting KIES), and maybe some USB quirks from this forum post. Just a quickie, because the 3D disable thing is not obvious.