I started deploying vRealize Automation SaltStack Config to check out its features by adding it to my existing vRealize Automation deployment, in vRealize Suite Lifecycle Manager.

Followed by selecting a certificate issued by the same Internal CA vRA is leveraging.

Then I ensured the slider to Integrate with Identity Manager was enabled.

After successfully deploying vRASSC from vRSLCM, integrated with vRA authentication, I was greeted by a friendly 403 error page.

Saltstack 403 forbidden

In checking the RaaS logs (/var/log/raas/raas) we observe SSL certificate verification failure messages. These are due to the certificate applied to vRA, being either self-signed or signed by an internal certificate authority (vRSLCM Locker, AD CA, etc)

To allow vRASSC to trust the certificate applied to the authentication provider (vRA), we need to first capture the root certificate, followed by appending it to /etc/pki/tls/certs/ca-bundle.crt, and restarting the RaaS service. This is noted in the docs under the “Troubleshooting SaltStack Config environments with vRealize Automation that use self-signed certificates” section.

• Troubleshooting SaltStack Config environments with vRealize Automation that use self-signed certificates

Step1, ssh to the vRASSC appliance, get the certificate from vRA and update the ca-bundle.crt file.

For example my vRA host is FQDN.Local Update this value in the following command to your vRA fqdn noted in the RaaS error logs.

root@vrassc [ ~ ]# echo -n | openssl s_client -connect vranode.fqdn:443 -showcerts | tac | sed -ne '1,/-BEGIN CERTIFICATE-/p' | tac | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | tee -a /etc/pki/tls/certs/ca-bundle.crt

After running the above command we can confirm our root certificate is added to the end of /etc/pki/tls/certs/ca-bundle.crt

In step 2 we need to add a line to the raas.service file, in a specific location, so we thought it be best to again script this portion.

root@vrassc [ ~ ]# sed -i.bak '/ExecStart\=/iEnvironment=REQUESTS_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crt' /usr/lib/systemd/system/raas.service

Now we have a raas.service.bak of the original and updated raas.service file in /usr/lib/systemd/system/.

With the root certificate of vRA added to a-bundle.crt, and the path set in raas.service, its time to restart the services and refresh the site to confirm resolution in step 3.

root@vrassc [ ~ ]# systemctl daemon-reload

root@vrassc [ ~ ]# systemctl stop raas

root@vrassc [ ~ ]# rm /var/log/raas/raas

root@vrassc [ ~ ]# systemctl start raas

root@vrassc [ ~ ]# tail -f /var/log/raas/raas

With all of these commands, we again think there is an easier way. So we have put together the commands with the following extensive “one-liner”

… just update the vRA host name from FQDN to your vRA fqdn in the beginning of the following command

root@vrassc [ ~ ]# echo -n | openssl s_client -connect VRA FQDN:443 -showcerts | tac | sed -ne '1,/-BEGIN CERTIFICATE-/p' | tac | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' | tee -a /etc/pki/tls/certs/ca-bundle.crt && sed -i.bak '/ExecStart\=/iEnvironment=REQUESTS_CA_BUNDLE=/etc/pki/tls/certs/ca-bundle.crt' /usr/lib/systemd/system/raas.service && systemctl daemon-reload && systemctl stop raas && rm /var/log/raas/raas && systemctl start raas && echo -e 'Starting RaaS Service and tailing the log to see if errors persist. \n Please Wait' && sleep 10 && echo -e 'Relaunch the web browser and navigate to the vRASSC login page and monitor this screen for further errors.\n CTRL+C to exit the tail' && tail -f /var/log/raas/raas