After setting up a fresh VMware vCenter Server the vSphere Client and the web services like SOAP and REST APIs are served by a self signed TLS/SSL certificate which was generate by the installer. This makes their consumption cumbersome for every client application. The certificate must be accepted manually as the signing root authority is not know to the client application. The chain of trust is broken.
In this article I will describe a way to setup a widely accepted certificate for the vCenter Server services.
We will leverate a certificate signed by Let’s Encrypt. Which is a non-profit certifcate authority run by the Internet Security Research Group. The service can sign your Certificate Signing Requests CSR free of charge and fully automated with the ACME protocol. Several ready to use client implementations exists and make the certificate consumption convenient. One downside of this service the short lifespan for each certifcate of three months.
Tool of choice - certbot
We’ll use certbot which is one of the most powerfull client implementation for letsencrypt. The Python source code is hosted on github. The tool supports the most common public DNS providers and applications by a plugin system which makes it the right tool for many TLS services found on the internet. A complete list can be found with the official certbot documentation.
Setup DNS-1 challenge
Assuming the vCenter Server is not public available from the internet we have to validate the ownership of the domain we want to get a certificate for with the DNS-01 challange method.
Acquire TLS/SSL server certificate
Transform files
Files generated by letsencrypt are Base64 encoded DER certificates. Content of the .pem files can be viewed with this openssl command:
openss x509 -noout -text -in cert.pem
This will show up details like common name, expiration date and issuer.
| Certbot File | Content | Description | Target File |
|---|---|---|---|
| cert.pem | Server x509 Certificate | Let’s Encrypt signed public key. Will be used for vCenter Services. | cert.pem |
| privkey.pem | Server private key | Private key for vCenter Services. | privkey.pem |
| chain.pem | Root and intermediate certificates from Let’s Encrypt | Peel out the direct signing instance for cert.pem. This was the ‘‘R3’’ certificate in time of writing this article. | intermediate.pem |
IMPORTANT Replacing certificates with a .pem file containing a chain or multiple certificates will fail. intermediate.pem must contain only one single certificate from Let’s encrypt.
Push cert to vCenter Server
Unfortenately VMware did not provide a application module for certbot. Therefore we’ll have to inject it with VMwares own tool certificate-manager. The procedure is called ‘‘Replace Machine SSL Certificate with Custom Certificate Using the Certificate Manager’’ by VMware.
- SSH to vCenter Server
- Switch to Shell
- Start certificate manager:
/usr/lib/vmware-vmca/bin/certificate-manager
- Choose the first procedure: Replace Machine SSL certificate with Custom Certificate
- Login with the SSO domain administrator: e.g. administrator@vsphere.local
- Choose the second option: Import custom certificate(s) and key(s) to replace existing Machine SSL certificate
- Please provide valid custom certificate for Machine SSL.: cert.pem
- Please provide valid custom key for Machine SSL.: privkey.pem
- *Please provide the signing certificate of the Machine SSL certificate’: intermediate.pem
- Continue operation : Option[Y/N] ? : Y
WARNING After confirming the operation Certificate Manager will restart the vCenter services. This happens in both cases : Success and Fail.
Cross fingers and check if the tool runs smoothly. Certificate Manage will create a backup before making any changes to the existing certificates. If validation of the given files fails it will automatically roll back.