Tag Archives: VMware Vcenter Server

The authentication server returned an unexpected error

Posted on March 12, 2014 | Leave a comment

I came in this morning only to be greeted by my web client telling me that I can’t login because it can’t create SAML 2.0. I am not sure that I really want it creating SAML 2.0….I don’t know SAML 1.0. Ok, bad joke. Here was the message…

I found KB2034798 at which point I remoted into my SSO server and checked the imsTrace.log for “NetUserGetLocalGroups”. I didn’t find it…so the KB didn’t apply to me…L

After some more googling I found this blog post that indicated that references KB2043070. The idea is that there is a local identity source within SSO that it is trying to authenticate the users to. You have to login with the admin@system-domain account and password. Hopefully you saved this when setting up your SSO server. The only problem I had was that I didn’t have this local identity source to remove.

I thought to myself, that there might be a stale identity source on the list that it is authenticating to. I was talking to a coworker and they mentioned that there was a domain that was deleted the day before. AHAH!! I clicked on the identity source of the domain that had been removed and then clicked “Test Connection”. There was an error that didn’t tell me much.

I cancelled out and was back at my list of identity sources. I selected the identity source that had been removed from AD and I hit the red X, “Delete Identity Source”. You will get a prompt asking for you to confirm. One thing to note is that the identity source that I deleted was not one of the default domains at the bottom. If you haven’t set a default domain up, I would do that now. I am wondering if there might be a bug that uses the identity source at the top of the list instead of the default at the bottom. After deleting the state Identity Source I was able to login again.

vSphere HA detected that host is in a different network partition than the master

Posted on February 17, 2014 | 16 comments

Target: Host
Previous Status: Green
New Status: Red
Alarm Definition:
([Event alarm expression: vSphere HA agent on a host has an error; Status = Red] OR [Event alarm expression: vSphere HA detected a network isolated host; Status = Red] OR [Event alarm expression: vSphere HA detected a network-partitioned host; Status = Red] OR [Event alarm expression: vSphere HA detected a host failure; Status = Red] OR [Event alarm expression: Host has no port groups enabled for vSphere HA; Status = Red] OR [Event alarm expression: vSphere HA agent is healthy; Status = Green])
Event details:
vSphere HA detected that host (host) is in a different network partition than the master (Cluster) in Datacenter

I had been getting this message randomly over the last couple months on some of my datacenter hosts. These alerts didn’t seem to be causing any problems within the cluster, but I wanted to get to the bottom of this. I opened a ticket with VMware and uploaded the logs from both the host and vCenter, but they didn’t see anything out of the ordinary. On the second webex with VMware I noticed a couple strange things with the management network that might be the cause.

The first thing I noticed was that the NICs were set for “Auto Negotiate”. I originally set up our environment on ESXi 4 before upgrading to ESXi 5.1. When I initially set this up I hard coded (KB1004089) these to 1000GB/Full. I am wondering if at some point during the upgraded that they defaulted back. On our switches it was set at 1000GB/Full so it is important that we set this on the host NICs to 1000GB/Full as well.
The second thing that I noticed that in the Management network that I had the Load Balancing set to “Route based on IP hash”. The problem here is that for this to work correctly you need a port channel configured (I do not have this configured this way). This might be the cause of the HA problem if the traffic is going across these NICs is getting confused because of the Load Balancing configuration. I changed this to “Route based on the originating virtual port ID”, which makes the traffic go out on the port that it came in on. There is a good read found here…http://blogs.vmware.com/kb/2013/03/troubleshooting-network-teaming-problems-with-ip-hash.html.

This case is still ongoing with VMware and I should know in the next couple weeks if this solves my problem; my gut tells me it will.

16 Comments

Posted in Configuration Changes, VMware Vcenter Server, VMware Vsphere 5

Tagged HA, NICS, Teaming, VMware Vcenter Server, vSphere 5.1

Creating a template for Server 2012 R2 – Part 1

Posted on February 7, 2014 | 5 comments

I have borrowed items from http://www.boche.net/blog/index.php/2012/08/16/microsoft-windows-server-2012-tips/ to create this post. I encourage you to take a moment to check out that post.

This is the step by step document that I used to build my 2012 and 2012 R2 VMs.

VM values will start at:

Hardware:	Value:
Memory	4 GB
CPU’s	1
Video card	Auto-detect video settings
VMCI device	None
SCSI Controller 0	VMware Paravirtual
Hard disk 1	40 GB, Thin
CD/DVD Drive 1	Client Device
Floppy Drive 1	Removed (when done)
Network Adapter 1	VMXNET3
General Options	OS: Microsoft Windows Server 2012 and 2012 R2
VMware Tools	Default Settings
Virtual Machine Version	9

Creating the VM

In vCenter click “File” then “New” then “Virtual Machine”
Choose the “Custom” radio button and then “Next”.
Name the SM and choose the folder location.
Choose the datastore for the VM and then click “Next”.
Make sure that the “Virtual Machine Version: 8” radio button is selected. (5.1 is using version 9 so I am not sure why this can’t be selected here. We will change this later.
Select the “Windows” radio button and then choose “Microsoft Windows Server 2012 (64-bit).
Take the default of 1 virtual socket and 1 core per virtual socket.
Take the default of 4GB memory and click “Next”
Choose your Network and change the adapter to “VMXNET 3” then click “Next”.
Change the SCSI controller to “VMware Paravirtual” and then click “Next”.
Select the “Create new virtual disk” radio button and then “Next”.
Take the default of 40GB and click “Next”.
Take the default virtual device node. For the system partition you want this to be SCSI 0:0. Click “Next”.
On the summary screen click the “Edit the virtual machine settings before completion” box and then click “Continue”.
Click on the Video Card and then change the radio button to “Auto-detect settings”.
Click on the CD/DVD and then choose the datastore location that you have the 2012 R2 install ISO. Make sure under Device Status that “Connect at power on” is checked. Now click “Finish”.
Right click on your newly created VM and click “Edit Settings”.
Click on the Floppy drive 1 and choose the “Use existing floppy image in datastore” radio button. Then click “Browse”. At the bottom of the datastores you should see a folder called “vmimages”. Double click this folder. (For some reason until the VM is created this folder does not show up and that is why we had to create the VM and then go back into the settings to change this).
Double click on the “floppies” folder.
Choose the “pvscsi-Windows2008.flp” and then “OK”.
The Floppy drive 1 settings should look like this and then click “OK”.
On the list of VMs click the one you are building and then click the “Power On” button.
Now click the “Open Console” button.
The VM should boot into the 2012 R2 setup screen. Choose your language and then “Next”.
Click “Install”.
Choose the version of server that you are using. We use the Datacenter here. Then click “Next”.
Agree to give up your first born to Microsoft by clicking the “I accept the license terms” box and then click “Next”.
Choose “Custom: Install Windows only (advanced).
Uh oh, there is no location to install Windows. Luckily you configured the floppy drive 1 earlier right? Click the “Load Driver” button.
Click “Browse”.
Look for the Floppy Disk Drive and then double click “amd64”.
Select the “VMware PVSCSI Controller (A:\amd64\pvscsi.inf) and click “Next”.
Hey look there is our drive!! Click “Next”.
Windows should now be installing.
Enter a password for your admin account. Do not lose this password!
You should have the login screen now.

5 Comments

Posted in Server 2012, Templates, VMs, VMware Vcenter Server, VMware Vsphere 5, Windows Server 2012 R2

Tagged Server 2012, Server 2012 R2, Templates, VMware Vcenter Server, vSphere 5, vSphere 5.1

Installing APC Network Shutdown for ESXi – Part 3

Posted on October 23, 2013 | 1 comment

In Part 3 we are going to install Powerchute Network Shutdown on the OVA that we deployed, then we are going to configure it to shut down the VMs in case of a problem.

See APC pdf FA159776. Open Putty.exe, insert the name or IP of the VMA you just deployed, and then click “Open“. Click “Yes” if you get a security alert. Login with vi-admin and your password that you set earlier.

Create a temp directory in opt using the command (You will be prompted for the vi-admin password): sudo mkdir /opt/temp

Next we need to change the permissions to this temp directory: sudo chmod 777 /opt/temp

Now to check the permissions: ls -la /opt The permissions should now read drwxrwxrwx

Now using WINSCP we need to transfer the .tar.gz file that we downloaded earlier up to the ESXi host. Enter the appropriate information and then click “Login“. Click “Yes” or “Proceed” if prompted with a security warning.

Check the “Never show this banner again” box and then click “Continue“. You should now see a screen with two windows. The window on the left is your local computer and the screen on the right is the VMA. Navigate on the left window until you find the .tar.gz file.

On the right window the drop down where it says “vi-admin“. Change this to /<root>. Then navigate to “opt–>temp“

Drag the .tar.gz file from the left window to the right window. Click “Copy” when prompted.

Verify that the file has been copied successfully.

Now go back to Putty.exe and we are going to uncompress the file. The commands are: gunzip pcnsname.tar.gz then: tar -xvf pcnsname.tar

Use the ls-la command and you should see a new ESXi folder. Use the command cd ESXi to change to this folder.

List the contents of ESXi with the ls -la command. We need to change the permissions for the installation file: sudo chmod 777 install_en.sh
Now do another ls -la to see that the permissions have changed to rwxrwxrwx.

Now we are ready to install PCNS. Use the command: sudo ./install_en.sh
Press “Enter” and then use the “z” key to scroll to the end of the agreement. If you agree then type “yes” and then press “Enter“.

Accept the default installation path (or insert a different one if you prefer). Press “Enter“. Type “yes” and “Enter” that you are sure about the path.

Take the default for the java directory. Press “Enter“.

Next the installation looks for the ESXi host that will be shut down. First add the IP of the host and then it will ask for the username and password for the host to make this change. Update: Almost all of the deployments failed to add the ESXi host here, so I would choose “q” to skip and then at the command line do: sudo vifp addserver <hostname/ IP address of ESXi host>

Verify that the server has been added with the command: vifp listservers

To ensure Powerchute can shutdown the VMs on the host, we need to add the ESXi host to the fasspass. Use the command: vifptarget -s <server name or ipaddress>
Now type the command: vicfg-nics -l
You should see a list of nics on the ESXi host.

One the server has been added you should be able to open a browser and go to the powerchute configuration wizard: https://vmahostnameorip:6547

Click “Next” and you should see the Configuration Wizard: Security page. Insert the username and password and the authentication phrase. This must match the card in your APC device. By default this is apc/apc with the passphrase: “admin user phrase” then click “Next“.

On the UPS Electrical Configuration page choose the correct configuration for your company and then click “Next“.

On the UPS Details page choose the protocol, port, and IP for the APC network card.

On the Miscellaneous page check the box for “Automatically check for updates to PCNS” and then click “Next“.

Confirm the details and then click “Apply“.

Hopefully you see that the computer is now protected. Click “Next“.
You should now see that the wizard is complete, now click “Finish”.

You will now see the main page for the Network Shutdown. Click “Configure Events” and then click the check box for “Shutdown System” on “UPS: On Battery“.

The “Shut Down Operating System” page will display and input 300 into the “Shut down the PCNS operating system only when the event lasts this long (seconds)“

Finally, we need to set up the virtual machine shutdown options on the ESXi host. Open the vSphere Client, select the host, and then choose the “Configuration” tab. Under the “Software” pane click on “Virtual Machine Startup/Shutdown“.

In the top right corner click “Properties“. Click the box “Allow virtual machines to start and stop automatically with the system“. Set the shutdown delay (120 default) and then set the shutdown action to “Guest Shutdown“.

Leaving VMs under the Manual startup will make it so when the host turns back on, the VMs will not start up by themselves. Usually you want to make sure power is restored and stable before bringing up VMs. You can change your VMs to start automatically if you really wanted to.

THAT’S IT!!

1 Comment

Posted in Powerchute, Uncategorized, VMA, VMware Vsphere 5

Tagged OVA, Powerchute Network Shutdown, VMware Vcenter Server, vSphere 5, vSphere 5.1

Installing APC Network Shutdown for ESXi – Part 2

Posted on October 23, 2013 | 1 comment

In Part 2 we are going to configure the OVA that we just deployed

Click on your new VMA and then click the “Open Console” button.

There should be a Network Configuration menu. I have found that if I set the gateway first that it will not save when I set the IP. I am going to set that last. Choose option “3” to set the hostname.

Make your hostname match your VM name.

Select option “4” to set the DNS servers. Type the appropriate primary (Server 1) DNS IP and then press “Enter“. If used, also add your secondary (Server 2) DNS IP and press “Enter” again.

Select option “6” to set the IP for eth0. I only use IPv4 so type “n” to not configure IPv6, then “y” to configure IPv4, and then “n” to not use DHCP. Type the IP and Subnet for your VMA and then “y” to confirm it is correct.

Now I set the Gateway. Choose option “2” and the press “Enter” to set the gateway for eth0. Type the IP of your IPv4 Default Gateway and the press “Enter“. Press “Enter” again to skip the gateway for IPv6.

Choose option “1” to “Exit this program“. This will boot the VMA with the network settings that we just configured.

Next the VMA will ask for the old password for the vi-admin account. Press “Enter” for the Old Password. Then type your new password “Enter” and then retype it when prompted. “Enter” again.

The VMA should boot and you should see the following screen. Browse to https://VMA-IP:5480 to verify connectivity.

Great, now you have configured the new VMA, it is now time to install Powerchute in Part 3.

1 Comment

Posted in Powerchute, VMA, VMware Vcenter Server, VMware Vsphere 5

Tagged OVA, Powerchute Network Shutdown, VMware Vcenter Server, vSphere 5, vSphere 5.1

Part 2 — vCenter 5.1 U1 — Creating and installing SSL certs for SSO.

Posted on June 17, 2013 | 1 comment

Installing Certificates with the VMware SSL Certificate Automation Tool

From and administrative prompt run c:\vmwarecerttool\ssl-environment.bat. This is important because it sets the variables that we edited early on.
Next run c:\vmwarecerttool\ssl-updater.bat
At this point backup all VMware Databases (VCDB, RSA, and VCU). Also take a VMware snapshot of the three VMware VMs.
Select Option 1 and then Option 8. Print out the Detailed Plan.
Press 9 to go back to the main menu and then choose option 3, “Update Single Sign-on”. Say a huge prayer and then press 1 to “Update the Single Sign-on SSL Certificate. You will be prompted for the Single Sign-on master password. Did you remember to write down your single sign-on master password? You will need this many times during this install.

Hopefully it was successful…
Switch to the vCenter Inventory Service Server. From an administrative prompt run c:\vmwarecerttool\ssl-environment.bat and then c:\vmwarecerttool\ssl-updater.bat. Select Option 4 “Update Inventory Service” and then option 1 “Update the Inventory Service Trust to Single Sign-On.
Select option 3, “Update the Inventory Service SSL Certificate”. You will be prompted for the SSO admin password.
Login to the vCenter Server. From an administrative prompt run c:\vmwarecerttool\ssl-environment.bat and then run c:\vmwarecerttool\ssl-updater.bat. Choose option 5, “Update vCenter Server” and then option 1, “Update the vCenter Server Trust to Single Sign-On”.
Make sure that you created an administrator account within vCenter to use for this install. This will be needed for the next step!
Select option 2, “Update the vCenter Server SSL Certificate”. You will need the passwords for your vcenter administrator, SSO admin, and the vCenter system database password.
Next, select option 3, “Update the vCenter Server Trust to the Inventory Service”.
Go back to the Inventory Service Server and choose option 2, “Update the Inventory Service Trust to vCenter Server”.
Switch again to the vCenter Server and select option 5 to get to the main menu, and then option 6, “Update vCenter Orchestrator (vCO)”. Select option 1, “Update the vCenter Orchestrator Trust to Single Sign-On”.
Select option 2, “Update the vCenter Orchestrator Trust to Single Sign-On”.
Select option 3, “Update the vCenter Orchestrator (vCO) SSL Certificate”.
Select option 5 to go back to the main menu. Select option 7, “Update vSphere Web Client and Log Browser”. Now select option 1, “Update the Web Client Trust to Single Sign-On”. You will be prompted for the SSO admin password.
Now choose option 2, “Update the Web Client Trust to Inventory Service”.
Continue with option 3, “Update the Web Client Trust to vCenter Server”.
Next choose option 4, “Update the Web Client SSL Certificate”. You will be prompted for the SSO admin password.
Continue by selecting option 5, “Update the Log Browser Trust to Single Sign-On”. This will ask you for the SSO admin password.

The last item for the certification tool is to choose option 6, “Update the Log Browser SSL Certificate”. This will ask you for the SSO admin password.

Updating VUM SSL Certificate

Backup all the files in the directory below. Copy the rui.key, rui.crt, and rui.pfx files from the c:\certs\vum directory to c:\Program Files (x86)\VMware\Infrastructure\Update Manager\SSL
Stop the VMware vSphere Update Manager Service.
In the C:\Program Files (x86)\VMware\Infrastructure\Update Manager directory launch the VMwareUpdateManagerUtility.exe application.
Login to the vCenter server using proper credentials.
Click on the SSL Certificate option on the left side then check the box on the right side and click Apply.
If all goes well you should see the window below. Restart the service as directed.
Go Back to Part 1
https://favoritevmguy.wordpress.com/2013/06/17/part-1-vcenter-5-1-u1-creating-and-installing-ssl-certs-for-sso/

1 Comment

Posted in Single Sign On, VMware Vcenter Server, VMware Vsphere 5

Tagged Certificates, Single Sign On, VMware SSL Certificates, VMware SSO, VMware Vcenter Server, vSphere 5.1

Part 1 — vCenter 5.1 U1 — Creating and installing SSL certs for SSO.

Posted on June 17, 2013 | 5 comments

There is a lot of information out there for installing vCenter 5.1, but the information is lacking for getting SSL certs working properly. I first want to thank Derek Seaman over at www.derekseaman.com for his posts regarding what to do. I have tried to shorten this a little bit for my own recollection. Here is what I did to get SSL certs working.

Preparation

Make sure you have installed the SSO Server, Inventory Service Server, and vCenter Server. I used three separate machines for my environment, but you can use just one if you wanted to.
Download and install the Visual C++ 2008 Redistributables (x64) and Win64 OpenSSL v0.9y from http://slproweb.com/products/Win32OpenSSL.html on your SSO server.
Create a c:\certs folder on the SSO server containing the following subfolders:
Download the SSL Certificate Automation Tool from https://my.vmware.com/group/vmware/get-download?downloadGroup=SSL-TOOL-10. Unzip this to c:\vmwarecerttool folder.
Following Derek Seaman’s blog post http://www.derekseaman.com/2012/09/create-vmware-windows-ca-certificate.html , create a VMware-SSL template on your CA server.
You will need the following information during the install:

SSO Administrator

Username: admin@System-Domain

Password:

vCenter Administrator

Username:

Password:

Original Database Password

Creating Certificates

1. Edit the ssl-environment.bat file located in c:\vmwarecerttool and fill in the appropriate information:

set sso_cert_chain=c:\certs\sso\chain.pem
set sso_private_key=c:\certs\sso\rui.key
set sso_node_type=single
set sso_admin_is_behind_lb=no

set is_cert_chain=c:\certs\inventory\chain.pem
set is_private_key_new=c:\certs\inventory\rui.key

set vc_cert_chain=c:\certs\vCenter\chain.pem
set vc_private_key=c:\certs\vCenter\rui.key

set ngc_cert_chain=c:\certs\WebClient\chain.pem
set ngc_private_key=c:\certs\WebClient\rui.key

set logbrowser_cert_chain=c:\certs\LogBrowser\chain.pem
set logbrowser_private_key=c:\certs\LogBrowser\rui.key

set vco_cert_chain=c:\certs\Orchestrator\chain.pem
set vco_private_key=c:\certs\Orchestrator\rui.key

set vum_cert_chain=c:\certs\UpdateManager\chain.pem
set vum_private_key=c:\certs\UpdateManager\rui.key

set sso_admin_user=admin@system-domain
set vc_username=corp\vminstaller

2. Next, create the following configuration files in their respective folders. Make sure that you name the files correctly. Do not include the .cfg filename in the .cfg file. I have done this…J Do not change the organizationalUnitName! I have created an example of the Inventory.cfg. I got these from http://www.derekseaman.com/2012/09/vmware-vcenter-51-installation-part-2.html .

EXAMPLE: Inventory.cfg
[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:VCINV1, DNS:VCINV1.DOMAIN.LOC

[ req_distinguished_name ]
countryName = US
stateOrProvinceName = Missouri
localityName = Saint Louis
0.organizationName = IT
organizationalUnitName = vCenterInventoryService
commonName = VCINV1.DOMAIN.LOC

Inventory.cfg
[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:(Your Inventory Server), DNS:(FQDN of your Inventory Server)

[ req_distinguished_name ]
countryName = (Country Code)
stateOrProvinceName = (State)
localityName = (City)
0.organizationName = (Organization)
organizationalUnitName = vCenterInventoryService
commonName = (FQDN of your Inventory Server)

SSO.cfg
[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:(Your SSO Server), DNS:(FQDN of your SSO Server)

vCenter.cfg

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectAltName = DNS:(Your vCenter Server), DNS:(FQDN of your vCenter Server)

[ req_distinguished_name ]
countryName = (Country Code)
stateOrProvinceName = (State)
localityName = (City)
0.organizationName = (Organization)
organizationalUnitName =vCenterServer
commonName = (FQDN of your vCenter Server)

WebClient.cfg

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ req_distinguished_name ]
countryName = (Country Code)
stateOrProvinceName = (State)
localityName = (City)
0.organizationName = (Organization)
organizationalUnitName =vCenterWebClient
commonName = (FQDN of your vCenter Server)

VUM.cfg

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ req_distinguished_name ]
countryName = (Country Code)
stateOrProvinceName = (State)
localityName = (City)
0.organizationName = (Organization)
organizationalUnitName =VMwareUpdateManager
commonName = (FQDN of your vCenter Server)

LogBrowser.cfg

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ req_distinguished_name ]
countryName = (Country Code)
stateOrProvinceName = (State)
localityName = (City)
0.organizationName = (Organization)
organizationalUnitName =vCenterLogBrowser
commonName = (FQDN of your vCenter Server)

Orchestrator.cfg

[ req ]
default_bits = 2048
default_keyfile = rui.key
distinguished_name = req_distinguished_name
encrypt_key = no
prompt = no
string_mask = nombstr
req_extensions = v3_req

[ req_distinguished_name ]
countryName = (Country Code)
stateOrProvinceName = (State)
localityName = (City)
0.organizationName = (Organization)
organizationalUnitName =VMwareOrchestrator
commonName = (FQDN of your vCenter Server)

3. You should now have one configuration file in each of the certificate folders you created earlier. Next, we need to pull down the root certificate. I am using Microsoft CA, so that is the only example I can give. Open a browser and go to https://yourcaserver/certsrv/. Make sure you fill in your CA server. Click on Download a CA certificate, certificate chain or CRL. Change the encoding method to Base 64 and click Download CA certificate chain. Change the file name to cachain.p7b.

4. Double click on the downloaded certificate, then locate the certificate in the console. If you have more than one certificate in the console, skip to step 3 below. If you have just one certificate, right click on the certificate and select All Tasks -> Export. Select Base-64 encoded and save the certificate with a filename of Root64.cer in the root of the Certs directory.

Notice that I have a root CA and a Subordinate CA

5. If you have a root and intermediate CAs (two or more certs in the console), you have some extra work. Export each certificate from the console as Base-64 and save into different files (e.g. Root64-1.cer and Root64-2.cer). You MUST save your Root CA as Root64-1.cer and the intermediary CA as Root64-2.cer.

6. We also need a concatenated file of the CAs (Root64.cer), in reverse order. Reverse order means the root is at the bottom of the file, and the subordinate CA is at the top. From an administrative command prompt in the c:\certs folder run:
copy Root64-2.cer+Root64-1.cer Root64.cer

7. Create a batch file in c:\certs called create_csr.bat. Paste the following into this file:

Set OpenSSL_BIN=c:\OpenSSL\bin\openssl.exe

Set Cert_Path=C:\Certs

CD /d %Cert_Path%\vcenter\