VMCA subordinate CA caveats

vSphere 6 comes with the VMware Certificate Authority service on the VCSA. It’s possible to configure this as a subordinate CA in the existing CA infrastructure.

We tested this configuration in our lab environment and ran into some issues with this configuration. As I don’t have any screenshots of the issues, I will try and explain them shortly.

*Updated with VSAN Health Check error*


Java: Certificate does not comply to algorithm constraints

First off, when we configured the VMCA as a subordinate CA and replaced all certificates of the PSC and vCenter it wasn’t any longer possible to connect vRealize Operations or Trend Micro Deep Security to the vCenter Server. Both products would give you an Java error complaining that the certificate did not comply to the algorithm constraints. After a lot of debugging we found the problem. Our Windows CA infrastructure uses the SHA256 algorithm with the option AlternateSignatureAlogritm=1. This option sets the algorithm to RSASSA-PSS.

vROPS and Deep Security do not work with this algorithm and will trow you an error. We have setup a second CA infrastructure but this time with the option AlternateSignatureAlogritm=0. The algorithm that is used now is SHA256. After re-configuring the VMCA as subordinate CA and replacing the PSC and vCenter certificates it was possible again to connect vROPS and Deep Security to the vCenter Server.


NSX Manager SSO Lookup Service: Failed to Register

After replacing the certificates we were not able to configure the NSX Manager to use the SSO Lookup service.

This happens because after replacing the certificates the corresponding service registration does not get updated in the lookup service. VMware does have a KB article explaining this and provides a solution in these articles if you use an External or Embedded PSC.

vCenter Server with External PSC


vCenter Server with Embedded PSC



NSX Manager Host preparation: Not Ready

After replacing the certificates and updating the lookup services with the instructions from the KB article above the host preparation tab would show the status “Not Ready” for the cluster.

This happens because the EAM service on the VCSA doesn’t recognize the new certificate. VMware does also have a KB article for this.



VSAN Health Check: Unexpected status code:400 

After replacing the certificates the VSAN Health Check Plugin wouldn’t run anymore with the error “Unexpected status code: 400”. I have had already encountered this once before so I knew how to fix this.

Not very surprising but VMware have a KB article for this.



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: