VCF 9 - Certificate exchange

Certificates – the mother of all evils

In the last 25 years of working in IT, I have never met anyone who is happy when certificates expire and need to be replaced – quite the opposite, in fact. Certificates are like printers: everyone hates them, but we need them. Fortunately, VCF and VCF9 have greatly simplified the entire procedure. In this article, I would like to briefly explain how you can use VCF Operations and a Microsoft CA to exchange certificates easily and, in some cases, automatically – guaranteed pain-free. However, it is still not an enjoyable process.

Let’s get started

VCF (VCF9) currently supports two integrations of certificate authorities. It supports Microsoft CA or OpenSSL. Since I already have a Windows domain running, I simply use Microsoft CA for the sake of simplicity. Nevertheless, the completely manual method is also supported, which I will show at the end of this article.

I will use the Microsoft Certification Authority Web Enrollment Service. If you want to use fully automated certificate enrolment with a microsoft CA, there is no way around this. Please note that the web service requires basic authentication and generally poses a security risk if everything is not configured correctly.

Preparing the RootCA

The following server roles must be enabled on the CA:

• Certification Authority
• Certification Authority Web Enrollment

After installing the roles, Basic Authentication must be enabled in IIS.

Next, a dedicated certificate template must be created. This template defines the attributes used to sign the VCF component certificates. To do this, I start the Certificate Templates console by running certtmpl.msc. I duplicate the default template Web Server.

In the new template, adjust the compatibility settings so that Windows Server 2008 R2 is specified as the certification authority and Windows 7 / Server 2008 R2 as the certificate recipient. Give the template a unique name, e.g. VMware.

Remove ‘Server authentication’ from the application policies under Extensions, enable the ‘Basic Constraints‘ extension, and in the key usage settings, enable ‘Signature is proof of origin (non-repudiation)’ while keeping the default settings for the rest. On the Subject Name tab, make sure that ’Supply in the request’ is selected. Save the new template once all settings have been applied.

Finally, add the template to the Microsoft certification authority. To do this, open ‘certsrv.msc’, go to ‘Certificate Templates’ and select ‘New → Certificate Template to Issue’. Select the template you just created and activate it.

The final step is to assign the rights. The CA user requires the following rights:

• Issue and Manage Certificates
• Request Certificates

This completes the process on the Windows side. The CA can now be used either manually or automatically via VCF Operations.

Preparing VCF Operations

The cool thing is that you can now not only change VCF certificates, but also, if you use a central VCF operations like I do, you can also change these certificates.

This is also practical, as I can store different CAs per VCF instance in VCF Operations. Perhaps I will write a second article in which I do the whole thing via OpenSSL CA. To set the CA for a VCF, go to Fleet Management -> Certificates and then select the VCF instance or VCF Management, depending on whether it is to be configured for the management components or the VCF instance.

The settings are self-explanatory. It is important that the complete username with domain is used and that the template is written correctly (case sensitive). For the CA server URL, https is recommended, as basic authentication is used, which means that the user and password are transmitted in plain text. Therefore, as a minimum security measure, transport encryption with TLS should be used here.

Request certificate

In my case, I want to replace the vCenter certificate in my workload domain. To do this, I select my workload domain in VCF Operations, click on the component that is to receive a new certificate, and select Generate CSR.

The Generate CSR dialogue box appears and some information must be added. The Common Name, Host and Subject Alternative Name (SAN) are pre-filled and should not be changed. The following fields must be completed or modified:

• Organisation
• Organisation Unit
• Country
• State/Province
• Locality
• Key Size

Once saved, a new certificate request is created in the background. The private key remains on the server that created it. You can download the request if a manual signing request is used or required. This would be the case if you do not want to use the Microsoft Certification Authority Web Enrollment Service for security reasons or if you do not use either Microsoft or OpenSSL CA.

Once the certificate request has been successfully created, all you need to do is select Replace With Configured CA Certificate and the automatic enrolment process will start.

The SDDC now takes care of all further steps. A new certificate is automatically requested from the CA, signed and then exchanged on the relevant system. Depending on the system, the process takes a few minutes, so it’s best to go and make a cup of coffee while you wait, as you can’t do anything else at this point.

And (e)voilà, here is our beautiful new certificate (sorry for the bad pun about my employer evoila). The cool thing is that certificate renewal can now be done with a simple button press. No more filling out annoying requests or interacting with the CA. One button press, a cup of coffee, a little wait, and the job is done – that’s how I like it.

But Daniel, you wanted to show us how to do it manually!

Extra - the manual way

It all starts as before with a request. To ensure that the certificate can be easily exchanged with VCF Operations, the request must be executed via Operations and then simply downloaded via the GUI.

With the request, I now create a certificate at my CA and save it as Base 64 encoded. I now have to import the certificate, together with the the CA certificate. To do this, the certificate must be PEM encoded. Alternatively, the certificate can also be imported as a certificate chain encoded in Base64. VCF Operations supports both options.

Server Certificate

-----BEGIN CERTIFICATE-----
MIIDdzCCAl+gAwIBAgIEbmh8+TANBgkq...
...dein Server/Leaf-Zertifikat...
-----END CERTIFICATE-----

Root Certificate

-----BEGIN CERTIFICATE-----
MIIFQTCCAymgAwIBAgISA9pL1W...
...Intermediate CA Zertifikat...
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
MIIDrzCCApegAwIBAgIQCDvgVpF3...
...Root CA Zertifikat (optional)...
-----END CERTIFICATE-----

Once the certificate has been successfully imported, it can now be assigned. To do this, select the certificate in VCF Operations that is to be replaced and click on the button Replace with imported certificate.

VCF Operations suggests the certificate. If this does not work, you must select the correct certificate from the drop-down menu. In my case, it worked and the correct certificate was selected. Push replace and go to the coffee machine.

Conclusion

Certificates will still be a pain in the neck in 2025, but VCF Operations has made the process much, much easier. The ability to easily exchange certificates for both management components and the components of my VCF instances is brilliant. Unfortunately, there is still no nice built-in feature that allows me to do this on Microsoft without the Web Enrollment Service.

The fact that I can automatically renew my certificates with a single button is also something that makes the whole process much easier for me. Many of the things just shown were already possible in older VCF versions, but now that everything is centralised in VCF Operations and works for all my VCF instances, it’s just great. I will take a look at enrolment with an OpenSSL CA when I have time, but for now I am focusing on the Microsoft CA, as it is really widespread in practice and I am more familiar with the Windows CA than with the OpenSSL CA.

Maybe one more thing: It is also possible to exchange the certificates of the ESX servers. You just have to activate the Show ESX Hosts slider.

Now that you’ve read this far, how painful is certificate exchange for you, and how much coffee have you had? Feel free to let me know on LinkedIn.