vCenter 5.1 U1 Install: Part 2 (Create vCenter SSL Certificates)

Welcome to Part 2 of the 15 part vCenter 5.1 Update 1 installation series. This post will guide you through the process of creating the vSphere 5.1 Update 1 vCenter SSL certificates. ALL production environments should use trusted SSL certs, not just “high security” environments. Key infrastructure services are probably running on vSphere, so security is paramount. After all, if your hypervisor gets p0wn3d, so will your VMs. Replacing vCenter SSL certificates is key to good security!

This is a tedious process, and each component has different ways of replacing the certificate. You can check out the official VMware guidance for vSphere 5.1 here. I’ve included a few simple script files in this post to help automate the process and reduce human error. The script at the bottom automates the whole request process, and is a superset of the various scripts earlier in the post. So I would suggest reading through the whole process then deciding which scripts, if any, you want to use. I prefer using only the last script, since it does everything.

Important: As mentioned in Part 1, VMware has released the vCenter Certificate Automation tool. This makes SSL certificate replacement easier, although not fully automated. This post will show you how to create all of the needed files in order to use the automation tool. I prefer using the automation tool and replacing all SSL certificates post-install, rather than doing it manually or by pre-staging.

For quick reference here are the other installments in this series:

Part 1 (SSO Service)
Part 3 (Install SSO Service SSL Certificate)
Part 4 (Install Inventory Service)
Part 5 (Install Inventory Service SSL Certificate)
Part 6 (Create vCenter and VUM Databases)
Part 7 (Install vCenter Server)
Part 8 (Install Web Client)
Part 9 (Optional SSO Configuration)
Part 10 (Create VUM DSN)
Part 11 (Install VUM)
Part 12 (VUM SSL Configuration)
Part 13 (VUM Configuration)
Part 14 (Web Client and Log Browser SSL)
Part 15 (ESXi Host SSL Certificate)

—

UPDATE 5/18/2013: I’ve updated the all-in-one certificate script at the end of this article. It now supports and automatically detects if you are using a subordinate CA, assuming you have the properly labeled CA files (root-1.cer and root-2.cer). If you only have a root CA, then it’s file should be called root.cer. It also silently overwrites any previous certificates, so you don’t have to click yes on each cert if you re-run the script.

UPDATE 5/4/2013: Added screenshots for scenarios when you have a subordinate CA. Also modified the concatenation command to put the certs in the proper order.

UPDATE 4/27/2013: Updated references to vSphere 5.1 Update 1, and made minor mods to the scripts for general cleanup. The process for Update 1 is exactly the same as prior versions of 5.1. I recommend using the vCenter Certificate Automation tool to replace the self-signed SSL certificates post-install.

UPDATE 4/7/2013: For compatibility with the VMware Certificate automation tool I’ve made a few changes. I added the creation of a vCenter Orchestrator certificate, and also the fully automated script at the bottom of the post creates the required chained “PEM” files for each service. You won’t use these PEM files if you manually replace certificates.

UPDATE 10/26/12: VMware has released guidance, in the form of several KB articles, on how to configure SSL certificates for vSphere 5.1. This is a complex process. Thankfully these new articles are a vast improvement over what was available at GA, and closely mirrors my original blog posts for the 5.1 GA release.

—

vCenter SSL Certificates

Certificates are tricky, and depending on how you “mint” them (OpenSSL root CA, Microsoft CA, commercial CA, etc.) the steps may differ significantly. This blog series assumes an online Microsoft Windows Server 2008 R2 Enterprise root CA (Server 2012 works as well) that has the web certificate services installed. VMware supports intermediate CAs, and I’ve tried to incorporate those instructions. However, I personally haven’t verified those steps.

The scope of this post will be only to create the vCenter 5.1 SSL certificate for all services. Follow-on posts cover the ins and outs of replacing the service specific SSL certificates, as the process differs for each service. For the official VMware KB article on creating the certificates, click here.

Although not mentioned in the VMware KB articles, “Pre-Staging” the SSL certificates is still the easiest method, when doing a clean install, to configure the SSL certificates. This eliminates some of the manual steps as many services (except the SSO) will automatically use the trusted certificates if they are in the right folder during the installation process. You can view a separate post here that I wrote which contains a script to automate the pre-staging process.To be clear, pre-staging is NOT required, but does reduce fresh installation time and effort.

Per VMware KBs, the trusted SSL certificates should have the Data Encipherment key usage attribute. If you are using a Microsoft CA with the default “Web Server” certificate, your minted certificates will NOT have this property. You can check out my blog post here for how to create a custom certificate template that has this required key usage feature. You can see this Key Usage in the screenshot below. I’ve heard reports of SSL certificates without this property working, but VMware currently has this property as required in their KB articles so I would be safe and use it.

A single SSL certificate, even for all-in-one servers will NOT work. This is due to how various components (such as Inventory Service, vCenter, etc.) register with the SSO service. Multiple SSL certificates are required for a functioning system. For a complete installation of vCenter with VUM, you need seven certificates:

• Inventory Service
• SSO
• Update Manager
• vCenter
• Web Client
• Log Browser
• Orchestrator

You will likely run into major problems if you try and use a commercial CA for your certificates. Many will ignore the “OU” field which the SSO service depends on, and must be unique in each certificate for each service. Without the required unique OU fields, you will be left with a non-functional system. You really need an internal CA where you can control the certificate templates, and validate the certificates are properly minted. The certificates also require the SAN (subject alternative name) field to be populated as well.

The key difference in each certificate is the “OU” property. This OU property must be unique, as this is the primary means the SSO service differentiates the SSL certificates for each service. Duplicate “OU” values is bad juju and will cause you a lot of grief, not to mention a smoking vCenter hole.

1. Download and install the Windows OpenSSL binary. You need the OpenSSL 0.9.8y (or later) package. Remember to install the appropriate Visual C++ Redistributable package prior to installing OpenSSL. While you can use the 1.x OpenSSL binaries for this manual process, the new VMware certificate automation tool needs the legacy 0.9.8 version to properly calculate the hashes. So I would go with the older version to save you potential future headaches.

2. Install OpenSSL with the default path. You need a certificate directory to store all of the configuration files and resulting certificates. I created a directory called Certs on my D drive. In that directory you need to create a folder for each service that will be getting a SSL certificate. Each certificate is unique, organizing them by folder is critical.

3. VMware requires that all the vCenter certificates contain a SAN (subject alternative name) field in them. I’ve provided OpenSSL configuration files below for each of the services. Save each of the configuration files below into their respective directory.

Note that VMware has you adding the IP address of the server in the subjectAltName field. You can see the difference here. Through feedback and testing, I haven’t seen where leaving out the IP address causes issues. But feel free to add that field, but remember to change out all of your certificates should the server IP address change.

The following fields in red for each file need to be changed for your environment. Copy and paste the contents into Wordpad. I’ve also tweaked the configuration file to include clientAuth extended key usage, as VMware support has told some people to include the property.

subjectAltName = DNS:ServerShortName, DNS:Server.DomainName
CountryName = US (Two letters ONLY)
stateOrProvinceName = YourState
localityName = YourCity
0.organizationName = YourCompanyName
commonName = Server.DomainName

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, clientAuth
 subjectAltName = DNS:ServerShortName, DNS:Server.DomainName

[ req_distinguished_name ]
 countryName = YourCountry
 stateOrProvinceName = YourState
 localityName = YourCity
 0.organizationName = YourCompanyName
 organizationalUnitName = vCenterInventoryService
 commonName = Server.DomainName

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, clientAuth
 subjectAltName = DNS:ServerShortName, DNS:Server.DomainName

[ req_distinguished_name ]
 countryName = YourCountry
 stateOrProvinceName = YourState
 localityName = YourCity
 0.organizationName = YourCompanyName
 organizationalUnitName = vCenterSSO
 commonName = Server.DomainName

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, clientAuth
 subjectAltName = DNS:ServerShortName, DNS:Server.DomainName

[ req_distinguished_name ]
 countryName = YourCountry
 stateOrProvinceName = YourState
 localityName = YourCity
 0.organizationName = YourCompanyName
 organizationalUnitName = vCenterServer
 commonName = Server.DomainName

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

[ v3_req ]
 basicConstraints = CA:FALSE
 keyUsage = digitalSignature, keyEncipherment, dataEncipherment
 extendedKeyUsage = serverAuth, clientAuth
 subjectAltName = DNS:ServerShortName, DNS:Server.DomainName

[ req_distinguished_name ]
 countryName = YourCountry
 stateOrProvinceName = YourState
 localityName = YourCity
 0.organizationName = YourCompanyName
 organizationalUnitName = vCenterWebClient
 commonName = Server.DomainName

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

[ v3_req ]
 basicConstraints = CA:FALSE
 keyUsage = digitalSignature, keyEncipherment, dataEncipherment
 extendedKeyUsage = serverAuth, clientAuth
 subjectAltName = DNS:ServerShortName, DNS:Server.DomainName

[ req_distinguished_name ]
 countryName = YourCountry
 stateOrProvinceName = YourState
 localityName = YourCity
 0.organizationName = YourCompanyName
 organizationalUnitName = VMwareUpdateManager
 commonName = Server.DomainName

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

[ v3_req ]
 basicConstraints = CA:FALSE
 keyUsage = digitalSignature, keyEncipherment, dataEncipherment
 extendedKeyUsage = serverAuth, clientAuth
 subjectAltName = DNS:ServerShortName, DNS:Server.DomainName

[ req_distinguished_name ]
 countryName = YourCountry
 stateOrProvinceName = YourState
 localityName = YourCity
 0.organizationName = YourCompanyName
 organizationalUnitName = vCenterLogBrowser
 commonName = Server.DomainName

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

[ v3_req ]
 basicConstraints = CA:FALSE
 keyUsage = digitalSignature, keyEncipherment, dataEncipherment
 extendedKeyUsage = serverAuth, clientAuth
 subjectAltName = DNS:ServerShortName, DNS:Server.DomainName

[ req_distinguished_name ]
 countryName = YourCountry
 stateOrProvinceName = YourState
 localityName = YourCity
 0.organizationName = YourCompanyName
 organizationalUnitName = VMwareOrchestrator
 commonName = Server.DomainName

Download Root Certificates

The root certificate(s) are required to properly create the required certificate files. Again, I’m assuming you have a Microsoft online CA, otherwise you are on your own to create your root certificate file.

1. Go to the Microsoft CA home page that you used to mint the certificates and 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.

2. 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.

As you can see in my screenshot below, I have a root CA (D001DC02-CA) and a subordinate CA (D001DC01-CA). In this case extra steps are needed, so proceed to step 3.

3. 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.

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.

copy Root64-2.cer+Root64-1.cer Root64.cer

Root64.cer example with a root and subordinate CA (certificates have been shortened):

Don’t delete any of these root or intermediary files, as they will be used later in the installation process.

4. You should now have the following folder structure, assuming you have one or more subordinate CAs. If not, you will only have a Root64.cer certificate file.

Create CSRs

After you tweak and save your OpenSSL configuration files you need to generate the actual CSR files so you can submit that to your CA. First, we need to generate the RSA 2048 bit private keys. I have two scripts that help automate the certificate process. The script immediately below only automates the CSR process, as you may not be using a Microsoft CA which my fully automated script at the end of this post requires.

At the end of this post is a script that automates all of the certificate minting process, including creating the CSRs, PFX and PEM files. However, it requires the use of an online Microsoft enterprise CA in your domain. Read through all of the steps so you know what is needed, then feel free to use the automated scripts instead of typing all of the commands for each of the certificates.

WARNING: vCenter is extremely picky about the format of the RSA private key file (rui.key) and you will most certainly have a smoking vCenter VM if you don’t have the right format. If the header of the RSA key file only reads “—–BEGIN PRIVATE KEY—–” then Houston, you have a major problem.

The format of your RSA private key file should have a header of “—–BEGIN RSA PRIVATE KEY—–“. This is the one and ONLY format that vSphere will accept.

1. Use the following OpenSSL command to create a file called rui.key. Run this in each directory, as each certificate should have a unique private key. Note, these steps differ ever so slightly from the VMware KB, but produce the same results. These steps produce the RSA key in the proper format from the get-go, without having to convert them like the KB article has you do.

c:\OpenSSL-Win32\bin\openssl.exe genrsa 2048 > rui.key

Note: I’ve added a script at the bottom of this post that automates the entire certificate process, after you create the OpenSSL configuration files. Scroll down to the end if you wish to try that out instead of individual commands that are in the next several steps.

2. Using the RSA private key and the service-specific configuration file we need to generate CSRs (certificate signing request) for each service. Run the command below in each service certificate folder, changing the name of the configuration file for each invocation.

c:\OpenSSL-Win32\bin\openssl.exe req -out rui.csr -key rui.key -new -config inventory.cfg

3. After running both commands you should now see rui.csr and rui.key files in each service folder.

Create_CSR.bat

Set OpenSSL_BIN=c:\OpenSSL\bin\openssl.exe
Set Cert_Path=D:\Certs

CD /d %Cert_Path%\vcenter\
%OpenSSL_BIN% genrsa 2048 > rui.key
%OpenSSL_BIN% req -out rui.csr -key rui.key -new -config vcenter.cfg

CD /d %Cert_Path%\Inventory\
%OpenSSL_BIN% genrsa 2048 > rui.key
%OpenSSL_BIN% req -out rui.csr -key rui.key -new -config inventory.cfg

CD /d %Cert_Path%\SSO\
%OpenSSL_BIN% genrsa 2048 > rui.key
%OpenSSL_BIN% req -out rui.csr -key rui.key -new -config SSO.cfg

CD /d %Cert_Path%\UpdateManager\
%OpenSSL_BIN% genrsa 2048 > rui.key
%OpenSSL_BIN% req -out rui.csr -key rui.key -new -config VUM.cfg

CD /d %Cert_Path%\webclient\
%OpenSSL_BIN% genrsa 2048 > rui.key
%OpenSSL_BIN% req -out rui.csr -key rui.key -new -config webclient.cfg

CD /d %Cert_Path%\LogBrowser\
%OpenSSL_BIN% genrsa 2048 > rui.key
%OpenSSL_BIN% req -out rui.csr -key rui.key -new -config LogBrowser.cfg

CD /d %Cert_Path%\Orchestrator\
%OpenSSL_BIN% genrsa 2048 > rui.key
%OpenSSL_BIN% req -out rui.csr -key rui.key -new -config Orchestrator.cfg

Mint Certificates

There are a couple of ways you can mint the SSL certificates from a Microsoft CA. One is using the traditional web interface. The other, is a command line method to automate the process. I prefer the command line, as it’s faster and less error prone.

–Command Line Method–

1. To use the command line method you need to know the hostname of your CA, the “name” of your CA (see first screenshot below), and the certificate “template name” which may NOT the same as the certificate “template display name”. The “template name” is usually the template display name without any spaces (see screenshot below).

Select the appropriate certificate template (e.g. “VMware SSL”) that has the additional key usage property (dataEncipherment). You can check out my blog post here for how to create a custom certificate template that has this key usage feature.

2. In the first certificate directory run the following command, of course changing the properties as needed for your CA. This will produce the rui.crt file, a newly minted SSL certificate.

certreq -submit -config “D001DC01\Contoso-D001DC01-CA” -attrib “CertificateTemplate:VMwareSSL” rui.csr rui.crt

3. Repeat the minting process for the remaining certificates…or use my script at the bottom of this post to automate the process.

–Web Method–

1. If you want to create the certificate the old fashion method then open the first rui.csr file with NotePad and copy the contents to the clipboard.

2. To create the certificate submit the CSR to the Microsoft CA then download the certificate. Navigate to the homepage of the Microsoft CA (https://YourCAServer/certsrv) and you should see a screen just like the one below. Select “Request a certificate.”

4. Select the second option shown below:

5. Paste the CSR you generated from OpenSSL into the request window. Change the certificate template to “VMware SSL” or whatever you have defined as your SSL certificate template with the additional key usage property. Again, you can check out my blog post here for how to create a custom certificate template that has this required key usage feature.

If you only see “User” and “Basic EFS” options, then the account you are using lacks the proper permissions on the CA to request certificates. Use a more privileged account to perform the request.

6. Submit the certificate request (Base 64 encoded) then Save As and use a file of rui.crt and place it into the appropriate folder (e.g. D:\Certs\Inventory) directory. If the saved file is mangled, you probably have the enhanced IE security enabled. Turn it off and re-submit the request and it should properly save.

7. Repeat the web-based minting process for the remainder of the certificates. Each folder should have the following files:

Certificate Validation

To validate the certificates have all of the right fields, double click on each rui.crt file and it should open up. Click on the Details tab and verify that the “OU” sub-field of the Subject name matches the service for which you created the certificate for. I would also double check the Subject Alternative Name to ensure both the short hostname and the server’s FQDN is listed.

Creating PFX Files

This process is also covered in the fully automated script below, but in case you want to manually do it you can follow the procedures here.

CD /d D:\certs\SSO
C:\openssl-Win32\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -certfile D:\certs\root64.cer -name rui -passout pass:testpassword -out rui.pfx
CD /d D:\certs\Inventory
C:\openssl-Win32\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -certfile D:\certs\root64.cer -name rui -passout pass:testpassword -out rui.pfx
CD /d D:\certs\vCenter
C:\openssl-Win32\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -certfile D:\certs\root64.cer -name rui -passout pass:testpassword -out rui.pfx
CD /d D:\certs\UpdateManager
C:\openssl-Win32\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -certfile D:\certs\root64.cer -name rui -passout pass:testpassword -out rui.pfx
CD /d D:\certs\WebClient
C:\openssl-Win32\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -certfile D:\certs\root64.cer -name rui -passout pass:testpassword -out rui.pfx
CD /d D:\certs\LogBrowser
C:\openssl-Win32\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -certfile D:\certs\root64.cer -name rui -passout pass:testpassword -out rui.pfx
CD /d D:\certs\Orchestrator
C:\openssl-Win32\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -certfile D:\certs\root64.cer -name rui -passout pass:testpassword -out rui.pfx

C:\openssl-win32\bin\openssl pkcs12 -in rui.pfx -info

When you run that command you will be prompted a few times to enter the password, which is ‘testpassword’. Validate all of the fields look appropriate.

Create JKS KeyStore

Note: If you want to use the VMware vCenter certificate automation tool, you don’t need to create the JKS keystore. So you can skip this section. I recommend you use this tool instead of manually replacing certificates.

1. We need to create an empty JKS keystore the SSO service will use. In an elevated command prompt enter the command below to create the keystore:

“C:\Program Files\VMware\Infrastructure\jre\bin\keytool.exe” -v -importkeystore -srckeystore D:\certs\sso\rui.pfx -srcstoretype pkcs12 -srcstorepass testpassword -srcalias rui -destkeystore D:\certs\sso\root-trust.jks -deststoretype JKS -deststorepass testpassword -destkeypass testpassword

2. To add your Root CA certificate to the store enter this command. If you have intermediate CAs, for this command use the Root64-1.cer file (not Root64.cer), which should be the root CA certificate.

“C:\Program Files\VMware\Infrastructure\jre\bin\keytool.exe” -v -importcert -keystore D:\certs\sso\root-trust.jks -deststoretype JKS -storepass testpassword -keypass testpassword -file D:\certs\Root64.cer -alias root-ca

When prompted to confirm you trust the certificate, enter yes.

3. If you have intermediary certificate authorities, you have a bit more work to do. You first need to get the hash of your Root64-2.cer file (intermediate CA public certificate). If you have additional intermediate CAs, repeat the process for each one:

openssl x509 -subject_hash -noout -in D:\certs\Root64-2.cer

4. To import the intermediate CA certificates into the JKS keystore run the following command, replacing YourHash with the output of the hash command in the previous step:

keytool -v -importcert -noprompt -trustcacerts -keystore D:\certs\sso\root-trust.jks -deststoretype JKS -storepass testpassword -keypass testpassword -file D:\certs\Root64-2.cer -alias intermediate-YourHash.0

5. You can now validate that the keystore has all of the required certificates by running the following command:

“C:\Program Files\VMware\Infrastructure\jre\bin\keytool.exe” -list -v -keystore D:\certs\sso\root-trust.jks

6. The SSO service needs a copy of the JKS so enter the following command:

copy D:\certs\sso\root-trust.jks D:\certs\sso\server-identity.jks

Automated Certificate Batch File

Below is the batch file that will create the private RSA keys, create CSRs based on the OpenSSL configuration file, get a minted certificate from a MS CA, then create the PFX file with the VMware password, and makes the PEM files needed for the vCenter certificate automation tool. Fully automated!

To successfully execute the script you need the following:

• All certificate directories created
• All OpenSSL configuration files created
• Root CA Only: Export the root CA certificate to root64.cer
• Root and subordinate CA: Export root CA to root64-1.cer and subordinate to root64-2.cer
• Have read and enroll permissions on the Microsoft CA template you want to use
• OpenSSL installed (0.9.8 strongly recommended)

The certreq command is very picky about the format of the CA name and certificate template. See the steps above for screenshots and more details on what to put there. It is not as obvious as it may first appear. The script assumes all certificates were minted from the root CA. Modifications would be needed if an intermediary CA is used.

Depending on the security and delegation in your environment, you may not have the rights to request a certificate from the enterprise CA. If that’s the case, find someone in the organization which does have the proper permissions to run the script below. After you run the script each directory should have the same files as shown below.

Summary

Once you have created all of the certificate files you can proceed to Part 3 if you want to manually install your SSL certificates (not recommended) or skip to Part 4 if you want to use the VMware vCenter certificate automation tool (highly recommended).

vCenter5.1_CertRequest.bat

:: Script to request vCenter 5.1 SSL certificates from a Microsoft CA
:: Modify these variables for your paths and CA information
:: Place your root64-1.cer and root64-1.cer (if using an intermediate CA)
:: in the Cert_Path directory. OpenSSL config files must already exist.
:: Also creates the chain.pem files for the VMware Certificate automation tool
::
:: Written by Derek Seaman, derekseaman.com
::

:: Certificate Authority Template name
Set Cert_Template=VMware-SSL

:: Certificate Authority Name
Set CA_Name=D001DC01\Contoso-D001DC01-CA

:: Path to OpenSSL
set OPENSSL_CONF=c:\OpenSSL\bin\openssl.cfg
Set OpenSSL_BIN=c:\OpenSSL\bin\openssl.exe

:: Path to your vcenter services directory with the config files
Set Cert_Path=D:\certs

:: Do not change anything below here
Set Root_CA_Cert=%Cert_Path%\Root64-1.cer
Set Sub_CA_Cert=%Cert_Path%\Root64-2.cer
Set CA_Chain=%Cert_Path%\Root.cer

if exist %Sub_CA_Cert% (
copy /B  %Sub_CA_Cert% + %Root_CA_Cert% %CA_Chain%
Set CA_Cert_Chain=%CA_Chain%
) Else (
Set CA_Cert_Chain=%Cert_Path%\root64.cer
)

CD /d %Cert_Path%\vcenter
%OpenSSL_BIN%  genrsa 2048 > rui.key
%OpenSSL_BIN%  req -out rui.csr -key rui.key -new -config vcenter.cfg
certreq -submit -q -f -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_Cert_Chain% -name rui -passout pass:testpassword -out rui.pfx
copy /B rui.crt + %CA_Cert_Chain% chain.pem

CD /d %Cert_Path%\Inventory
%OpenSSL_BIN%  genrsa 2048 > rui.key
%OpenSSL_BIN%  req -out rui.csr -key rui.key -new -config inventory.cfg
certreq -submit -f -q -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_Cert_Chain% -name rui -passout pass:testpassword -out rui.pfx

copy /B rui.crt + %CA_Cert_Chain% chain.pem
CD /d %Cert_Path%\SSO
%OpenSSL_BIN%  genrsa 2048 > rui.key
%OpenSSL_BIN%  req -out rui.csr -key rui.key -new -config SSO.cfg
certreq -submit -f -q -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_Cert_Chain% -name rui -passout pass:testpassword -out rui.pfx

copy /B rui.crt + %CA_Cert_Chain% chain.pem
CD /d %Cert_Path%\UpdateManager
%OpenSSL_BIN%  genrsa 2048 > rui.key
%OpenSSL_BIN%  req -out rui.csr -key rui.key -new -config VUM.cfg
certreq -submit -f -q -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_Cert_Chain% -name rui -passout pass:testpassword -out rui.pfx

copy /B rui.crt + %CA_Cert_Chain% chain.pem
CD /d %Cert_Path%\webclient
%OpenSSL_BIN%  genrsa 2048 > rui.key
%OpenSSL_BIN%  req -out rui.csr -key rui.key -new -config webclient.cfg
certreq -submit -f -q -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_Cert_Chain% -name rui -passout pass:testpassword -out rui.pfx

copy /B rui.crt + %CA_Cert_Chain% chain.pem
CD /d %Cert_Path%\LogBrowser
%OpenSSL_BIN%  genrsa 2048 > rui.key
%OpenSSL_BIN%  req -out rui.csr -key rui.key -new -config LogBrowser.cfg

certreq -submit -f -q -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_Cert_Chain% -name rui -passout pass:testpassword -out rui.pfx
copy /B rui.crt + %CA_Cert_Chain% chain.pem
CD /d %Cert_Path%\Orchestrator

%OpenSSL_BIN%  genrsa 2048 > rui.key
%OpenSSL_BIN%  req -out rui.csr -key rui.key -new -config Orchestrator.cfg
certreq -submit -f -q -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_Cert_Chain% -name rui -passout pass:testpassword -out rui.pfx
copy /B rui.crt + %CA_Cert_Chain% chain.pem