A repost from my latest consulting Blog!
-------
Picking up where Part 1 left off, in this part I discuss
the architecture decisions that I have seen commonly used for the VMware
Certificate Authority. This comes from
many conversations with customers, VMware Professional Services, VMware
Engineering and even VMware Support. In
addition to these sources I recently participated in many a conversation at
VMworld. I spoke at several sessions as
well as was manning the VMworld booth. I
ended up with the opportunity here to better appreciate the complexity, and
also got to talk with some fantastic people about their environments.
Architecture of the Environment
Getting back to the conversation, the architecture of the
environment becomes one that is incredibly important to design up front. This allows for an administrator to avoid
much of the complexity and allows for security to be kept. That being said, from my current experiences
I have seen three different ways that environments are the most frequently
being configured:
- VMware Certificate Authority as the root CA in the default configuration
- VMware Certificate Authority used but operating as a subordinate CA
- Hybrid model using custom Machine SSL Certificates, but using VMware Certificate Authority in its default configuration.
Before we get into them however keep in mind that as I
mentioned in my previous blog series regarding the architecture changes for
vSphere 6.0, there are two basic platform service controller architectures that
should be considered when designing your certificate infrastructure.
Be sure to note up front whether an external or embedded
Platform Services controller is to be used as this is important. The difference
being that a separate Machine SSL endpoint certificate would be required for
each system.
This means that on an embedded system a single certificate
is required as shown:
Or for an external environment 2 or more will be needed depending
on the size of the infrastructure. An
example is shown:
For further details on the different platform services
controller architectures, and to become familiar with them before proceeding,
see:
http://blogs.vmware.com/consulting/2015/03/vsphere-datacenter-design-vcenter-architecture-changes-vsphere-6-0-part-1.html.
http://blogs.vmware.com/consulting/2015/03/vsphere-datacenter-design-vcenter-architecture-changes-vsphere-6-0-part-1.html.
Using VMware Certificate Authority as the root CA in the default configuration
This is by far the most common configuration I have seen
deployed. Of course this is also the default which explains WHY this is the
case. Personally I fully support and recommend actually using this
configuration in almost all circumstances. The beauty of it is that it takes
very little configuration to be fully secured. Why change something if you do
not need to, right? By default, after
installation everything is already configured to use VMware Certificate
Authority and has already had certificates granted which are deployed to all
solutions and ESXi hosts which are added to vCenter Server.
In this situation the only thing that is required to
secure the environment is to download and install the root certificate (or
chain) from VMware Certificate Authority:
Note: When you
download this file in vSphere 6.0, it simply is called ‘download’. This a known issue in some browsers. It actually is a ZIP file which contains the
root certificate chain.
Once downloaded and extracted, the certificate(s) are the
file(s) ending in .0. To install simply
rename .0 to .cer and double click to import to the Windows certificate store. Repeat
the procedure for all certificates in the chain. The certificates should be
installed into the Local Machine’s Trusted
Root Certificate Authority or the Intermediate
Certificate Authority stores respectively.
If using Firefox, import to its proper store to ensure that the chain is
trusted.
The next time you go to the web page, it will show as
trusted:
This can potentially take some time if there are many
clients which need to have the certificate’s imported to them, however is the
easiest (and default) deployment model.
Using VMware Certificate Authority as a subordinate CA
This mode is less commonly used but it is the second
largest deployment type I have seen. This takes a bit of work but essentially
it allows for you to integrate VMware Certificate Authority into an existing
certificate infrastructure. The big benefit to this is that you will issue
completely signed certificates in the existing hierarchy, and in many cases no
installation of the certificate chain is required. The downside on the other hand is that you
will need a subordinate CA certificate to be able to implement the
configuration in this way. This in some cases that I have seen is simply not
allowed by policy. This is where the
hybrid configuration comes into play as discussed next.
To configure this it is done by a command line utility
called certificate-manager.
Once launched Option
2, is used to Replace VMCA Root Certificate with Custom Signing Certificate
and replace all Certificates. The first
part of the process is to generate the private key, and the certificate request
that will be submitted to the Certificate Authority. To do this, select Option 1:
Once generated, submit the request to the CA for issuance
of the certificate as well as collection of the root certificate chain. For
more details, see KB article Configuring
VMware vSphere 6.0 VMware Certificate Authority as a subordinate Certificate
Authority (2112016).
When the new certificate has been collected, it is a
matter of providing this new certificate as well as key, to the manager
utility. If the certificate-manager
screen is still open, select Option 1
to continue otherwise Select Option 2
and then Option 2 again. It will prompt to provide the details for the
certificate including all details for the certificate that is to be issued. Once
complete, services are stopped and restarted:
After this the Machine Certificate (aka the Reverse Proxy
certificate) can be regenerated from the VMware Certificate Authority for the
vCenter Server(s) that are in the environment.
This is done by selecting Option
3 from the menu:
This will prompt for a Single Sign-On administrator
password, as well as, the Platform Services Controller IP if the system is a
distributed installation. It will then prompt to enter the Information for the
certificate and restart the vCenter services. The server has its reverse proxy
certificate replaced at this point.
The next step is to replace the solution user
certificates. This can be done by
running Option 6 from certificate-manager:
This completes the configuration of the custom certificate
authority certificates for the vCenter components, but it is not quite done
yet.
The final step is to replace the ESXi host
certificates. This is done directly from
each host’s configuration in the Web Client.
The first step here is to set the details for the certificate in the
advanced settings for the vCenter Server:
When complete, navigate to an ESXi host and select, Manage > Certificates. On this screen, click Renew. This will regenerate
the certificate for this host:
In any case this is the most complex of the architectures
shown, but it also is the most environmentally integrated as well. It provides
an additional level of security that is required to satisfy compliance
regulatory requirements.
Using Hybrid Configurations for the Reverse Proxy but VMware Certificate Authority for all other certificates
Hybrid configurations are the middle ground in this
discussion. It is a balance between security and complexity and also satisfies
the security team in many cases as well.
The biggest issues that I have seen that require a configuration such as
this are:
- Granting or purchasing a Subordinate CA certificate is not possible due to policy or cost
- Issuing multiple certificates to the same server, one for each service is not something that can be done due to policy or regulatory requirements.
- Controls to approve or deny certificate requests are required.
In these cases although it may not be possible to fully integrate
VMware Certificate Authority into the existing CA Hierarchy it is possible to
still provide added levels of security. In this case it is possible to leave
VMware Certificate Authority in the default configuration, and only replace the
Machine certificate only. You can do
this by using Option 1 from the certificate Manager tool.
When configured the environment will use the corporate CA
certificate for external user facing communication because everything now goes
through the reverse proxy. On the other side of things the other components are
still secured by certificates from VMware Certificate Authority. The
configuration would look like this:
As you can clearly see, the architectures are varied and also
provide quite a bit of flexibility for the configuration.
Which method should be configured?
The only remaining question is that of what method is the
best to use. I said it in one of the
previous sections but my personal preference is actually use the keep it simple
methodology and use the default configuration. The reason for this is that it
is the simplest configuration, and the only requirement is that the root certificate
is installed on clients rather than custom certificates having to be
regenerated and then the configuration modified.
Obviously where policy or regulatory compliance is
concerned there may be a need to integrate it.
This, although more complex than doing nothing, is also something that
is much easier than in prior versions.
Hopefully all of this information has been of use to you
for consideration while designing or configuring your different vSphere
environments. As can be seen the
complexity has been dramatically reduced, and only promises to get better. For
now I stop however and simply say that I can’t wait for when I complete the
next part of this blog, which will give some details that will make all of this
even simpler.
