Adding secure, signed certificates to a vSphere environment is something that a lot of administrators don't bother...
to do. It is easy enough to click accept on that nontrusted, self-signed certificate warning.
Best practice states that a vSphere environment should have properly signed certificates from a known certificate authority (CA) or an enterprise CA. There are several ways to implement certificates in a vSphere environment; each has benefits and drawbacks.
VSphere 6 includes several new services, including VMware Certificate Authority (VMCA) which manages the certificates. VMCA manages certificates for several components, including vSphere Web Client, ESXi hosts and vSphere management agents that run on the host, such as VPXD.
Essentially, VMCA functions as a reverse proxy for Secure Socket Layer (SSL) authentication, and you can use that one certificate across the board, as is done out of the box.
In conjunction with VMCA, there is a new item called VMware Endpoint Certificate Store (VECS). VECS's purpose is to function as a secure local repository -- a strongbox -- for generated certificates and keys. VECS runs on every Platform Service Controller and management node within the environment.
In short, there are four potential ways to use certificate authorities: with the VMCA self-signed root certificate, with the subordinate VMCA certificate, with enterprise certificates and with customer setup.
VMCA self-signed root certificate
We have already discussed VMCA self-signed certificates. This is the least complex way to implement a certificate -- and the least secure.
Setup is trivial and easily managed. You can fix the untrusted domain issue by opening the vCenter webpage and clicking the button on the right that says Download trusted root certificates.
Download the file and rename it to add .zip to the end. Then, open the zip file and install the root certificates -- the ones ending in r0 and r1 -- onto your browser or certificate store. This will depend on which browser you are using. In a larger environment, you could apply these using a group policy.
You can replace the out-of-the-box certificates with new ones, if you so choose.
Subordinate VMCA certificate
Setting up the environment to use a subordinate certificate authority removes the burden of an administrator having to issue certificates to all of the various components in the estate. The subordinate VMCA certificate server setup will automatically manage all the certificates in the VMware infrastructure on behalf of the administrator. This will essentially mint a new certificate every time you need one.
In a VMware environment, the intermediate certificate alongside the VMCA service functions as an intermediate certificate creation and signing authority. The certificate differs from a standard, run-of-the-mill SSL certificate and must be configured to function with intermediate CA.
The exact configuration steps will vary from implementation setup to setup. For ease of use, I, along with most people that have done this, recommend using a Windows-based CA. It's better suited for amateurs and will automatically create certificates as needed.
External certificates require some additional configuration. Each and every server must have its own bespoke certificates, signing requests and so on created, submitted and replaced. It's a lot of work, but is useful in highly secure environments.
A custom setup is only for administrators who really have nothing better to do with their time or need a super secure environment. Custom setups allow administrators to manage every single certificate the infrastructure requires manually, including hosts, services and other dependencies.
This isn't so bad for a small three-node cluster, but when you ramp up to hundreds of servers, it gets a little -- or rather, a lot -- more problematic. I know of no one using this solution, though highly secure environments may mandate it. As a side note, the certificate items will still be stored in the VECS strongbox, but you must manage them manually. You can't bypass VECS when using certificates in any configuration.
In summary, vSphere 6 made the actual job of replacing certificates dramatically easier by introducing a menu-driven, script-based application that allows administrators to create signing requests and certificates. This is in stark contrast to ESXi 5 -- and, to some degree, 5.5 -- which had administrators running away in terror. VMware offers the exact implementation details around certificate creation on their website.
Though not exactly trivial, an administrator really should set up the environment to be secure from the outset. Not only does it make the environment more secure, it also looks a lot more professional.
Avoid common SSL certificate management mistakes
AWS releases new SSL certificate tool
Do subscriptions simplify SSL certificate management?
Take these steps to boost VMware vSphere security