For a small lab or test environment is a full CA setup far too much effort. So, I have decided to create a new root and intermediate CA with XCA and request a CA signed vCenter Certificate from XCA. The requested certificate should be used to replace the vCenter default Machine SSL certificate.
Requirements for all imported vCenter 6.7 certificates:
- Key size: 2048 bits or more (PEM encoded)
- PEM format. VMware supports PKCS8 and PKCS1 (RSA keys). When you add keys to VECS, they are converted to PKCS8.
- x509 version 3
- SubjectAltName must contain DNS Name=machine_FQDN
- CRT format
- Contains the following Key Usages: Digital Signature, Key Encipherment.
- Enhanced Key Usage can be either empty or contain Server Authentication.
Source: Certificate Requirements for Different Solution Paths
# Create Root-CA with XCA
With a new XCA database is the first step of this process the creation of the new Root-CA certificate (if you use an existing CA, you can import the certificates to use XCA “only” for the handling of the server certificates). To create a new certificate switch to the “Certificates” ribbon and choose “New Certificate”.
XCA has a default template for CAs. The template has the necessary key usage parameters preconfigured.
After you have filled out everything, a new key for the Root-CA can be generated.
If you have no other unhandled private keys in your XCA database, this key will automatically be chosen.
All other default setting from the CA template worked fine for me.
With these settings we can now create the new Root-CA certificate.
# Create Intermediate-CA with XCA
The usage of an Intermediate-CA does from security perspective not make sense with this setup. I have done this to simulate the real-world scenario where a two-tier CA makes sense.
With XCA you are able to create pretty fast similar cetificates.
Just a few settings need to be modified for the Intermediate-CA certificate. The first one is, that the Intermediate-CA certificate needs to signed by the Root-CA.
After updating the Internal and Common Name, deselect the “Used keys too” checkbox and generate a new private key for the Intermediate-CA.
With those settings we can now create the new Intermediate-CA certificate signed by the Root-CA.
XCA stores in addition to the generated certificates also their private keys in the database. Please keep in mind that private keys are confidential data!
# Request CA signed vCenter Certificate from XCA
As we have created a proper two-tier CA we can now request the CA signed vCenter Certificate from XCA. The new vCenter Machine SSL certificate needs to be signed by the Intermediate-CA.
The “Similar certificate” process can also be used to create the Server certificate, but a few more modifications are required in this case. The most important step is applying (“Apply extensions”) the template for HTTP Servers.
After updating the Internal and Common Name, deselect the “Used keys too” checkbox and generate a new private key for the Server certificate.
In the ribbon Extension, you can optionally extend the validity to two years. All common browsers are at the moment fine with that.
XCA automatically copies the Common Name (CN) of the certificate into the Subject Alternate Name (SAN) field of the certificate. Using the vCenter FQDN as SAN is not only a VMware requirement. Some common browsers use the SAN to match the certificate:
For Chrome 58 and later, only the subjectAlternativeName extension, not commonName, is used to match the domain name and site certificate.
If you need to add, for example an IP address as additional SAN, use the Edit button.
With those settings we can now create the new Server certificate signed by the Intermediate-CA.
# Import CA signed vCenter Certificate
One of the most awsome feature in XCA this wide range of export capabilities. The fist thing we need to export is the CA Chain.
The exported Chain needs to imported as Trusted Root into the vCenter Certificate Management.
For the replacement of the vCenter Machine SSL Certificate two files need to be exported from XCA: Certificate Chain and Private Key
After that, both files can be imported during the Machine SSL Certificate replacement wizard of the vCenter Certificate Management.
After a final reboot of the vCenter Appliance, the VAMI Interface, the vSphere HTML5 Client and the vSphere FLEX Client are exposing the new CA signed vCenter Certificate from XCA (actually, the reverse proxy service certificate was replaced). To make the Machine SSL certificate trusted you just need to deploy the CA Certificate as Trusted Root Certification Authority to your servers and clients (e.g via GPO). Be aware that some browsers, like Mozilla on Windows, have their own Trust store.