The WEI engineering team thrives on solving our customer's toughest technology challenges. Often times these challenges are the first of their kind--meaning there are no google searches that will lead to a solution, the forums haven't covered it yet and the vendor/supplier teams are racking their brains to solve the unique challenge. Several of our customers are at the bleeding edge of enterprise technology, and we work with them closely to test new concepts and approaches; and in turn we document the newly discovered best practices first-hand. This blog post shares one of those stories.
Managing certificates with Platform Service Controllers
There are several options managing certificates with the Platform Service Controllers (PSC). You can use the default which makes the PSC a standalone CA, you can use hybrid which the PSC is still the stand alone CA but you replace the user facing certificate with one trusted by your enterprise CA, or you can make the PSC a subordinate CA to your enterprise CA. VMware recommends the hybrid approach for several reasons, the main one being subordinate CAs are not more secure.
We recently had a customer who wanted to take advantage of vSphere vCenter 6.5 high availability options, as well as, make the PSC a subordinate CA. On the vCenter level this is pretty straight forward as you just need to create a heartbeat network and supply heartbeat VLAN addresses to the vCenter, the mirror and the witness VM. When it came time to plan out the external Platform Service Controller (PSC) we started to see possible issues.
During planning of the architecture of the environment it became clear we would need two external PSCs to handle the failover because the HA vCenter would be in another facility. We started to research solutions and it quickly became apparent not many people were talking about making PSCs that were subordinate CAs highly available, so we had to test this on our own.
The good news is—yes, it’s possible—but as already stated, not recommended. In this customer's case there was no negotiation with the security team and self-signed certificates. The bad news? It can be fairly difficult to get working and we found it fairly temperamental.
The Solution
The broad steps to make it work were to use the certificate wizard to make the PSC subordinate CAs. This replaces the three main certificates the PSC uses; machine, machine_ssl, and the web client. Then we ran the wizard again to just replace the machine_ssl certificate so it had the subject alternate names of both PSCs and the virtual interface of the load balancer. The machine_ssl is the external facing certificate you want to replace if you just want to do the hybrid approach. You can then run the HA scripts on the PSC and install vCenter by pointing to the virtual IP on the load balancer.
Even after performing all these steps we would run into issues. The majority of the time vCenter would install correctly, but Single Sign On would error out so we couldn’t log in. We spent a lot of time reviewing time services, DNS settings, and certificate creation with no success. In working with VMware it seems that the HA scripts may be causing an issue. The way we got around this was to run the certificate wizard again on the PSC and import the same exact certificate again.
In the end, for most single site environments using plain old VMware HA will probably suffice, but in metro cluster setups with vCenter HA enabled it can get more complicated very quickly. If you are experiencing a similiar situation, or are hitting a roadbloack, contact us over here at WEI. We want to solve your toughest technology challenges.
>> Do you have a question for WEI's VMware experts? Contact us today.
