vRA 8.10.1 load balanced 3 node cluster using F5 Big-IP LTM as load balanced VIP. Purchased trusted certificate authority verified Wildcard certificate for client certificate and local ADCA generated server certificate.
I thought I found a cute way to bypass certificate issues for L4-L7 inspection on the F5 for vRA. I use a trusted provider wildcard certificate on the F5, and re-encrypt via server policy certificates to the back-end vra appliance cluster. But I found an issue where it wasn't picking up the embedded vRO saying that it was shutdown and there was an issue with data collection.
com.vmware.automation.vro.exceptions.VroServiceException: 9100010: Data collection
[cec9b45d-1917-46d8-a65b-7a518dd82f4d] failed. Could not retrieve workflow list from
I could verify authentication to vRO and save, but still no dice on getting it working. And because data collection was failing, Cloud Assembly had no workflows listed under extensibility.
I could still navigate and access Orchestrator in the Cloud Service Console. Troubleshooting in the logs, I found where the system was "designed" to grab the certificates and try to verify via DNS certificate names and alternate names. The wildcard certificate uses subject name local.domain and alternate name *.local.domain. local.domain doesn't resolve to same IP as vRA-LB.local.domain and *.local.domain doesn't resolve.
Adding the server certificate and key to the F5, I can create a client SSL policy. Removing the wildcard client certificate and using the server client certificate seems to have resolved the issue.
But does anyone know how I can go back to using the Trusted Root Authority wildcard certificate for the client side?
Damion Terrell . + (He/Him) + . * . + @ + . * . + .
Core IT Service Specialist * . + * . + . + . + * +
UNM – IT Platforms – VIS + . . . . . . . . .
. + . + * . + * .
* . . + . . . . + . + * + .
“You learn the job of the person above you, * + . + * @
and you teach your job to the person below you..” . * +