vRA 7.x Certificate Replacement Process
vRA 7.x Certificate Replacement Process
Certificate for component "website" on node "<node name>" will expire on <date>
Certificate for component "ManagerService" on node "<node name>" will expire on <date>
Seeing the above message in your vRA vami interface, that means its time to replace your vRA ssl certificates.
This post will cover the vRA 7.x cert replacement process. Certificate Management in vRA 7.x has been simplified and is all performed from the Certificates tab of the VAMI interface:
https:<vRAFQDN>:5480 -> vRA -> Certificates
A distributed vRA will have three main certificate components:
- vRA cert itself
- IaaS web certificate
- IaaS manager certificate
!! In a simple install with a single IaaS web server the Manager and Web component will share the same certificate!!
You have two options when choosing a certificate:
- Self-signed certificate generated by vRA itself
- Certificate Authority Signed certificate
When using CA signed certificates you can have vRA generate the certificate Signing Request(CSR file) or you can create your own.
Important to note here that the generation of the CA certificate is not the responsibility of VMware it is between you and your chosen Certificate Authority. VMware is only responsible for the replacement operation to ensure vRA components correctly present this new certificate chain.
!! When having vRA generate the CSR file the private key is already stored on the vRA appliance, so this field can be left Blank when importing the end product certificate chain!!
Checklist before replacing
To ensure the certificate replacement operation goes smoothly it's best to validate the below points ahead of time.
- IaaS Node Last Connected Status, the iaas management agents are the main component responsible for propagating the certificate replacement. So it's vital to ensure these are performing as expected prior to attempting the cert change. The easiest method to validate this is to examine the Last connected status of each of the IaaS nodes under the cluster tab of the VAMI interface. These should all show a last connected time of under < 2 minutes:
If any of the IaaS nodes do not report a recent last connected time then follow troubleshooting steps in below post to resolve the issue before proceeding
vRealize Automation 7 Management Agents Explained - Embedded Postgres certificate validity, sadly a timebomb still exists for this
component which will be exactly 5 years since deployment. SSH to vRA
appliance & below command will tell you the expiry date, if expired
you can follow steps in KB85904 to resolve.
openssl x509 -enddate -noout -in /storage/db/root.crt - Backups, Snapshot vRA appliances , IaaS windows nodes & take a manual backup of the vRA IaaS MS SQL Database before attempting a certificate replacement operation.Replacing the Certificates
!! Certificate replacement does require downtime so arrange for a maintenance window, 2 hours should suffice!!
The certificates should be replaced in the order in which components are shown in the Component Type radio button:- vRA appliance Cert
- IaaS Web Cert
- IaaS Manager Cert
The process itself is simple:- Login to the VAMI interface
- Navigate to certificate tab
- Select the component type
- Select Generate Certificate(for self signed) or Import (for CA signed)
- For CA signed you need to paste in the cert chain info , for self-signed just select Save Settings button, a progress wheel is then displayed
Afterwards a successful task list should display below notifying that the IaaS Windows servers have successfully been notified of the new vRA certificate:
Process is same for IaaS web and Manager certificates these will display similar list of certificate replacement tasks in the bottom pane of VAMI UI
Once certs are replaced ensure to follow the process to update the Embedded vRO or External vRO with new vRA certificates.
Also, login to vRO client and run the 'Update a vRA host' and 'Update and IaaS host' configuration workflows selecting the option to automatically trust SSL certificate. That is of course if you don't want your integrations to fail with SSL related errorsIf it goes wrong...
It shouldn't if checklist above has been validated however if it does the VAMI UI should give feedback in relation to which step has failed and why. You can also check the below logfiles for more information.- Management Agent logs:
C:\Program Files (x86)\VMware\vCAC\Management Agent\Logs\All.log
- vRA appliance logs:
/var/log/VMware/vCAC/vcac-config.log
You also have backups taken step 3 of checklist to restore to in the event of any issues.
Any questions or suggestions for future content drop a comment below
Comments
Post a Comment