Replacing the vRealize Automation 7.3 IaaS Manager Service Certificate
Certificates VMware vRealize Automation vRealize Orchestrator
Published on 11 December 2017 by Christopher Lewis. Words: 466. Reading Time: 3 mins.
This is the third in a series of posts covering the replacement of vRealize Automation SSL Certificates. In this post, we will tackle replacing the vRealize Automation IaaS Manager Service Certificate.
This post is based on the VMware procedure and this is documented here .
Prerequisites
The following are expected prerequisites for this walkthrough:
- A fully deployed and working vRealize Automation solution.
- A set of certificate files:
- The RSA Private Key used to encrypt the vRA IaaS Manager certificate.
- The Root CA Certificate file.
- The vRA IaaS Manager Certificate file.
- The Root CA Certificate and any Subordinate/Intermediate CA Certificates are installed within the appropriate Certificate store on the local machine (normally the Trusted Root Certification Authorities and the Intermediate Certification Authority respectively).
Identifying the “Issue”
If you log into any vRA IaaS DEM or Agent server and navigate to https://vra7-man.fqdn/VMPS
you will see the screen below:
As you will see, the certificate is the** self-signed SSL certificate** generated as part of the install that has no trusted Certification Path.
Let us go through the steps to fix that!
Replacing the Infrastructure as a Service Manager Certificate
Navigate to the vRealize Automation Appliances Virtual Appliance Management Infrastructure (VAMI) interface, https://vra.fqdn:5480
.
Log into the VAMI by typing the User Name and Password configured during the install wizard and clicking Login.
Note: By default, the username is always root.
Under vRA Settings, click Certificates.
Under Component Type, select the Manager Service option.
Under IaaS Web Certificate, select the Import Certificate option.
Open the RSA Private Key in a text editor and copy and paste the information into the RSA Private Key field.
Note: You should include the -----BEGIN RSA PRIVATE KEY-----
and -----END RSA PRIVATE KEY-----
text.
Open the Certificate and the Root Certificate file in a text editor and copy and paste the information into the Certificate Chain text field.
Note: You should include the -----BEGIN CERTIFICATE-----
and -----END CERTIFICATE-----
text for each certificate.
Note: The client SSL certificate should be first, then any intermediate CA certificates, followed by the Root CA certificate.
If required, enter the Passphrase into the text field.
Under Actions, click Save Settings.
Note: The process of replacing the certificates may take some time, so go grab a beverage!
(If required) Copy/Upload the vRealize Automation IaaS Manager Service certificate to the Manager Service load balancer configuration.
Verify the new SSL Certificate
No, if you log into any of the vRealize Automation IaaS DEM or Agent servers and navigate to https://vra7-man.fqdn/VMPS
you will see the screen below:
If you view the SSL certificate, you can see that it as been replaced with the certificate that has a certification path back to the Trusted Enterprise CA certificate! #JobDone
Next Step(s)
In the next post, we’ll look at the process for refreshing the embedded vRealize Orchestrator certificate.
Published on 11 December 2017 by Christopher Lewis. Words: 466. Reading Time: 3 mins.
- Replacing the vRealize Automation 7.3 IaaS Web Certificate ()
- Replacing SSL Certificates in vRealize Automation 7.3 ()
- Replacing the vRealize Automation 7.3 Appliance Certificate ()
- Replacing the Control Center Certificate on an embedded vRO instance ()
- Replacing the Package Signing Certificate in vRO 7 ()
- Operating a Private Cloud - Part 3: Creating a Pricing Card in VMware Aria Automation
- Operating a Private Cloud - Part 2: Creating a Pricing Card in VMware Aria Operations
- Operating a Private Cloud - Part 1: Understanding Pricing Cards in VMware Aria
- Zero2Hero - Using Aria Automation to Deploy Multiple Machines with Multiple Disks - Part 5
- Zero2Hero - Using Aria Automation to Deploy Multiple Machines with Multiple Disks - Part 4