In this post we will take a look into the SSL certificate replacement process for vRealize Orchestrator (vRO) 7.x appliance
- Lab Environment
- Current VMware Certificate Restrictions
- Scenario 1: Use vCO Dunes Private Key
- Scenario 2: Use Custom Private Key
- Final Step
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.
include TEMPLATEPATH."/../../../itBlogDisclaimer.php"; ?>
Thanks Spas Kaloferov….. This article is perfectly crafted with appropriate commands and screen shots at right places.
Do we also have any such document for vRO 8.x. since in this version, its a huge change in overall architecture of the product.
Sharing some help for CSR file generation will be a great help.
Thanks in advance…
Deepak Yadav
+91 9594412421
HI, process hasn’t really changed .