Rapid Recovery self-signed certificates versus signed public third-party certificates (4036097)

Rapid Recovery self-signed certificates versus signed public third-party certificates

Rapid Recovery use self-signed certificates instead of public third-party signed certificates.

By default Rapid Recovery uses self-signed certificates for encrypted communication. These self-signed certificates may show up as a vulnerability during a security audit. However, self-signed certificates are not inherently insecure, it is dependent on how and why they are used. In the case of Rapid Recovery, the self-signed certificates are used to allow two known devices to communicate with each other. The self-signed certificates are automatically generated as part of the protection process which requires you to enter a username and password to connect the core server to the agent. Then future communication uses these self-signed certificates to encrypt the communication. In this case you can think of the Rapid Recovery self-signed certificate as an extra secure authentication token used for communication between two devices you authorized to communicate. Because all devices in this scenario are known, the risks associated with using a self-signed certificate are mitigated.

If you would like to use a Public third-party signed certificate you can use the workaround below:

Windows Registry Disclaimer:

Quest does not provide support for problems that arise from improper modification of the registry. The Windows registry contains information critical to your computer and applications. Make sure you back up the registry before modifying it. For more information on the Windows Registry Editor and how to back up and restore it, refer to Microsoft Article ID 256986 “Description of the Microsoft Windows registry” at Microsoft Support.

 

---

 

When requesting a certificate, use the regular Windows procedure for generating a certificate request. This typically involves using the Certificate Request Wizard in IIS, the Certificates MMC, or the certreq command line. These techniques are all well documented outside of this KB.

The main requirements for custom SSL Server certificate:

• It should have private key
• It should be exportable
• Custom certificate should be imported to Trusted Root CA or to Enterprise Trust Root level certification authorities
• It is recommended for public key to have 4096 Bits RSA value

Install the certificate per the authority's instructions and associate it with the computer account of the server on which it's installed.

To apply a third-party certificate in Rapid Recovery Core Console, complete the following steps.

1. Stop the Core Service.
2. Type Regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Core\CertificateService.
3. Change the LocalServerThumbprint to the thumbprint value of your new certificate.
4. Delete LocalServerCertificate key
5. Start the Core Service and launch the Central Console.
6. Verify that the custom certificate is now used and that a new LocalServerCertificate value was generated.

To apply a third-party certificate in Rapid Recovery Agent, complete the following steps.

1. Stop the Core Service.
2. Type Regedit and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\AppRecovery\Agent\CertificateService.
3. Change the LocalServerThumbprint to the thumbprint value of your new certificate.
4. Delete LocalServerCertificate key
5. Start the Core Service and launch the Central Console.
6. Verify that the custom certificate is now used and that a new LocalServerCertificate value was generated.

 

Note: Certificates without an exportable private key will not work and the LocalServerThumbprint will revert from the value entered in step 4

Note 1: if after installing 3rd party certificate, Core console is asking for credentials over and over, seemingly not accepting correct credentials then do the following:

• stop the Core service
• open regedit
• navigate to HKLM\system\CurrentControlSet\Services\Lanmanserver\parameters
• create DWORD value DisableStrictNameChecking and set it to1
• navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
• create DWORD value DisableLoopbackCheck and set it to 1
• reboot the Core server