In this recipe, we will have a closer look at the SSL certificate of the Orchestrator server.
You need a running Orchestrator server.
If you are intending to use an SSL certificate signed by a Certificate Authority (CA), you need to be able to sign a certificate request. You also need the CA root certificate, as well as any intermediate certificate, so that you can import it into the Orchestrator SSL store.
If you are creating a clustered vRO, please see the recipe Load-balancing Orchestrator in Chapter 3, Distributed Design first.
There are basically two kinds of certificates we can use, self-signed or CA-signed.
When you installed vRO, a self-signed certificate has been created, but you are free to create a new one containing your details:
- Open the Orchestrator Control Center.
- Click on Certificates and select Orchestrator Server SSL Certificate.
- You will then see the current certificate.
- Click on Generate to generate a new self-signed certificate.
- As the First and last names, you have to enter the FQDN of the server name. The Country code is a two-letter code:
DE= Germany,AU=Australia. - Click again on Generate and then reboot the appliance.
After the reboot, your Orchestrator should show the new certificate when connecting.
This creates a PEM file using the VMCA (VMware Certificate Authority) that is part of the PSC (Platform Controller Service). Consider to create a snapshot of Orchestrator before trying this out:
- Open an SSH connection to your PSC (or to vCenter if your PSC is installed with vCenter).
- Create a configuration file,
/tmp/vro.conf, with content similar to this:Country = DE Name= vro Organization = vLeet GmbH OrgUnit = Consulting State = Bayern Locality = Munich IPAddress = 192.168.220.12 Email = [email protected] Hostname = vro.mylab.local
- Run the following commands to generate a certificate using VMCA:
cd /usr/lib/vmware-vmca/bin/ ./certool --genkey --privkey=/tmp/vro.prikey --pubkey=/tmp/vro.pubkey ./certool --gencert --privkey=/tmp/vro.prikey --cert=/tmp/vro.cert --config /tmp/vro.conf - Download the VMCA root certificate:
cd /tmp wget https://127.0.0.1/certs/download --no-check-certificate -O /tmp/vmca.zip unzip vmca.zip - Select the correct VMCA root certificate. If your vCenter is not a CA sub authority, the correct file is
6bc2e122.0, or else it should be the second one with the .0 ending. Copy the file to/tmp:cp certs/6bc2e122.0 vmcaroot.cert
- Build the
.pemfile:awk 1 vro.prikey vro.cert vmcaroot.cert >vro.pem
- Use SCP to download the
.pemfile and then use the next section to import the.pemfile.
A CA-signed certificate can be imported using a PEM encoded file, see the How it works... section.
- Open the Orchestrator Control Center, click on Certificates and select Orchestrator Server SSL Certificate.
- You will then see the current certificate.
- Click on Import and select the
.pemfile to import. If you secured the file with a password, enter it also. - Click on Import again and then reboot the appliance.
After the reboot, your Orchestrator should show the new certificate when connecting.
Orchestrator uses an Apache web server that is installed along with Orchestrator. The SSL certificate is stored within the Java environment of the Orchestrator installation. The SSL certificate we discuss here is the certificate that Orchestrator uses to communicate with other instances, such as the Orchestrator Client or other programs.
vRO 7 made some changes to its certificates encryption. MD2 and RSA must have a minimum length of 1024 bit. In vRO7.1, an additional change was introduced:
- In Cluster mode, the nodes exchange certificate information, which leads to the fact that all nodes share the same certificate. This requires you to use SAN certificates in the Cluster mode. Also, see the recipe Building an Orchestrator cluster in Chapter 3, Distributed Design.
- Plugins now need to use the plug-in SDK to retrieve a certificate.
For rounded information about all the Orchestrator certificates that exist, see Spas's post:
http://kaloferov.com/blog/orchestrator-certificates-explained/
The question now is which certificate should we use, the default SSL certificate, a self-signed certificate, or a CA-signed certificate?
The main difference between the default and the self-signed certificates is that the self-signed certificate is issued with the correct FQDN of the Orchestrator server, and therefore, is more secure than the default certificate.
A CA-signed certificate has the advantage as it is automatically accepted by all hosts that trust the CA. This makes large deployments easier to manage as well as comply with the security demands of your company.
The VMCA is an integrated part of vSphere 6 and creates a CA that signs and publishes all ESXi and solution user certificates. The cool thing is that if you have used your own enterprise CA to make the VMCA a Subordinate Certificate Authority ( kb.vmware.com/kb/2111219 ) then your CA trusts your VMCA and VMCA trusts vRO.
If you don't have a CA, you can export the VMCA root certificate and import it into your trusted root certificates on your computer, which automatically results that the certificates for vCenter and all ESXi server URLS are trusted. (see http://blogs.vmware.com/vsphere/2015/03/vmware-certificate-authority-overview-using-vmca-root-certificates-browser.html ).
PEM encoded files are a one-stop shop and the new way forward in regards to certificates. They combine not only a signed certificate, but also the certificate's private key, the root certificate, and any intermediate certificates. Orchestrator, as well as vRealize Operations Manager, now uses this method. The structure is as follows:
-----BEGIN PRIVATE KEY----- (Your Primary SSL certificate: PrivateKey.key) -----END PRIVATE KEY----- -----BEGIN CERTIFICATE----- (Your Primary SSL certificate: Server.crt) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Your Intermediate certificate: Intermediate.crt) -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- (Your Root certificate: TrustedRoot.crt) -----END CERTIFICATE-----
The - - - - , as well as the headers are important and should not be changed. Also, make sure that you copy the header and footer notes of the certificate.
Next to using the PEM integration of the Control Center you can also use the old method shown here.
Security has improved as the password of the SSL keystore isn't dunesdunes anymore. It is now generated when you start the appliance and is stored in /var/lib/vco/keystore.password. As we need that password, let's save it into a bash variable and also create one for the SSL store:
STOREPASS=`cat /var/lib/vco/keystore.password` STORE="/etc/vco/app-server/security/jssecacerts"
First of all, we need to back up the default certificate that comes with Orchestrator:
- Log in to the Orchestrator appliance via SSH as
root. - Stop the Orchestrator service.
- Make a copy of the existing SSL store:
cp $STORE $STORE.bak
We will now create the new self-signed certificate and then create a request from it to get it signed by the CA making it a CA-signed certificate. After this we will import the signed certificate. The alias for the Orchestrator certificates is still dunes and refers to the original name of the company that created Orchestrator before it was bought by VMware. Follow these steps to create a certificate and request:
- First, we need to delete the existing certificate:
keytool -keystore $STORE -storepass $STOREPASS -alias dunes -delete
- We will now create the certificate:
keytool -keystore $STORE -storepass $STOREPASS -alias dunes -keypass $STOREPASS -keyalg RSA -sigalg SHA512withRSA -keysize 2048 -genkey
- As the First and last names, you have to enter the FQDN of the server name. The Country code is a two-letter code:
DE= Germany,AU=Australia. - Fill in the rest of the required information. When asked for a password, just press Enter.
- Generate a new certificate-signing request (CSR) with the following command:
keytool -keystore $STORE -storepass $STOREPASS -alias dunes -keypass $STOREPASS -certreq -sigalg SHA512withRSA -file /tmp/cert.csr
This is an alternative method to the preceding one, and you can use it for an Orchestrator cluster and if you are using not only FQDNS but IPs (only in Labs please). For more details, see the recipe Load-balancing Orchestrator in Chapter 3, Distributed Design.
Replace the content of dname and SAN with your DNS names and/or IPs:
keytool -keystore $STORE -storepass $STOREPASS -alias dunes -keypass $STOREPASS -genkey -keyalg RSA -sigalg SHA512withRSA -keysize 2048 -dname "CN=vro1.mylab.local, OU=consulting, O=vLeet GmbH, L=Munich, ST=Bayern, C=DE" -ext SAN="ip:192.168.220.20,dns:vro2.mylab.local,ip:192.168.220.21"
- Have the certificate request signed by your CA. Export the CA root as well as any intermediate certificates.
- Import the CA's root certificate into the keystore:
keytool -keystore $STORE -storepass $STOREPASS -alias root -import -file [root file certificate] - Import the CA-signed certificate into the keystore:
keytool -keystore $STORE -storepass $STOREPASS -alias dunes -import -keypass $STOREPASS -sigalg SHA256withRSA -file [file name].crt - Reboot the appliance.
Your CA-signed certificate is now imported into Orchestrator.
Create a Microsoft CA VMware template: