- Introduction
- Lab Environment
- Scenario 1: Use vCO Dunes Private Key for your new certificate
- Scenario 2: Use Custom Private Key with your new certificate
- Known Issues and Errors
Introduction
In this post we will take a look into the certificate replacement process for vCenter Orchestrator (vCO)/vRealize Orchestrator (vRO) installed on Windows. As basis we will be using the great post by Burke Azbill (Work with vCO over SSL)from the vCO Team. Also special thanks to Nick Jacques on figuring out some of the content. In this example we will show how to install third party certificate In order to work with vCO 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 vCO/vRO Appliance, check this blog post: How to change the SSL certificate of a vCO Appliance
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:
<vCO install folder>\jre\bin\keytool.exe
<vCO install folder>\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.
Stop both vCO services
Open a command line and run:
cd “C:\Program Files\VMware\Orchestrator\Uninstall_vCenter Orchestrator\uninstall-jre\bin”
keytool.exe –certreq –alias dunes –keypass dunesdunes –keystore “C:\Program Files\VMware\Orchestrator\app-server\conf\security\jssecacerts” –file C:\myCertRequest.csr
When asked for password enter: 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.
Open a command line and run:
cd “C:\Program Files\VMware\Orchestrator\Uninstall_vCenter Orchestrator\uninstall-jre\bin”
Keytool.exe –importcert –alias dunes –keypass “dunesdunes” –file C:\MyCert.crt –keystore “C:\Program Files\VMware\Orchestrator\app-server\conf\security\jssecacerts”
When asked for password enter: 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:
C:\Program Files\VMware\Orchestrator\Uninstall_vCenter Orchestrator\uninstall-jre\bin>keytool -list -keystore “C:\Program Files\VMware\Orchestrator\app-server\conf\security\jssecacerts”
When asked for password enter: dunesdunes.
Restart vCO and open the https:\\<vco_FQDN_name>:8281 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 vCO and CA certificates into the Windows certificate store
If your company has it’s own certificate authority you might leverage a workflow package that might streamline and speedup the certificate generation process for all your VMware certificates. This can be found here: vCO Workflow to automate the certificate generation process
In this example we have a package with containing our certificate with private key and all of the CA’s certificates included. This mean we only need to import this package into the windows certificate store and the CA’s certificates will be installed also. I have received the CA’s certificates separately you need to install them manually in addition to the new vCO/vRO certificate.
First you need to import the certificate package you have into the local computer store, into the Personal store.
Open the certificate and select Local Machine.
Type the password you have received from your certificate vendor.
Make sure the Mark this key as exportable and include all extended properties checkboxes have been marked. We will be needing the private key to be exportable as we will export the certificate and use it in vCO/vRO.
Select the Place all certificates in the following store option.
Select the Show physical stores checkbox and navigate to the Personal store.
Import the certificate.
Verify it has been imported in the Local Computer Personal store.
Create a PFX certificate package
Now we are going to export the certificate together with the private key and all of the CA’s certificates into a single PFX certificate package.
Export the certificate which you will be using importing into vCO/vRO .
Select Yes, export private key when asked.
Make sure the Include all certificates in the certification path if possible and Export all extended properties checkboxes have been selected.
For a password type: dunesdunes
Now we have the PFX certificate package we can import into the vco keystore
Import the new certificate into vCO SSL Trust Store
Backup/rename the jssecacerts keystore located in
C:\Program Files\VMware\Orchestrator\app-server\conf\security\
Run the following command to import the certificate.
C:\Program Files\VMware\Orchestrator\Uninstall_vCenter Orchestrator\uninstall-jre\bin>keytool -importkeystore -srckeystore C:\lan2dc1.vmware.com\rui.pfx -srcstoretype pkcs12 -srcstorepass dunesdunes -deststoretype jks -destkeystore “C:\Program Files\VMware\Orchestrator\app-server\conf\security\jssecacerts” -deststorepass dunesdunes
You should get similar output:
Entry for alias {dd30e294-d56f-4d73-aaf6-1de620a70efb} successfully imported.
Import command completed: 1 entries successfully imported, 0 entries failed or
Cancelled
Note the alias listed or use the following command to find out the alias for the keystore:
C:\Program Files\VMware\Orchestrator\Uninstall_vCenter Orchestrator\uninstall-jre\bin>keytool -list -keystore “C:\Program Files\VMware\Orchestrator\app-server\conf\security\jssecacerts” -storetype jks -storepass dunesdunes
You should get similar output:
Keystore type: JKS
Keystore provider: SUN
Your keystore contains 1 entry
{dd30e294-d56f-4d73-aaf6-1de620a70efb}, Nov 20, 2014, PrivateKeyEntry,
Certificate fingerprint (SHA1): 56:63:75:F5:ED:91:C3:B6:6F:65:25:2E:47:D7:AA:84:
54:A8:76:98
The alias in this case is “{dd30e294-d56f-4d73-aaf6-1de620a70efb}”. We need to change it to dunes. Do accomplish this run the following command:
C:\Program Files\VMware\Orchestrator\Uninstall_vCenter Orchestrator\uninstall-jre\bin>keytool -changealias -alias “{dd30e294-d56f-4d73-aaf6-1de620a70efb}” -destalias “dunes” -keystore “C:\Program Files\VMware\Orchestrator\app-server\conf\security\jssecacerts”-storetype jks -storepass dunesdunes
Restart vCO and open the https:\\<vco_FQDN_name>:8281 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.