How to replace default VCSA 5.5 certificates with Microsoft CA signed certificates

DISCLAIMER: This is a very lenghty procedure and I’ve changed some steps from the original KB trying to make it shorter; if I made some mistakes please let me know.

I don’t do this all the time but today I had to replace SSL certificates on a vCenter Virtual Appliance and since I know this will happen more and more often I thought I should write a shorter procedure since VMware KB is very detailed and, yet again, very long. At least it’s not as long as the infamous 96 steps of version 5.1.

Before proceding it’s good practice to shutdown your vCSA and take a snapshot.

Go to http://vcenter_ip_address:5480 or http://fqdn:5480 and chack that the “Certificate regeneration enabled” setting in the Admin tab of the vCSA web interface is set to “No” or we will lose all our work at first reboot:

1

Also, since we are going to use a Microsoft CA for this tutorial, it would be a good idea to take a look at KB2062108 and complete those steps before proceeding.

Note: This procedure is specific for vCSA 5.5. If you have a previous version of vCSA please refer to KB2036744.

Download and install the latest build of OpenSSL 0.9.8 on a machine of your choice. For convenience I installed it on a Windows VM in “C:\OpenSSL”.

Create the following folders:

C:\OpenSSL\Certs
C:\OpenSSL\Certs\vCenterSSO
C:\OpenSSL\Certs\InventoryService
C:\OpenSSL\Certs\LogBrowser
C:\OpenSSL\Certs\AutoDeploy

Open a text editor:

[ req ]
default_md = sha512
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req
input_password = testpassword
output_password = testpassword

[ v3_req ]
basicConstraints = CA:false
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = DNS:vcva55, IP: 10.0.0.10, IP:ServerIPv6Address, DNS: vcva55.vmware.com

[ req_distinguished_name ]
countryName = US
stateOrProvinceName = NY
localityName = New York
0.organizationName = VMware
organizationalUnitName = vCenterApplianceUniqueServer
commonName = vcva55.vmware.com

Change the following lines:

  • subjectAltName: insert here data about name and IP of your vCSA (you can omit IPv6 if you don’t use it)
  • commonName: this must be your vCSA FQDN
  • all section [req_distinguished_name]
  • leave organizationalUnitName as it is

Save the file as “C:\OpenSSL\Certs\openssl_generic.cfg”.

We need to generate one .cfg file for each service, changing the “organizationalUnitName” by opening the “openssl_generic.cfg” file we just created:

  • organizationalUnitName = VMware vCenter Service Certificate (save as “C:\OpenSSL\Certs\vCenterSSO\openssl_vpxd.cfg”)
  • organizationalUnitName = VMware Inventory Service Certificate (save as “C:\OpenSSL\Certs\vCenterSSO\openssl_inventoryservice.cfg”)
  • organizationalUnitName = VMware LogBrowser Service Certificate (save as “C:\OpenSSL\Certs\vCenterSSO\openssl_logbrowser.cfg”)
  • organizationalUnitName = VMware vSphere Autodeploy Service Certificate (save as “C:\OpenSSL\Certs\vCenterSSO\openssl_autodeploy.cfg”)

You should now have a .cfg file for each service in each folder with a different organizationalUnitName.

To generate the certificate requests, assuming you have the same path I have, you can use the following commands.

cd c:\OpenSSL\bin

openssl req -new -nodes -out c:\openssl\certs\vCenterSSO\rui_vpxd.csr -keyout c:\openssl\certs\vCenterSSO\rui_vpxd.key -config c:\openssl\certs\vCenterSSO\openssl_vpxd.cfg

openssl req -new -nodes -out c:\openssl\certs\InventoryService\rui_inventoryservice.csr -keyout c:\openssl\certs\InventoryService\rui_inventoryservice.key -config c:\openssl\certs\InventoryService\openssl_inventoryservice.cfg

openssl req -new -nodes -out c:\openssl\certs\LogBrowser\rui_logbrowser.csr -keyout c:\openssl\certs\LogBrowser\rui_logbrowser.key -config c:\openssl\certs\LogBrowser\openssl_logbrowser.cfg

openssl req -new -nodes -out c:\openssl\certs\AutoDeploy\rui_autodeploy.csr -keyout c:\openssl\certs\AutoDeploy\rui_autodeploy.key -config c:\openssl\certs\AutoDeploy\openssl_autodeploy.cfg

Now you should also have a .key file and a .csr file in each respective directory.

To generate certificates from the .csr file login your Microsoft CA web interface (by default it is http://servername/CertSrv/):

  1. Click the Request a certificate link.
  2. Click advanced certificate request.
  3. Click the Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file link.
  4. Open the certificate request (rui_service.csr, as generated above for each component) in a plain text editor and paste this text into the Saved Request box.
  5. Select the Certificate Template as VMware Certificate.
  6. Click Submit to submit the request.
  7. Click Base 64 encoded on the Certificate issued screen.
  8. Click the Download Certificate link.
  9. Save the certificate as rui_service.crt, in the appropriate C:\OpenSSL\Certs\<service>\ folder.  (for example rui_vpxd.crt)
  10. Repeat Steps 2 to 10 for each of the additional service.
  11. Navigate back to the home page of the certificate server and click Download a CA certificate, certificate chain or CRL.
  12. Click the Base 64 option.
  13. Click the Download CA Certificate chain link.
  14. Save the certificate chain as cachain.p7b in the c:\openssl\certs\ directory.

By default, Microsoft CA certificates are generated with the .cer format. Either use Save As or change it to .crt before continuing.

When complete, you have four certificates (rui_service.crt) for each of the services generated in their respective c:\openssl\certs\<services> folders and the cachain.p7b file in the c:\openssl\certs\ folder.

Copy the c:\openssl\certs folder on the root of the vCenter filesystem via SCP, rename it to “ssl”, SSH to the vCSA, then:

service vmware-stsd stop
service vmware-vpxd stop

Rename all files in the service folders so that the .key file is named “rui.key” and the .crt file is named “rui.crt”.

On the vCenter Appliance, move where the cachain.p7b file is, then convert it to cachain.pem:

openssl pkcs7 -print_certs -in cachain.p7b -out cachain.pem

Now open cachain.pem with a text editor and remove any text before the first “—–BEGIN CERTIFICATE—–” and after “—–END CERTIFICATE—–“.

Note: This assumes there are no intermediate certificates in the Certificate Authority.

Copy the cachain.pem file in every service folder.

cd <vcenterservicefolder>
cat rui.crt cachain.pem > chain.pem
/usr/sbin/vpxd_servicecfg certificate change chain.pem rui.key

If all goes well you should receive this:

VC_CFG_RESULT = 0

Check KB2057248 if you get a different result.

service vmware-stsd start
cd /etc/vmware-sso/register-hooks.d
./02-inventoryservice --mode uninstall --ls-server https://<em>server.domain.com</em>:7444/lookupservice/sdk

Create the chain.pem file for every service:

cat rui.crt cachain.pem > chain.pem

Then:

cd <inventoryservicefolder>
openssl pkcs12 -export -out rui.pfx -in chain.pem -inkey rui.key -name rui -passout pass:testpassword
cp rui.key /usr/lib/vmware-vpx/inventoryservice/ssl
cp rui.crt /usr/lib/vmware-vpx/inventoryservice/ssl
cp rui.pfx /usr/lib/vmware-vpx/inventoryservice/ssl
cd /usr/lib/vmware-vpx/inventoryservice/ssl/
chmod 400 rui.key rui.pfx
chmod 644 rui.crt
cd /etc/vmware-sso/register-hooks.d
./02-inventoryservice --mode install --ls-server https://<em>server.domain.com</em>:7444/lookupservice/sdk --user <em>sso_administrator</em> --password <em>sso_administrator_password
</em>rm /var/vmware/vpxd/inventoryservice_registered
service vmware-inventoryservice stop
service vmware-vpxd stop
service vmware-inventoryservice start
service vmware-vpxd start

Note: As there is a plain-text password on the above command, to avoid the history file showing the contents of the password because it is in plain text in the command above, run the unset HISTFILE command prior to executing any step containing a password.

Note: The default SSO administrator username for vCenter Single Sign-On 5.5 is administrator@vSphere.local

cd /etc/vmware-sso/register-hooks.d
./09-vmware-logbrowser --mode uninstall --ls-server https://<em>server.domain.com</em>:7444/lookupservice/sdk
cd <logbrowserservicefolder>
<code>openssl pkcs12 -export –out rui.pfx –in chain.pem -inkey rui.key –name rui –passout pass:testpassword</code>
cp rui.key /usr/lib/vmware-logbrowser/conf
cp rui.crt /usr/lib/vmware-logbrowser/conf
cp rui.pfx /usr/lib/vmware-logbrowser/conf
cd /usr/lib/vmware-logbrowser/conf
chmod 400 rui.key rui.pfx
chmod 644 rui.crt
cd /etc/vmware-sso/register-hooks.d
./09-vmware-logbrowser --mode install --ls-server https://<em>server.domain.com</em>:7444/lookupservice/sdk --user <em>sso_administrator</em> --password <em>sso_administrator_password
service vmware-logbrowser stop
service vmware-logbrowser start

In this environment the AutoDeploy service is not started so I’m skipping this step. (refer to KB2057223 to complete this step)

You can now restart the vCenter Server Appliance and chek that the certificates have been successfully replaced.

 

Related documents
Configuring Certificate Authority (CA) signed certificates for vCenter Server Appliance 5.5 (2057223)
Creating a Microsoft Certificate Authority Template for SSL certificate creation in vSphere 5.x (2062108)
Decoding a non-zero VC_CFG_RESULT for failed vpxd_servicecfg certificate changes (2057248)
Configuring certificates signed by a Certificate Authority (CA) for vCenter Server Appliance 5.1 (2036744)

vSphere 5.5 Update 1 is out with vSAN support!

What’s new

vCenter server 5.5 Update1

  • vCenter Server is now supported on Windows Server 2012 R2
  • vCloud® Hybrid Service™ vSphere® Client Plug-in, is now available in vSphere Web Client.

 

vSphere ESXi 5.5 Update1

  • VMware Virtual SAN  Virtual SAN 5.5 is a new hypervisor-converged storage tier that extends the vSphere Hypervisor to pool server-side magnetic disks (HDDs) and solid-state drives (SSDs). By clustering server-side HDDs and SSDs, Virtual SAN creates a distributed shared datastore designed and optimized for virtual environments. Virtual SAN is a standalone product that is sold separate from vSphere and requires its own license key

 

vSphere replication 5.5 Update1

  • VMware Virtual SAN is a fully supported feature of vSphere 5.5u1. You can use Virtual SAN in production environments with vSphere Replication 5.5.1 and vSphere 5.5u1.
  • Configure vSphere Replication on virtual machines that reside on VMware vSphere Flash Read Cache storage. vSphere Flash Read Cache is disabled on virtual machines after recovery.

 

vCenter Orchestrator 5.5 Update1

  • Workflow tagging
  • Plug-ins improvements
  • Version control system support
  • Dynamic Types (Beta)

Horizon View 5.3.1 is out and supports vSAN!

Today, VMware announced the General Availability (GA) of VMware Virtual SAN 5.5 and I’d like to take a moment to also introduce Horizon View 5.3.1. With this release, we are continuing the tradition of rapidly introducing innovations to market. And, now, the details:

  • Horizon View 5.3.1 supports VMware Virtual SAN 5.5. VMware Virtual SAN 5.5 is a component of VMware vSphere 5.5U1.
  • Horizon View 5.3.1 when used with VMware Virtual SAN 5.5 has been shown to reduce the total CAPEX cost of storage by up to 50%.
  • Horizon View 5.3.1 GA is intended for use with Virtual SAN 5.5 datastores only. There are no other new features in Horizon View 5.3.1 besides support for Virtual SAN 5.5.
  • Customers can purchase a Virtual SAN 5.5 license to deploy Horizon View 5.3.1.

How to distribute Mirage Client with logon script

One of the things that Horizon Mirage doesn’t give you out of the box is the ability to deliver the Mirage client to clients in a centralized manned, which is kinda awkward for a solution that tries to centralize everything.

I solved this problem with a logon script i use for client deployments; you can use and tweak my script as you want but don’t blame me if it doesn’t work for you 🙂

Here’s the thing:

@echo off

rem echo Detecting OS processor type

if "%PROCESSOR_ARCHITECTURE%"=="AMD64" goto 64BIT

:32BIT
rem echo 32-bit OS
msiexec /norestart /quiet /l* "\\path_to_log\%COMPUTERNAME%-MirageClient.log" /i "\\path_to_setup\MirageClient.x86.15875.msi" serverip=<your_mirage_server> usessltransport=false
goto END

:64BIT
rem echo 64-bit OS
msiexec /norestart /quiet /l* "\\path_to_log\%COMPUTERNAME%-MirageClient.log" /i "\\path_to_setup\MirageClient.x64.15875.msi" serverip=<your_mirage_server> usessltransport=false
:END

Notice that the setup files have to be on a network share as well as the location of the log files where everyone have write access.

New job, new challenges, new opportunity to learn

If you have been following my blog so far you might have noticed that I’ve kept a long radio silence recently.

The reason for this is that I am leaving the company I am working for to join a Citrix Partner, Sinthera.

I will be part of the Citrix Group there and still be involved in VMware projects, so it seems I will be able to know both sides of the EUC river.

A lot to learn, a lot of new stuff… many new challenges.

I’ll do my best to keep writing in this blog and you might expect I will open a Citrix section as well 🙂

I would like to thank you all the people at Gruppo Sinapsi who helped me develop as a professional in all those years.

Wish me luck!

Using ESXTOP with OSX Terminal application displays incorrectly

If are a VMware Admin switching from Windows to Mac you will find some limitations, even if lately VMware solved one of the major problems making the vSphere Web Client fully compatible with Mac in version 5.5.

Speaking about running ESXTOP from Mac, if you tried it you know you won’t be able to get any understandable data out of it and the reason seems to be the default  type of emulation that needs to be changed from “xterm-256color” to “xterm”.

Thanks to this post on the PunchingClouds Blog (bookmark it, it’s one of the good ones!) now this is not a problem anymore.

Using View Agent Direct-Connection

VMware released this piece of software that was previously available to VMware employees only or specific use case for customers that would make specific requests.

I’ve been deploying and supporting Horizon View environments since version 4.5 and if like me you can’t understand the use of VADC other than customer POC or lab use than you should watch this video which explains scenarios and use cases where it could be useful.

Upgrading VMware Mirage to 4.3

I’ve been waiting for a while for version 4.3 to come out for some interesting features some of my customers would be able to leverage, but I never thought I would be so surprised once I got to understand how to do it.

Essentially, there is no upgrade procedure, you just uninstall and reinstall the components just as they were before by using installer files from the 4.3 version.

Yes, I know, I thought the same but I can say that in the end it just seems to work. Even if there is no orchestration of a version upgrade that checks things around before proceeding I have to admit that the ease of operations is pretty nice.

Preparations steps are simple, just make sure you have the following written down:

  • Database server name
  • Credentials for the database server
  • Horizon Mirage server cache directory location
  • Cache size

Then just stop all Mirage services, snapshot all volumes, backup your DB and you’re done. A more detailed procedure can be found here but there is really not much more than that.

Now to the upgrade (or should I say reinstall?), the only thing to remember is that the order of operations must be respected:

  1. Select Control Panel > Add or Remove Programs to uninstall the system components.
  2. Uninstall all Horizon Mirage servers.
  3. Uninstall the Horizon Mirage Management console.
  4. Uninstall the Horizon Mirage Management server.
  5. Uninstall Horizon Mirage WebAccess.
  6. Use the new mis files to install the latest version of Horizon Mirage.
  7. Install the Horizon Mirage Management server.
  8. Install the Horizon Mirage Management console.
  9. Install the Horizon Mirage servers.
  10. Install Horizon Mirage WebAccess.

You will need to reboot the server after step 9.

A neat thing is that you won’t need to do anything to update your Mirage clients because once they contact the server they will self-upgrade with no downtime for the user. I just wish it would be possible to suppress the balloon notification that informs users about the upgrade or the possibility to decide when user clients will be upgraded.

I used this procedures twice on simple single server implementations and I had no issues.

Even if I would prefer a real upgrade procedure, in the end of the day i just want upgrades to work and this seems to be the case with Horizon Mirage, so no complains.

Horizon Mirage CVD Explorer AKA How to extract files from a CVD that is not actively being used

In Horizon Mirage the client has a nice little feature that allows users to self-restore files and folders taking them straight from their snapshots in the SIS (Single Instance Storage) database on the Horizon Mirage server that they are connected to.

Simple enough, but there is still a situation where you can’t use this feature. What if a specific CVD had been archived or what if simply the user or the sysadmin doesn’t have access to the endpoint where the Mirage client is installed?

In the Horizon Management Server there is some sort of a hidden feature (Mirage seems to have many…) that lets you open a CVD from the SIS, browse the filesystem and recover files and folders; the only limitation I’ve found compared to the full Mirage client experience is that you will not have the chance to choose from what snapshot to extract the files but you can only access the last one.

Fair enough.

Here’s what I did when I had to recover a folder from a user’s CVD:

1. RDP to the Management Server
2. cd “C:\Program Files\Wanova\Mirage Management Server”
3. run “Wanova.Server.Tools.exe CvdExplore”
4. Set output directory by clicking “Server -> Set output dir” (if you don’t set this value default location will be “C:\Program Files\Wanova\Mirage Management Server\CvdExplorer” for a default install)
5. Type in the path of the Mirage storage (eg. e:\mirage)
6. Type in the CVD number then hit enter (eg. 10001)
7. Browse the file system and find the file/folder you need
8. Right click and choose “Extract”
9. The application will automatically exit and you will find your files/folders in the output directory

Good to go!

Horizon Mirage 4.3 Released!

After quite a long radio silence i can tell you that since i’ve been working behind the scenes with Horizon Mirage, i am pretty excited about the announcement of the new 4.3 version!

This version provides the following new features and improvements:

  • The IT manager can now manage VMware View full clone desktops with Horizon Mirage. The IT manager can send image updates to View desktops, while keeping the user applications and data intact.
  • A new policy enables Horizon Mirage to work only with base and app layer updates, without uploads, reducing the overhead of the Horizon Mirage steady state on the end user’s machine.
  • Using Windows 7 migration with layers:
    • The IT manager can send app layers during the migration process.
    • Endpoints receive the base layer and the app layers in a single batch, and require only one reboot.
    • When the IT manager is following the progress of the migration, the app layers assignments under the Windows 7 migration task can also be followed.
  • The new web console supports the Protection Manager role, which has primary responsibility to ensure that the devices are protected and synchronized with the CVDs.
  • The dashboard for the Protection Manger role includes:
    • Last known upload errors, to help the IT manager focus on the main issues that are preventing users from uploading their data.
    • Centralization trends, to enable the IT manager to view the current state of the endpoint centralization process and determine how long this phase will take to finish.
    • Unprotected endpoints, to enable the IT manager to view, for a specific time period, which endpoints did not complete the upload.
    • Network disconnects, to enable the IT manager to view if there are slow remote branches that suffer from network disconnects that affect user uploads.

I’ll try to share my findings with this product soon as i did with Horizon Workspace.

Stay tuned!

%d bloggers like this: