For a small
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
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

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

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.
https://support.google.com/chrome/a/answer/7391219?hl=en
If you need to add, for

With those

Import CA signed vCenter Certificate
One of the most


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
thanks for the how-to. finally my lab has some valid certificates 🙂