As a vSphere user and administrator, I want to access the vSphere UI and API with widely trusted certificates (i.e. not obtaining/trust a CA first) so that the system can be used and managed by any authorized users without forcing Trust On First Use behavior that adds friction to the user experience.

*It is difficult to add third-party signed certificates to VCSA. There seems to be some unresolved issue with the certificate chains causing the certs to fail to be rolled over properly when the machine cert is provided and the certificate chain of intermediate and root CA is provided for the signing key.

When the initial self-signed certificate is replaced, the process will fail if there is not a common Subject Alternative Name (SAN) on the self-signed certificate and the third-party signed certificate. This makes it difficult to initially provision VCSA with an IP hostname and later add DNS support.
ESXi seem to replace it's certificate with certificates issued by vSphere when joined to the system. This behavior causes the ESXi to overwrite issued valid Let's Encrypt signed certificates with self-signed certificates issues by the VCSA.
VCSA does not trust the root certificate of Let's Encrypt implicitly. Among other things, this means the machine certificate for VCSA that would present the end user with valid certs cannot be rotated to a Let's Encrypt certificate until the root CA for Let's Encrypt has been trusted. A code sample of how to accomplish this is listed below.
```
#Trust the certificate
/usr/lib/vmware-vmafd/bin/dir-cli trustedcert publish --chain --cert /root/DARootCAX3.pem
```
Automating the certificate rotation on a newly deployed system is difficult to do via the CLI because you are not initially presented with a bash shell. Rather, you are presented with a shell that allows you to select a shell and must change the shell after logging in. This also prevents utilities such as SCP from functioning as intended as they require shell functionality that the default VCSA shell does not provide
```
#Enter bash shell
shell
```

Reset shell to root

chsh -s /bin/bash root


* The only automatable way to change the VCSA machine certificate seems to be a TUI provided by `/usr/lib/vmware-vmca/bin/certificate-manager`.  This would require use of a tool such as `pexpect` to automate answers.
* Allowing default self-signed certificates requires not only the vSphere UI to be trusted, but also the ESXi UI to be trusted as things like datastore uploads via the GUI will fail due to trust issues otherwise.  

Some potential solutions:
1. Run a reverse proxy that trust the certificate authority managed by VCSA.  VCSA seems to want to own the certificate process not only for itself, but also for ESXi hosts that it manages.  This means that even rotating the certificate on the VCSA server would require additional effort to maintain the ESXi host certificates properly.  Given that we can expect entire systems (ESXi + vSphere) to regularly be created and die for the purposes of hosting infrastructure that is cleanly provisioned from code end to end, a widely trusted certificate on the proxy (such as one from Let's Encrypt) could be used to proxy with reencryption to the actual endpoint via a certificate that the proxy and VCSA/ESXi hosts share trust on.  This would require automating the proxy and the hosts, but not all the clients.

In general, this seems be a thorny problem for a fairly simple end user experience desire.

redhat-cop / disconnectedinfra

Add valid certificates generated from Let's Encrypt on vSphere #1

Reset shell to root