How to Change the SSL Certificate of a vRO Appliance (7.x) (SKKB1021)

In this post we will take a look into the SSL certificate replacement process for vRealize Orchestrator (vRO) 7.x appliance

If you are want to know how to change the SSL certificate of a vCO 6.x Appliance, visit
How to change the SSL certificate of a vCO Appliance (6.x)
If you are want to know how to change the SSL certificate of a Windows installed vRO , visit
How to change the SSL certificate of windows installed vCO

Generally there are two scenarios you might see related to the vRO SSL certificates.

Scenario 1:

In the first scenario you use the existing private key of the vRO self-signed certificate (with alias dunes) and the existing keystore. With this private key you generate a certificate request which than is being used by a Certificate Authority (CA) to generate the final certificate. You than import this certificate to the existing keystore together with the certificates of all the Root, Intermediate and Subordinate Certificate Authorities up to the root of the certificate chain. So for example if you have the usual 3-tier Root CA , Intermediate CA and Issuing CA hierarchy, you will need to import the certificates of all 3 of them into the keystore. You can also create a new keystore and import all certificates . if you have a certificate package (PKCS21, ect…) you can import it and it will import all the certificates from the chain.

In the first scenario we will use the existing keystore to import all of the certificates. In the second scenario we will create new keystore and import the certificate package containing the private key and all certificates form the certificate chain.

Scenario 2:

In the second scenario you have received a certificate package from your company’s CA or 3rd party public CA and you want to use this certificate to secure the communication to and from the vCO/vRO. A reason why you would want to have custom private key might be that you company has security policies which require higher bit encryption or particular cypher being used for all SSL communications.

In this example we will be importing a PFX certificate package that contains the certificate private key and also all of the certificates for all CA’s from the certificate chain. We will be creating new keystore to use.

 

Lab Environment

The logical design of this lab can be seen HERE.

 

Current VMware Certificate Restrictions

Before we continue it’s good to understand the certificate restrictions that vRO 7.0 presents.

vRO has algorithm restrictions for certification path (CertPath) processing. In some environments, certain algorithms or key lengths may be undesirable for certification path building and validation.  For example, "MD2" is generally no longer considered to be a secure hash algorithm.

vRO 7.0 does not support MD2 or RSA with key length smaller then 1024

There are also some algorithm restrictions for Secure Socket Layer/Transport Layer Security (SSL/TLS) processing In some environments, certain algorithms or key lengths may be undesirable when using SSL/TLS.

vRO 7.0 does not support SSLv3, RC4, DH with key length smaller then 768

 

Scenario 1: Use vCO Dunes Private Key

In the first scenario you use the existing private key of the vRO self-signed certificate (with alias dunes) and the existing keystore. With this private key you generate a certificate request which than is being used by a Certificate Authority (CA) to generate the final certificate. You than import this certificate to the existing keystore together with the certificates of all the Root, Intermediate and Subordinate Certificate Authorities up to the root of the certificate chain. So for example if you have the usual 3-tier Root CA , Intermediate CA and Issuing CA hierarchy, you will need to import the certificates of all 3 of them into the keystore. You can also create a new keystore and import all certificates . if you have a certificate package (PKCS21, ect…) you can import it and it will import all the certificates from the chain.

In the first scenario we will use the existing keystore to import all of the certificates. In the second scenario we will create new keystore and import the certificate package containing the private key and all certificates form the certificate chain.

Generate Certificate Request and Issue Certificate

First let’s query the existing keystore and examine the certificates.

In previous versions of vRO the password for the keystore was dunesdunes. In version 7.x the password for the keystore is generated on first appliance boot. I’ts the same on all appliances.

To find the password make an SSH session to the appliance and run:

cat /var/lib/vco/keystore.password

To query the keystore using this password run:

keytool -list -keystore "/etc/vco/app-server/security/jssecacerts"

We will use the private key of the dunes certificate to generate certificate request file.

To generate the certificate request file run:

keytool -certreq -alias dunes -keypass "vJNnwffBGKw5L8weYRC1fRbnNWfJ6zxhzh1gKe4s" -keystore "/etc/vco/app-server/security/jssecacerts" -file "/etc/vco/app-server/security/myCertRequest.csr" -storepass "vJNnwffBGKw5L8weYRC1fRbnNWfJ6zxhzh1gKe4s"

Verify the myCertRequest.csr file was generated.

Now as I’m administrator of my own Certificate Authority I’ve created a certificate template called VMwareCertificate which I will use to issue the certificate for my vCO. You can provide this to your 3-rd party certificate vendor and request a certificate from them.

I’m running the following command to submit a request to the CA and issue a certificate:

Certreq –attrib "CertificateTemplate:VMwareCertificate" –config "lan1dc1.vmware.com\RootCA" –submit –f "C:\myCertRequest.csr" "C:\MyCert.crt"

You should see the certificate being created

Import the Ccertificate

Import a PEM into the vRO SSL store

If you have received a PEM encoded certificate you can use the vRO Control Center interface to import it.
To do so you can navigate to the Certificates , then Orchestrator Server SSL Certificate, then Import , then Import from a PEM-encoded file.

I have the certificate in a CRT format so I will use the keytool tool to import the certificate into the keystore.
Before importing the CRT file into the keystore I must import all certificates from the certificate chain into the Orchestrator trust store.
To import certificates into the Orchestrator trust store open the Control Center and navigate to Certificates, then Trusted Certificates, then click Import.

Select the certificate and click Import.

Repeat this for all the certificates from the certificate chain.

 

Import a CRT into the vRO SSL store

If you have received a CRT certificate you can use the keytool to import it

To import a CRT file into the keystore run :

keytool -importcert -alias dunes -keypass "vJNnwffBGKw5L8weYRC1fRbnNWfJ6zxhzh1gKe4s" -file "/etc/vco/app-server/security/MyCert.crt" -keystore "/etc/vco/app-server/security/jssecacerts" -storepass "vJNnwffBGKw5L8weYRC1fRbnNWfJ6zxhzh1gKe4s"

Verify that the new certificate has been imported in the keystore by running:

keytool -list -keystore "/etc/vco/app-server/security/jssecacerts" -storepass "vJNnwffBGKw5L8weYRC1fRbnNWfJ6zxhzh1gKe4s"

If you are missing any of the certificates from the certificate chain (Root, Intermediate, Issueing CA’s certificates) you can import them through Control Center as described earlier.
In this case I have all of my certificate chain certificates present.
Reboot the appliance.

 

Verify the Certificate

You should find that the certificate is trusted and valid. You might need to close and open the browser in order for the change to take effect.

Examine the certificate and verify it is the one you just issued.

Verify the certificate is shows in Control Center under Certificates tab, then Orchestrator Server SSL Certificate.

Scenario 2: Use Custom Private Key

In the second scenario you have received a certificate package from your company’s CA or 3rd party public CA and you want to use this certificate to secure the communication to and from vRO. A reason why you would want to have custom private key might be that you company has security policies which require higher bit encryption or particular cypher being used for all SSL communications.
In this example we will be importing a PFX certificate package that contains the certificate private key and also all of the certificates for all CA’s from the certificate chain. We will be creating new keystore to use.

 

Import the Certificate Package into the vRO SSL Trust Store

Backup/rename the jssecacerts keystore :

mv /etc/vco/app-server/security/jssecacerts /etc/vco/app-server/security/jssecacerts-bak

Copy the certificate package you have (in this case PFX package) into the vCO appliance.

In previous versions of vRO the password for the keystore was dunesdunes. In version 7.x the password for the keystore is randomly generated on first appliance boot.
To find the password make an SSH session to the appliance and run:

cat /var/lib/vco/keystore.password

Note that the password stored in the file must match the PFX password. You have generally two options:

  • Use this password when you create the PFX package so that you have encrypted the private key wit it.
  • If you already have a PFX package with a given password, change the password in the file to mach.

I already have a package with dunesdunes password, so I will change it in the file.

Note: If you are building a vRO Cluster and this is your first node, the keystore on all other nodes will be recreated and will contain the same certificates. The keystore password though will again be automatically generated on all other nodes. If you want to have the same keystore password on all nodes, after building the cluster, you can go on each remaining node and repeat the steps in this scenario. Essentially you will be recreating the keystore on each node and defining same password as you did on the first node. 

After you have found the password run the following command via SSH to import the PFX package:

keytool -importkeystore -srckeystore "/etc/vco/app-server/security/rui.pfx" -srcstoretype pkcs12 -srcstorepass "dunesdunes" -deststoretype jks -destkeystore "/etc/vco/app-server/security/jssecacerts" -deststorepass "dunesdunes"

You should get similar output:

The alias in this case is {00b5ba81-f24e-4f91-9f9a-f3e48f1574d5}. We need to change it to dunes. Do accomplish this run the following command via SSH:

keytool -changealias -alias {00b5ba81-f24e-4f91-9f9a-f3e48f1574d5} -destalias dunes -keystore "/etc/vco/app-server/security/jssecacerts" -storetype jks -storepass "dunesdunes"

Change the owner of the keystore to vco. This is the default owner of the keystore , but if you were logged on as root during the previous operations this is no longer the case.

chown vco "/etc/vco/app-server/security/jssecacerts"

To list the contents of the keystore run:

keytool -list -keystore "/etc/vco/app-server/security/jssecacerts" -storepass "dunesdunes"

Reboot the appliance

 

Verify the Certificate

You should find that the certificate is trusted and valid. You might need to close and open the browser in order for the change to take effect.

As we have replaced the existing keystore any certificates which were previously imported (vCenter, vRA, ect…) are gone. You must import them again via the Control Center interface.

If you list the contents of the key tool ro check in Control Center, under Trusted Certificates you should find all the certificates from the certificate chain:

keytool -list -keystore "/etc/vco/app-server/security/jssecacerts" -storepass "dunesdunes"

Final Step

If all went well, go grab a beer.

DISCLAIMER; This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Photos
Unless stated, all photos are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. If used with watermark, no need to credit to the blog owner. For any edit to photos, including cropping, please contact me first.
Recipes
Unless stated, all recipes are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Please credit all recipes to the blog owner and link back to the original blog post.
Downloadable Files
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.
Comments
Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to
– Comments deemed to be spam or questionable spam
– Comments including profanity
– Comments containing language or concepts that could be deemed offensive
– Comments containing hate speech, credible threats, or direct attacks on an individual or group
The blog owner is not responsible for the content in comments.
This policy is subject to change at anytime.

Leave a Reply

Your email address will not be published. Required fields are marked *