I had a project recently to deploy a three node highly available vROPs 6.4 solution. This included the master node, a master replica and a remote collector situated in a different datacenter. Due to security requirements it was necessary to replace the default self-signed certificates with a trusted certificate signed by an internal CA. I hadn’t had cause to do this before with vROPs, so thought I’d go through the process I followed here.
When deployed, each vROPs node has its own self-signed cert created, and is trusted by the other nodes when it is joined to an existing vROPs cluster. The self-signed certificates are different on each node, and have a ‘common name’ that relates to the order in which the node was added to the cluster. The master node’s cert will have a ‘common name’ of ‘vc-ops-slice-1’. The next node to be joined will have a certificate with the common name set to ‘vc-ops-slice-2’ and so on:
Issuer Distinguished Name: OU=MBU,O=VMware\, Inc.,CN=vc-ops-cluster-ca_c7edd330-6697-4df8-be04-c9cfdc6f22da Subject Distinguished Name: OU=MBU,O=VMware\, Inc.,CN=vc-ops-slice-2 Subject Alternate Name: localhost,127.0.0.1 PublicKey Algorithm: RSA
When you replace the default certificates with your own signed certificate, the certificate you use is copied to all the nodes in the vROPs cluster. Due to this, it’s necessary to include all your node names in the certificate request, so that you don’t get a certificate trust error in the browser when you go to each individual node. This is important if you are placing your vROPs cluster behind a load balancer in order to load balance web traffic to the vROPs nodes. When doing so, you would use the load balanced name as the subject name, and the node names as subject alternate names when crafting the certificate request.
The overall process for creating the CSR is documented in this VMware KB article. The first step is to create a new private key:
vrops1:~ # openssl genrsa -out vrops.key 2048
Next we would run the command to generate the CSR, however, when following this process the content of the csr is created interactively, which doesn’t give the opportunity to specify the SAN names. E.g:
vrops1:~ # openssl req -new -key vrops-new-key.key -out certificate_request-test.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:
So, instead, when running the command to generate the private key and then the CSR we need to supply a configuration file, which includes all the information required to generate the CSR for the cluster. Before we can run the command, we need to create the config file. The contents of the one I used for my test cluster looks like this:
distinguished_name = req_distinguished_name encrypt_key = no prompt = no string_mask = nombstr req_extensions = v3_req [ v3_req ] basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment, dataEncipherment extendedKeyUsage = serverAuth, clientAuth subjectAltName = DNS:VROPS.VROPS.LOCAL, IP:192.168.5.25, DNS:VROPS, DNS:VROPS1.VROPS.LOCAL, IP:192.168.5.20, DNS:VROPS1, DNS:VROPS2.VROPS.LOCAL, IP:192.168.5.21, DNS:VROPS2, DNS:VROPS3.VROPS.LOCAL, IP:192.168.5.22, DNS:VROPS3 [ req_distinguished_name ] countryName = US stateOrProvinceName = CALIFORNIA localityName = CAL 0.organizationName = VROPS organizationalUnitName = VROPSORG commonName = VROPS.VROPS.LOCAL
In the last section we specify the details that you would normally input interactively, such as the commonName (which is the name I will use on the load balancer), the countryName and the Org name.
In the v3_req section above, I have included the host name, fqdn and IP address of each of my vROPs nodes (there are 3) along with the load balanced name and vip. This ensures that the certificate generated by this CSR will be valid on all my vROPs nodes, and on my load balancer.
With the configuration file in place we can run the command to generate the .csr file, which makes use of the config file and the private key generated earlier:
openssl req -new -key vrops.key -out vrops.csr -config vrops.cfg
The resultant .csr file can then be submitted to your certificate authority in order to generate the certificate. Once you have the certificate, it will need to be combined with the private key and the CA certificate chain in order to generate a PEM file. The process for doing this is described here.
Applying a new certificate to vRealize Operations Manager
Once you have the necessary .pem file, it can be uploaded and applied to the vROPs cluster. To do so, log into the admin URL of your master vROPs node, then click the certificate icon:
The window will display the current certificate. Click on ‘Install New Certificate’ button, then browse to the .pem file that you have created:
If the .pem passes the validation checks you should see a green tick, informing you the certificate is ready to install. Click install. Once done, log out of the admin portal, the open the UI interface – “https://fqdm/ui/login.action”. The browser should show that the certificate is valid and that the connection is secure:
The connection should also be secure and without errors if you point the browser to any of the vROPs nodes. E.g:
Replacing Custom vROPs Certificates with Default Certificates
Should there be any issues after implementing custom certificates, there is a process available for reverting back to the default certificates, which is described here.