Friday, December 18, 2015

Platform Services Controller Architectures Page created!

I have been meaning to do this for awhile now, but I have internally been maintaining a Platform Services Controller Architectures document that I wanted to share with everyone.  I have recently brought it online to a page on this blog.
Platform Services Controller Architectures
http://vmware.jmweb.ca/p/platform-services-controller.html

Definitely it is an effort by quite a few folks, not just myself.  I will be keeping this up to date as future versions of the products change and improve how this functions.  Hopefully you find it useful.

Monday, October 5, 2015

VMware Certificate Authority, Part 3: My Favorite New Feature of vSphere 6.0 – The New!

Repost from the VMware Consulting Blog!

https://blogs.vmware.com/consulting/2015/10/vmware-certificate-authority-part-3.html

--------

In the last blog, I left off right after the architecture discussion. To be honest, this was not because I wanted to but more because I couldn’t say anything more about it at the time. As of September 10, vSphere 6.0 Update 1 has been released with some fantastic new features in this area that make the configuration of customized certificates even easier. At this point what is shown is a tech preview, however it shows the direction that the development is headed in the future. It is amazing when things just work out and with a little bit of love, an incredibly complex area becomes much easier.

In this release, there is a UI that has been released for configuration of the Platform Services Controller. This new interface can be accessed by navigating to:

https://psc.domain.com/psc

When you first navigate here, a first time setup screen may be shown:



To set up the configuration, login with a Single Sign-On administrator account, and the actual setup will run and be complete in short order. Subsequently when you login, the screen is plain and similar to the login of the vSphere Web Client:


After login, the interface appears as follows:


As you can see, it provides a ton of new and great functionality, including a GUI for installation of certificates! I will not be talking about the other features except to say there is some pretty fantastic content in there, including the single sign-on configuration, as well as appliance-specific configurations. I only expect this to grow in the future, but it is definitely amazing for a first start.

Let’s dig in to the certificate stuff.

Certificate Store

When navigating to the Certificate Store link, it allows you to see all of the different certificate stores that exist on the VMware Certificate Authority System:


This gives the option to view the details of all the different stores that are on the system, as well as view details, and add or remove entry details of each of the entries available:


This is very useful when troubleshooting a configuration or for auditing/validating the different certificates that are trusted on the system.

Certificate Authority

Next up: the Certificate Authority option, which shows a view similar to the following:



This area shows the Active, Revoked, Expired and Root Certificate for the VMware Certificate Authority. It also provides the option to be able to show details of each certificate for auditing or review purposes:


In addition to providing a review, the Root Certificate Tab also allows the additional functionality of replacing the root certificate:


When you go here to do just that, you are prompted to input the new Certificate and Private Key:


Once processed the new certificate will show up in the list.

Certificate Management

Finally, and by far the most complex, is the Certificate Management screen. When you first click this, you will need to enter the single sign-on credentials for the server you want to connect to. In this case, it is to the local Platform Services Controller:


Once logged in the interface looks as follows:


Don’t worry, however, the user or server is not a one-time thing and can be changed by clicking the logout button. This interface allows the Machine Certificates and Solution User Certificates to be viewed, renewed and changed as appropriate.

If the renew button is clicked the certificate will be renewed from VMware Certificate Authority.


Once complete the following message is presented:


If the certificate is to be replaced it is similar to the process of replacing the root certificate:


Remember that the root certificate must be valid or replaced first or the installation will fail. Finally, the last screenshot I will show is the Solution Users Screen:


The notable difference here is that there is a Renew All button, which will allow for all the solution user certificates to be changed.

This new interface for certificates is the start of something amazing, and I can’t wait to see the continued development in the future. Although it is still a tech preview, from my own testing it seems to work very well. Of course my environment is a pretty clean one with little environmental complexity which can sometimes show some unexpected results.

For further details on the exact steps you should take to replace the certificates (including all of the command line steps, which are still available as per my last blog) see, Replacing default certificates with CA signed SSL certificates in vSphere 6.0 (2111219).

I hope this blog series has been useful to you it is definitely something I am passionate about so I can write about it for hours! I will be writing next about my experiences at VMworld and hopefully to help address the most common concerns I heard from customers while there.


Thursday, September 24, 2015

VMware Certificate Authority – My Favorite New Feature of vSphere 6.0 – Part 2 – The Architecture

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.

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.