VMCA as a subordinate Certificate Authority

[Kesego]

Which certificates should be procured to enable a secure connection between a vCenter Server and local machines in an organization that already has a CA?

[Alex_Romeo]

Hi,

see:

• Make VMCA an Intermediate Certificate Authority (Certificate Manager)
• VMware Knowledge Base

ARomeo

[dvandelaar]

Hi,

Depends on what you want to do and the security level you want to be on. I believe that nowadays the most common use for vSphere, VMCA and Certificates is Hybrid Mode. This is a highly secure solution and pretty easy to implement. It basicly means that on the ' outside'  there are certificates signed by your company's CA. Normally this would be the FQDN('s) of your vCenter and if applicable the PSC('s). On the inside VMCA does it's thing and takes care of the hosts and all other certificates.

The above supersedes the ' VMCA as Subordinate'  method when it comes to security, also it doesn't require you to mess with the vmca root certificate.

So I would recommend the Hybrid approach and just replace certificates of your vcenter and psc's outside fqdn's.

There is some nice information on how this works and how to do this (walk-trough)

https://blogs.vmware.com/vsphere/2017/01/walkthrough-hybrid-ssl-certificate-replacement.html

https://featurewalkthrough.vmware.com/t/vsphere-6-5/ssl-certificate-replacement-hybrid-mode/1

Hope this helps or gets you in the right direction !

Kind regards

[Raudi]

Hello,

in my view the hybrid config makes no sense, because the VMCA root certificate must be instlled to the admin station too, for example to upload files to the datastore (hosts CA must be trusted). And if so, why should i replace the machine certificate? With installing the root certificate i have no error in my browser. The only reason can be to use a alternate name for hostname (without fqdn) and ip address, but starting with vSphere 7 this isn't working anymore, i can only use the FQDN to access the client.

So use the VMware default certificates, publish this root certificates to the admin clients manually or with a GPO or install the VMCA as a sub CA.

The following steps i have noticed to create a sub CA:

In the VCSA shell start this tool: /usr/lib/vmware-vmca/bin/certificate-manager

- Select option 2.

- Answer all questions, the information will be used to generate the certificate request for the SubCA and later a new machine certificate.

- Select option 1 to generate the certificate request.

- Use the file to request a certificate in your CA, how to create a template in a Microsoft CA is described here: https://kb.vmware.com/s/article/2112009

- Store the certificate on the VCSA and add the CA certificate to the file.

- If the Certificate Manager is still open continue with the option "1" and enter the full path to the certificate files.

- If the Certifikats Manager isn't started, start it again select again the option "2" and answer the question to modify the certool.cfg with "N". Then select option "2" to install the certificate.

 

All services will now e restarted.

Then renew the certificates of the hosts, it is possible that the parameter "vpxd.certmgmt.certs.minutesBefore" in the vCenter config must be set from 1440 to 10.

For rewnewing the certificates of a host, the host must not be in maintenance mode...

Stefan

[dvandelaar]

in my view the hybrid config makes no sense

Yeah, well, that's just your opinion man.

And that is fine, really. Every infrastructure has it's own needs and you should design it accordingly,

That being said, Hybrid mode is being recommended for quite a while now by VMware. Most importantly because the VMCA as subordinate method will make you vulnerable for a man in the middle attack. Something you do not want in a large enterprise. In Hybrid mode the hosts are still signed with a certificate, yes, from the VMCA! The only thing is, they don't show up in your browser as trusted when you connect to the host directly. Is that a problem? When you know it is a VMCA signed certificate you are going to trust when you click the proceed button? I don't think so.In my opinion you should not have to connect directly to your hosts that often anyways.

In vSphere 7 Hybrid is also the recommended method, together with the fully automated one and the subordinate way is explicitly not recommended. And again, if your organization has a need for doing it that way, that is fine. However, Hybrid mode does make sense for most (large) enterprises and organizations.

vSphere 7 - Certificate Management - VMware vSphere Blog

https://mysticmarvin.eu/vsphere-7-part-2-certificate-management/

Not sure if this will change your view on certificates, but i needed to explain this a little further,

kind regards

[Raudi]

When using a hybrid installation, the machine certificate is a certificate from a trusted company CA, but the VMCA isn't, so the hosts are not trusted. I agree, it is no problem when connecting directly to the hosts but:

Please try to upload a file to a datastore.

It will fail, because the host has a certificate which isn't trusted by the browser, even when you upload the file from the vCenter Client.

The solution is to install the root CA certificate from the VMCA to the client.

And when i now have installed the root VMCA certificate to my client, i have no security warnings in the browser when using the original VMCA machine certificate. Why should i replace the machine certificate with a custom certificate?

[dvandelaar]

Hi,

Let me first say, I do not want to dismiss your solution or the way you are working. Every organization has it's own needs and best practices. As long as you are aware of the pros, cons and alternatives I think you make the best decision out of weighing them.

As you requested I just did a test uploading a file to a local datastore on the esxi host. In that case, you are right. It will fail with a message that the certificate is not trusted. To fix this I open the UI of the esxi host and accept the 'untrusted' certificate. After that it works fine. Don't forget, the certificate is signed ans communications are encrypted! It is signed by the vmca and I see no reason why not to trust it? Unless you don't trust vmware that is.

When you have lots of hosts it might be some work to manually trust the certificates by opening their respective UI's, on the other hand, most larger organizations won't use the local datastores to copy data to. .

Personally I would always prefer Hybrid mode compared to making my vmca a subordinate and acting as a company root with risks of man in the middle attacks. The articles I included describe pretty well why you should not do this (anymore).

Also, if your company does require the subordinate method, or that method works best for you..I am not here to say you shouldn't do this. I merely reacted on the fact that you said that hybrid mode makes no sense, which is not true, because it does.

[Raudi]

I'm a not a english native speaking person, so excuse me if i choose not perfect terms.

But i really don't understand why i should use the hybride mode compared with the fully automated mode? Ignore the sub CA configuration for this question...

In the blog you included they wrote "vSphere Admins import VMCA root for ..." when using the hybrid config.

If i have done this and using the FQDN all is trusted and working fine, there is no need to replace certificates.

O.k. only if there is a company policy that all admin web pages should be use certificates from the company CA, to use revoke lists etc. Perhaps in this environment may be a hybrid config the best way... As you wrote:

Every organization has it's own needs and best practices. As long as you are aware of the pros, cons and alternatives.

[Raudi]

Do i understand this right, the risk in the "Sub CA" is only that the key is stored on the VCSA during certificate request and this key can be used to use for man-in-the-middle attacks, if the key isn't deleted after importing?

So the risk isn't the Sub CA, the risk is the process of creating the Sub CA. Correct?

[dvandelaar]

Hi,

Yes, for sure. That is partly true. Also there might be an issue with ' rogue'  administrators possibly having access all the way up to your company's root CA.

This is from the blog that convinced me to go Hybrid a few years ago:

From a security perspective, by having a Subordinate CA, a rogue administrator with full access to the PSC could mint fully trusted and valid certificates that are trusted all the way up to the organization’s Root CA. In talking with our customers, many of them who operate in a highly security conscious manner, this type of risk is a deal breaker for the Security teams in those organizations.

https://blogs.vmware.com/vsphere/2017/01/walkthrough-hybrid-ssl-certificate-replacement.html

And ofcourse it is possible to go for fully automated, nothing wrong with that, but in the original question it is not clear which vsphere version we are talking about and what the environment looks like.

I cannot say which method would work best, it just depends on the version of vsphere, level of security needed, company wishes etc. Hybrid mode in many cases comes out as best of both worlds though, hence my initial advice..but that doesn't mean it always suits your needs or company wishes.

This discussion really made me look into certificates again though :smileyhappy: which is always a good thing !

[Raudi]

This discussion really made me look into certificates again though :smileyhappy: which is always a good thing !

This it true! :smileyhappy:

[Raudi]

Hmm...

I looked on my VCSA, the certificate and key is stored in the file-system, not in a protected certificate store, so all users with shell access should be a secure password, because they cann access the files. And be careful which person will be grant shell access.

And more important, the "backup"! The certificate files are in this archive, must be... But if there is no encryption password configured, the certificate can be extracted by everyone who has access to the backup files.