Featured image of post CA signed vCenter Certificate from XCA

CA signed vCenter Certificate from XCA

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”.

CA signed vCenter Certificate from XCA - New Root-Ca

XCA has a default template for CAs. The template has the necessary key usage parameters preconfigured.

CA signed vCenter Certificate from XCA - Root-CA Subject

After you have filled out everything, a new key for the Root-CA can be generated.

CA signed vCenter Certificate from XCA - Generate Root-CA Key

If you have no other unhandled private keys in your XCA database, this key will automatically be chosen.

CA signed vCenter Certificate from XCA - Use new Root-CA Key

All other default setting from the CA template worked fine for me.

CA signed vCenter Certificate from XCA - Root-CA Extensions

CA signed vCenter Certificate from XCA - Root-CA Key Usage

With these settings we can now create the new Root-CA certificate.

CA signed vCenter Certificate from XCA - Final Root-CA

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.

CA signed vCenter Certificate from XCA - New Intermediate-CA

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.

CA signed vCenter Certificate from XCA - Intermediate-CA signing

After updating the Internal and Common Name, deselect the “Used keys too” checkbox and generate a new private key for the Intermediate-CA.

CA signed vCenter Certificate from XCA - Intermediate-CA Subject and Key

With those settings we can now create the new Intermediate-CA certificate signed by the Root-CA.

CA signed vCenter Certificate from XCA - Intermediate-CA Result

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!

CA signed vCenter Certificate from XCA - CA Private Keys

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.

CA signed vCenter Certificate from XCA - Server Certificate signing and Template

After updating the Internal and Common Name, deselect the “Used keys too” checkbox and generate a new private key for the Server certificate.

CA signed vCenter Certificate from XCA - Server Certificate Subject and Key

In the ribbon Extension, you can optionally extend the validity to two years. All common browsers are at the moment fine with that.

CA signed vCenter Certificate from XCA - Server Certificate Extension and Validity

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.

https://support.google.com/chrome/a/answer/7391219?hl=en

If you need to add, for example an IP address as additional SAN, use the Edit button.

CA signed vCenter Certificate from XCA - Server Certificate SAN

With those settings we can now create the new Server certificate signed by the Intermediate-CA.

CA signed vCenter Certificate from XCA - Server Certificate Result

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.

CA signed vCenter Certificate from XCA - CA Chain Export

CA signed vCenter Certificate from XCA - CA Chain Export Format

The exported Chain needs to imported as Trusted Root into the vCenter Certificate Management.

CA signed vCenter Certificate from XCA - CA Chain Import

For the replacement of the vCenter Machine SSL Certificate two files need to be exported from XCA: Certificate Chain and Private Key

CA signed vCenter Certificate from XCA - Server Certificate Export

CA signed vCenter Certificate from XCA - Server Certificate Provate Key Export

After that, both files can be imported during the Machine SSL Certificate replacement wizard of the vCenter Certificate Management.

CA signed vCenter Certificate from XCA - vCenter Machine SSL Certificate replacement

CA signed vCenter Certificate from XCA - vCenter Machine SSL Certificate replacement wizard

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.

Built with Hugo
Theme Stack designed by Jimmy