VMware vCenter's built-in CA (VMCA) should be able to run as a subordinate issuing CA under a CryptOS root, so the chain is CryptOS root, then an intermediate, then VMCA. VMCA keeps issuing the vSphere and ESXi certificates, but everything it issues now chains up to the enterprise CryptOS root instead of a self-signed VMCA root.
For this, CryptOS needs to accept a CA certificate signing request (VMCA generates one for itself) and issue a subordinate CA certificate for it. That certificate has to carry the right extensions: a BasicConstraints CA:TRUE with a pathLen that bounds the depth below it, KeyUsage of keyCertSign and cRLSign, and optionally NameConstraints to limit what the sub-CA may issue. CryptOS then returns the full chain so VMCA can be configured with itself, the intermediate, and the root.
On the operator side, we document the vCenter procedure: put VMCA into subordinate mode, generate its request, sign it with CryptOS, and install the chain that comes back.
This is a concrete driver for Phase-2 subordinate CA support. The config already reserves a pki.path_len_constraint field for issuing CAs, and Phase 1 only issues the root.
Not scheduled. CRL and OCSP for the issued sub-CA, and the exact pathLen and name-constraint policy, are still open.
VMware vCenter's built-in CA (VMCA) should be able to run as a subordinate issuing CA under a CryptOS root, so the chain is CryptOS root, then an intermediate, then VMCA. VMCA keeps issuing the vSphere and ESXi certificates, but everything it issues now chains up to the enterprise CryptOS root instead of a self-signed VMCA root.
For this, CryptOS needs to accept a CA certificate signing request (VMCA generates one for itself) and issue a subordinate CA certificate for it. That certificate has to carry the right extensions: a BasicConstraints CA:TRUE with a pathLen that bounds the depth below it, KeyUsage of keyCertSign and cRLSign, and optionally NameConstraints to limit what the sub-CA may issue. CryptOS then returns the full chain so VMCA can be configured with itself, the intermediate, and the root.
On the operator side, we document the vCenter procedure: put VMCA into subordinate mode, generate its request, sign it with CryptOS, and install the chain that comes back.
This is a concrete driver for Phase-2 subordinate CA support. The config already reserves a pki.path_len_constraint field for issuing CAs, and Phase 1 only issues the root.
Not scheduled. CRL and OCSP for the issued sub-CA, and the exact pathLen and name-constraint policy, are still open.