Save to My DOJO
In this blog post, we will go through the steps needed to create the certificate request and how to replace the signed certificate on the SRM Manager servers. Note that you will need OpenSSL to create the certificate request.
Replacing certificates is part of the work when managing an IT environment. Most products don’t generally require installing certificates signed by a trusted CA (Certificate Authority), but rather offer a quicker route by leveraging self-signed certificates, Site Recovery Manager (SRM) included. However, installing custom certificates is usually regarded as the best practice to increase security in the infrastructure.
VMware‘s disaster recovery solution SRM works with a management server in each of the protected and recovery sites that pair and connect to the vCenter servers. The SRM server certificate establishes the identity and secures the communication between SRM servers and clients.
Creation of the Certificate
-
Browse to your OpenSSL directory and create a config file like the following and change the fields specific to your environment (in red in the example cfg file below). In this example, I save it as “srm1.cfg“.
Note that you can put the server’s IP in the certificate but it is not required if you work with DNS names (which everyone should do).
In the “SubjectAltName” put the names the server is referred to (usually FQDN and short name).
If you look in openssl.cfg you will find more fields to populate in the last part (Country, city, email…).
[ req ] default_bits = 2048 default_keyfile = mg-p-srm11.key 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: mg-p-srm11.mgmtdom.intra, DNS:mg-p-srm11 [ req_distinguished_name ] O.organizationName = GROLAND organizationalUnitName = GRO commonName = srm1 |
-
Open an elevated command prompt and browse to the OpenSSL directory once again and generate the certificate request using the config file.
Openssl req -new -nodes -out srm1.csr -keyout srm1-orig.key -config srm1.cfg |
-
Convert the generated private key to RSA format.
Openssl rsa -in srm1-orig.key -out srm1.key |
-
Provide your certificate authority with the certificate request (.csr file) to sign the certificate.
(Note: consult this guide if you are signing it with a Microsoft CA and encounter an error regarding a missing template.
-
Once you have received the certificate from your CA, convert it to PKCS12 with the RSA private key, which is required by the SRM installer.
We will need OpenSSL one last time to do this operation. The signed certificate is named “srm1.cer” and the PKCS12 “srm1.p12” in this example.
Openssl pkcs12 -export -in srm1.cer -inkey srm1.key -name “xav-win-srm” -passout pass:Password123 -out srm1.p12 |
Replacement of the certificate in Site Recovery Manager
-
Open the “Uninstall or change a program” wizard On the SRM Manager server, select “VMware vCenter Site Recovery Manager” and click “Change“.
If you encounter an error due to UAC being enabled, follow this procedure.
-
Go to Start > Run, type regedit and click OK. The Registry Editor window opens.
-
Navigate to HKEY_LOCAL_MACHINE > SOFTWARE > Microsoft > Windows > CurrentVersion > policies > system.
-
Modify DWORD EnableLUA from 1 to 0.
-
Restart the Windows machine and run the modify installation.
-
Select the “Modify” option.
3. Type in the credentials of the service account connecting to vCenter. The Username is pre-populated.
-
Not much to do here except click “Next“.
-
In this pane, the “Local Host” is pre-populated with the IP address of the server. This field should be one of the SANs of the certificate (Subject Alternative Names).
This means that if the IP is not present in the SANs of your certificate, change these fields to the FQDN of the SRM server.
-
Select “Use a PKCS#12 certificate file” in the next pane.
-
Browse to the .p12 file and type the password you chose when converting it in OpenSSL. It was “Password123″ in my example.
-
Type the password of the user that connects to the database.
-
Leave the next pane alone unless you want to change the account under which the SRM service runs.
-
Finish the wizard and click “Install“.
-
It should complete successfully. If it doesn’t you will need to review the installation logs.
-
Once the wizard is closed, you can verify that the replacement has been done correctly in a web browser on the port 9086 of the SRM server with HTTPS.
Open the certificate presented and ensure it is the new one.
SRM site pairing connection
Now if you look at the SRM plugin after replacing the certificate on the protected site (xav-win-vc in the example below), you will see that the recovery site (xav-win-vc2 below) is disconnected.
-
Then replace the certificate of the recovery site (xav-win-vc2) by following the same procedure as before. You will notice that it is now the protected site that is disconnected (xav-win-vc).
-
To fix it, open the Site Recovery Manager plug-in in vCenter, go to “Sites” and click on “Reconfigure Pairing“.
-
The remote site of the one selected is pre-populated. Click “Next” here.
-
Type the password of the account used for the pairing.
You will notice a task “Repair Connection” which should succeed.
-
Ensure that both protected and recovery sites are now in the green “Connected” state.
The SRM Manager certificates are now successfully replaced.
Wrap up
Although not being the most attractive part of the job as a SysAdmin, certificate management is critical to ensure compliance with security policies of the company. It is also very important that customers have a way to closely monitor the expiry date of all the certificates installed in their environments. Whether it is handled manually by a crypto team or by a monitoring tool like Zabbix or Nagios, there should be alarms configured to warn the infrastructure team in advance (2 months is a safe margin). To monitor the SSL certificates of Site Recovery Manager, you can run SSL checks on port 9086 of each server as seen earlier in this blog.
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!