.png "jhanekom"){kind=avatar}
Not sure whether you’ve made progress since your post, but for what it’s worth here’s what I’ve been able to figure out.
I’ve replaced the “rui” certificates for Dump Collector, Syslog Collector and Auto Deploy using Derek Seaman and others’ techniques. I used unique OU names, but suspect most of them would work with generic names, as they don’t integrate with SSO (yet.) Autodeploy and Authentication Proxy are special cases. I'm still working on Authentication Proxy.
As for Autodeploy: Autodeploy comes with two SSL certificates, rbd-ca and rui.
From my experience, rui can be replaced in the same way other vCenter components are updated. It's used to render the (minimal) GUI with its Boot and Log download links, and to serve content when hosts boot. (Edit: you'll need to re-register Autodeploy with vCenter, see response later in this thread.)
rbd-ca is the CA certificate used to issue host certificates for hosts provisioned with autodeploy and thus has different properties for the “normal” rui-type certificates. Implementing a CA in this way allows vCenter to allocate a persistent certificate to stateless hosts on first boot; if each host auto-generated its own certificate on every boot, certificate validation would fail when vCenter attempts to reconnect to the host.
Host certificates issued by rbd-ca are stored in the Autodeploy SSL folder, with each host having a subfolder (e.g. host-28, host-143, etc.) under the SSL folder. On Windows, this is in C:\ProgramData\VMware\VMware vSphere Auto Deploy\ssl. This certificate is passed to each host every time it boots up.
The .srl file associated with the rbd-ca certificate in the SSL folder is just a serial number file. It can be left intact when replacing the CA certificate. Autodeploy automatically updates this file each time it issues a certificate, using it to ensure each certificate has a unique identifier.
To generate a new rbd-ca certificate, you will need to either create a new CA, or get your CA to issue a new subordinate CA certificate. I did it via an existing OpenSSL CA I use purely for my lab environment (“here’s one I prepared earlier”) so it was relatively straight-forward for me, but you will have difficulty doing this if you do not have direct control of the issuing CA. A subordinate CA that can issue its own certificates has significant security implications - particularly since the rbd-ca key is stored unencrypted in this case - so should not be done without proper consideration.
By no means a guide, but to point anyone doing this via OpenSSL in the general direction I followed to issue a suitable subordinate CA:
- Adjust your config to have the same basic constraints and key usage parameters for CA certificates as VMware’s cert. You can use the same config for user certs and CA certs, just specify different extensions when issuing the cert (example command line below.)
[ v3_ca ]
…
basicConstraints = CA:true,pathlen:0
…
keyUsage = keyCertSign
…
- Create a key and CSR, as you would for “normal” certificates:
OpenSSL genrsa 2048 -nodes -config %OpenSSL_Conf% > rbd-ca.key
OpenSSL req -out rbd-ca.csr -key rbd-ca.key -new -config %OpenSSL_Conf%
- Issue the certificate, specifying the v3_ca template: (I’m using a 10-year validity period here)
OpenSSL ca -config %OpenSSL_Conf% -days 3652 -extensions v3_ca -out rbd-ca.crt
My Autodeploy hosts in the lab are now issued automatically with certificates I trust 
No need for complex replacement procedures after-the-fact.
For the rui certificate, you would have used the same procedure but would have used usr_cert in stead of v3_ca in the command above. Also note that I already set the location for my CA inside the OpenSSL config, so none of that is passed on the command line in the examples above.
Ideally, after you’ve replaced the rbd-ca cert, you would trust the root CA (Windows: Trusted Root Certification Authorities) as well as the rbd-ca (Windows: Intermediate Certificate Authorities) on the clients where you’re accessing your vCenter and hosts from. This prevents the nasty certificate warning the GUI/browser presents.
Message was edited by: jhanekom (added note about Autodeploy re-registration when replacing rui)
