I would like to share my experience and findings when working with commercial certificates in vSphere 5.5. I’ve been working on a customer project where there is a requirement to replace the self-signed certificate of the Web Client with a commercial one. This particular project involved using a Verisign certificate.
I initially used the Certificate Automation Tool to generate the CSR (rui.csr) and the private key (rui.key). Oddly, Verisign is giving the Error 4824 below with the generated CSR:
The error points to the Subject Alternative Name (SAN) and specifically because there is a Shortname and Private IP in the SAN field of the CSR which Verisign does not allow. I remember when using the Certificate Automation Tool, the shortname and IP address are fields that must be populated. With the help of my colleague Frank Buechsel (http://fbuechsel.eu/), he recommended to generate the CSR’s manually using KB 2044696.
Following the KB article, I created an OpenSSL configuration file for the Web Client using the following format:
To remove the shortname and IP address, edit the subjectAltName and remove the ServerShortName and IP. It should look like this afterwards:
subjectAltName = DNS:server.domain.com
We can now generate the CSR using the modified configuration file. Following the same KB article, we generated the new CSR using the below commands (openssl is available inside the extracted Certificate Automation Tool):
After performing the above steps, we were able to successfully submit the CSR to Verisign.
After receiving the certificate in X.509 format, we are ready to install it using the Certificate Automation Tool. I renamed the certificate to rui.crt and attempted the replacement but encountered an error in the tool with a message that the chain cannot be validated. I then checked the downloaded certificate and saw that it does not contain the Intermediate CA in it. So it means that the tool won’t let you install the certificate if the chain to the intermediate CA is missing. We then proceeded to download the Intermediate certificate from Verisign and again referencing the same KB article, created the chain.pem file in order to have the certificate chain.
Using the Certificate Automation Tool with the new chain.pem file, the certificate replacement successfully went through.
To cut the long story short, the key takeaways when using commercial certificates are:
- Ensure that only FQDN is in the SAN field of the CSR else CSR submission will fail
- Once you receive the certificate from your commercial CA, verify that the chain to the intermediate CA is present before proceeding with replacement
rh5592dotcom 