VMware vCenter 5.1 Installation: Part 2 (Create vCenter SSL Certificates)

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 1/27/2013: I've refreshed this post to reflect changes in VMware KB articles, reader feedback, and general cleanup to make it easier to follow.

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, and the directives given with the 5.1 GA release flat out did not work. Thankfully these new articles are a vast improvement, and closely mirror my original blog posts for the 5.1 GA release. I've since consolidated all of my previous updates plus the new VMware guidance into a refreshed version of the article, so that its less confusing. If you want to start at the beginning of this vCenter 5.1 install series, you can find part one here.

---

In Part 1 of my series on installing VMware vCenter 5.1, we got the SSO Service installed using a remote Microsoft SQL 2008 R2 database. In production environments you should replace all of the default self-signed SSL certificates with trusted certificates. This is a tedious process, and each component has different ways of replacing the certificate. Again, you can check out the official VMware guidance for vSphere 5.1.0 here. ANY production environment should use trusted SSL certs, not just "high security" environments. Key infrastructure is probably running on vSphere, so its security is paramount.

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 a Microsoft Windows Server 2008 R2 Enterprise root CA that has the web certificate services installed.

The scope of this post will be only to create the SSL certificates for the vCenter 5.1.0 services. Follow-on posts cover the ins and outs of replacing the service specific 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

Also, you will likely run into major problems if you try and use a commercial CA for your certificates. Many, if not all, will ignore the OU field which the SSO service depends on. 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.

 

They key difference in each certificate is the "OU" property. This OU property must be unique, as this seems to be 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.

Configuration File Creation

1. Download and install the Windows OpenSSL binary. You need the OpenSSL v1.0.1c (or later) package. Remember to install the appropriate Visual C++ Redistributable package prior to installing OpenSSL.

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. You can put this directory anywhere you want.

3. VMware requires that the vCenter related certificates contain a SAN (subject alternative name) field in them. I've provided OpenSSL configuration files below for each of the services. All of the fields in red must be updated with your information. The country code must be only two letters. My folder structure looks like this:

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.

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

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

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 a two scripts that help automate the certificate process. The first only automates the CSR process, as you may not be using a Microsoft CA which my full automated script requires.

At the end of this post is a script that automates all of the certificate minting process, including creating the CSRs and PFX 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 every 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
----

CD /d D:\certs\vcenter
c:\OpenSSL-Win32\bin\openssl.exe genrsa 2048 > rui.key
c:\OpenSSL-Win32\bin\openssl.exe req -out rui.csr -key rui.key -new -config vcenter.cfg

CD /d D:\certs\Inventory
c:\OpenSSL-Win32\bin\openssl.exe genrsa 2048 > rui.key
c:\OpenSSL-Win32\bin\openssl.exe req -out rui.csr -key rui.key -new -config inventory.cfg

CD /d D:\certs\SSO
c:\OpenSSL-Win32\bin\openssl.exe genrsa 2048 > rui.key
c:\OpenSSL-Win32\bin\openssl.exe req -out rui.csr -key rui.key -new -config SSO.cfg

CD /d D:\certs\UpdateManager
c:\OpenSSL-Win32\bin\openssl.exe genrsa 2048 > rui.key
c:\OpenSSL-Win32\bin\openssl.exe req -out rui.csr -key rui.key -new -config VUM.cfg

CD /d D:\certs\webclient
c:\OpenSSL-Win32\bin\openssl.exe genrsa 2048 > rui.key
c:\OpenSSL-Win32\bin\openssl.exe req -out rui.csr -key rui.key -new -config webclient.cfg

CD /d D:\certs\LogBrowser
c:\OpenSSL-Win32\bin\openssl.exe genrsa 2048 > rui.key
c:\OpenSSL-Win32\bin\openssl.exe req -out rui.csr -key rui.key -new -config LogBrowser.cfg

CD /d D:\certs\Orchestrator
c:\OpenSSL-Win32\bin\openssl.exe genrsa 2048 > rui.key
c:\OpenSSL-Win32\bin\openssl.exe 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.

--Web Method--

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

5. 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."

 

6. Select "advanced certificate request."

7. Select the second option shown below:

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

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

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

Download Root Certificates

Further in the SSL replacement process we will need the public root certificate(s) file in Base-64 encoded format.

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.

3. If you have a root and intermediate CA (two or more certs in the console), you have some extra work. Export each certificate from the console and save into different files (e.g. Root64-1.cer and Root64-2.cer). For the purposes of this blog series, you MUST save your Root CA as Root64-1.cer. Any intermediary CAs should be Root64-2.cer, etc.  We also need a concatenated file of the CAs (Root64.cer):

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

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:

Creating PFX Files

1. To create the required PKCS#12 PFX files use the following command for each service (note that "testpassword" is required by VMware. Do NOT try and use a custom password!). Notice that we also embed the root certificate into the PFX file (-certfile). Also, do NOT change the friendly name (-name) of "rui" to anything else. The Profile Driven storage service will likely not function and die with an unhelpful error message.

 

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

  

2. To make life a little easier below is a little batch file that automates the PFX creation process. Of course change any paths that you need to. As I mentioned before, the script at the end of this post automates the entire process including PFX creation.

 

Create_PFX.bat

---

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

 

----

3. To validate the PFX files were created correctly you can run the following command from one of the service certificate folders:

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

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

Pre-Staging SSL Certificates

If you are performing a fresh install of the vCenter 5.1 components, I strongly urge you to use my pre-staging method of SSL certificate installation. That will save you A LOT of time, pain, and suffering by doing it post-install.

While it won't replace the SSO SSL certificates, it can do the Inventory service, vCenter, web client, and VUM services (sorry, LogBrowser is still outstanding). Check out my blog post here for a batch file that automates the pre-staging process for you. After you complete those steps, you can proceed to Part 3 where we replace the SSO SSL certificates.

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
• Downloaded the root CA certificate(s) into the root64.cer file
• Have read and enroll permissions on the CA template you are using

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:

---
Set OpenSSL_BIN=c:\OpenSSL-Win32\bin\openssl.exe
Set Cert_Path=c:\OpenSSL-Win32\certs
Set Cert_Template=VMwareSSL
Set CA_Name=D001DC01\Contoso-D001DC01-CA
set CA_Cert_Path=c:\OpenSSL-Win32\certs\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 -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_CERT_Path% -name rui -passout pass:testpassword -out rui.pfx
copy /B rui.crt + %CA_Cert_Path% 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 -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_CERT_Path% -name rui -passout pass:testpassword -out rui.pfx
copy /B rui.crt + %CA_Cert_Path% 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 -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_CERT_Path% -name rui -passout pass:testpassword -out rui.pfx
copy /B rui.crt + %CA_Cert_Path% 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 -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_CERT_Path% -name rui -passout pass:testpassword -out rui.pfx
copy /B rui.crt + %CA_Cert_Path% 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 -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_CERT_Path% -name rui -passout pass:testpassword -out rui.pfx
copy /B rui.crt + %CA_Cert_Path% 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 -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_CERT_Path% -name rui -passout pass:testpassword -out rui.pfx
copy /B rui.crt + %CA_Cert_Path% 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 -config "%CA_NAME%" -attrib "CertificateTemplate:%Cert_Template%" rui.csr rui.crt
%OpenSSL_BIN%  pkcs12 -export -in rui.crt -inkey rui.key -certfile %CA_CERT_Path% -name rui -passout pass:testpassword -out rui.pfx
copy /B rui.crt + %CA_Cert_Path% chain.pem