How to Change the SSL Certificate of a vRO Appliance (6.x) (SKKB1008)

Introduction

In this post we will take a look into the certificate replacement process for vCenter Orchestrator (vCO)/vRealize Orchestrator (vRO) appliance in order for the appliance to work over SSL.We will be using vCO version 5.5.2, but the process is the same for previous versions of vCO, with exception that paths to the keystores or the keytool might have changed.  

If you are searching how to change the SSL certificate of a WIndows installed vCO/vRO , visit
How to change the SSL certificate of windows installed vCO

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

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

Scenario 1:

In the first scenario you use the existing private key of the existing vCO/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 certificate. You than import this certificate to the existing keystore together with the certificates of all 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 there or if you have a certificate package (PKCS21, ect…) you can import only it.

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.

 

Note: Depending on the vCO/vRO version some of the paths in the commands used might vary. Known paths for previous versions are:
/opt/vmo/jre/lib/security/jssecacerts

 

Lab Environment

The following environment has been used in all of the examples below:

  • Active Directory Domain called vmware.com
  • Windows Server 2012 R2 (with FQDN lan1dc1.vmware.com)
    • Domain Controller
    • DNS Server.
    • PowerShell v4 Host.
    • .NET 4 Framework installed (4.0.30319)
  • Windows Server 2008 R2 SP1 (with FQDN lan1dm1.vmware.com)
    • Domain Member
    • PowerShell v3 Host.
    • .NET 4 Framework installed (4.0.30319)
  • vCO 5.5.1.0 Virtual Appliance (with FQDN vco-a-01.vmware.com)
    • vCO PowerShell Plugin installed (version 1.0.4.1736639)

The full lab logical design can be seen HERE.

 

Scenario 1: Use vCO Dunes Private Key

In the first scenario you use the existing private key of the existing vCO/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 certificate. You than import this certificate to the existing keystore together with the certificates of all 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 there or if you have a certificate package (PKCS21, ect…) you can import only it.

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.

 

Import the CA certificates into the vCO SSL Trust Store

First we must import the certificates of all CA’s that make up our certificate chain into the vCO/vRO keystore.
We can either use the existing vCO/vRO workflows to do so or we can use the keytool (shown later) to import them. I will be using the workflows for this example.

Make sure the orchestrator services are started and logon on the the vCO console

Navigate to Library > Configuration > SSL Trust Manager.

Start the Import a trusted certificate from a file workflow.
Select the certificate of your Root Certificate authority.

Make sure the certificate you are selecting has been exported as Base-64 encoded X.509 (.cer) file.

Click Submit and make sure the workflow finishes successfully.

Repeat the Steps to include all Intermediate Certificate Authorities certificates from the certificate chain.

Instead of the vco workflow you can use the keytool –importcert command.

 

Import the CA certificates into the Windows certificate store

In order for the certificate to be trusted by windows, the CA certificates must also be installed into the Windows certificate store and tursted. IN our example I have 1-tier certificate authority (RootCA) and I have imported the CA certificate into the Local Computer’s Trusted Root Certificate Store.

If you have or have received certificate form multi-tier CA than import the CA certificate accordingly to the Local Computer Intermediate Certification Authorities Certificate Store.

 

Generate Certificate Request and Issue Certificate

Now we must generate a certificate request by using the private key of the existing self-signed certificate of vCO/vRO. The self-signed certificate has an alias name dunes. As I operate my own CA I will than issue a certificate from this certificate request.

Connect via SSH to the appliance via root and stop the vCO services by running

service vco-server stop

Run the following command to generate a certificate request:

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

You should see the certificate request file being 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.
Run 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 new certificate into the vCO SSL store

Now we can import the generated certificate into vCO. Copy the generated certificate to the vCO appliance.
Run the following command via SSH:

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

You should get a message “Certificate reply was installed in keystore”

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

keytool -list -keystore “/etc/vco/app-server/security/jssecacerts”

When asked for password enter: dunesdunes. You cna veirfy the certificate is present by comparing it’s thumprint.

Restart vCO and open the https:\\<vco_FQDN_name>:8283 page.
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.

 

 

 

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

 

Import the new certificate into vCO SSL Trust Store

Backup and rename or delete the jssecacerts keystore located in

etc/vco/app-server/security/jssecacerts

Copy the certificate packate you have (in this case PFX package) into the vCO appliance. I\ve use the /tmp folder

Fun the following command via SSH:

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

You should get similar output:

Entry for alias le-vmwarecertificate-d8129c1b-0523-44fb-9d3a-0cc726bc6ada successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or cancelled

The alias in this case is “le-vmwarecertificate-d8129c1b-0523-44fb-9d3a-0cc726bc6ada”. We need to change it to dunes. Do accomplish this run the following command via SSH:

# keytool -changealias -alias "le-vmwarecertificate-d8129c1b-0523-44fb-9d3a-0cc726bc6ada" -destalias "dunes" -keystore "/etc/vco/app-server/security/jssecacerts" -storetype jks -storepass dunesdunes

Change the owner of the keystore to vco. This is the defualt 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"

 

Import the vCenter certificate into vCO SSL Trust Store

As we have created a new keystore any certificates that were installed on the vCO before are now gone. This inlcudes the vCenter certificate and therefore the licencing might fail. Due to this you might not be able to logon to the vCO/vRO Appliance before you re-import the vCenter certificate. If you logon to the vCO/vRO Configuration page, under the Licenses tab you will see an error:

Error while validating configuration          Ssl certificate, ‘com.vmware.vim.vmomi.core.exception.CertificateValidationException: Server certificate chain not verified’

Restart vCO and open the https:\\<vco_FQDN_name>:8283 page.
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.

 

Known Issues and Errors: keytool error: java.io.IOException: failed to decrypt safe contents entry

You are running the following command:

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

You receive an error similar to the following:

keytool error: java.io.IOException: failed to decrypt safe contents entry: javax.crypto.BadPaddingException: Given final block not properly padded

Cause for this might be either mismatched password or corrupted keystore.Make sure to verify your password again before recreating the keystore. .

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 *