Trying to install a cert for the Rapid Recovery Agent

Has anyone had any success installing a certificate for the Rapid Recovery Agent?  When I put in the thumbprint and restart the recovery service, it replaces the thumbprint I entered.  I was following kb 117531.  Any help would be appreciated.  Thanks!

  • This has never worked for us. I have opened cases and they cant figure out a solution. So there is always a warning when trying to open the Rapid Recovery GUI. It is embarrassing because it comes up at almost every install. Support will give you work-around's (but none seem to work) and tell you this cant be fixed

    226273 is another TN but it does not solve the issue either.
  • In reply to Emte:

    Thanks for the info. It's crazy that Quest hasn't fixed this issue by now.
  • I installed an agent certificate a few times without facing any issues at all. In my case the customers had to use SHA-2 certificates while keeping AppAssure 5.4.3 agents.
    Basically I created a self signed certificate with an exportable key (won't work otherwise), copied it in the Certs Store on the Agent -- Trusted Root Certification Authority, enabled it specifically for all purposes and replaced the thumbprint in the Agent Registry. The idea is that when the agent starts up it checks the thumbprint in the Certificate store and if it finds it, it uses the certificate already there. Please note that you need to replace the Cert thumbprint for two reg key values (AppAssure/RapidRecovery can use two certificates if needed but you are fine with just one).
    The Agent protection needs to be repaired as the core has the old agent certs.
    If you are using an AppAssure 5.4.3 core, there is a patch that makes it understand SHA-2 certs.

    Just two caveats:
    1. If you create your own cert, it will be placed most likely in your Personal Certs Store branch. You need to export it (including the key) and re-import it in the Trusted Root Certs Store.

    2. If you install a Sha2 cert, the thumbprint is still sha1 -- this is normal as the thumbprint is used just in place of the cert name.

    Hope that this helps.

    Anyway, that is all that is to it. If you have some difficulties implementing the solution, please open a case with us.

  • In reply to Tudor.Popescu:

    I had a case open and when the work-around's failed, the exact reply to me was "Thank you for the reply, unfortunately at this point we only have those workarounds for this certificate issue" No further troubleshooting was available

    I think we (I) are talking about 2 different issues. I was talking about the fact that opening the Core Console constantly gives warnings and you have to click through several things to get it to open. That is what is embarrassing
  • In reply to Emte:

    In my case I did not have such an issue. Do you still have the case# so I take a look?
  • In reply to Tudor.Popescu:

    4159048 - But we just closed it as they said nothing could be done if the work-around's did not work
  • In reply to Tudor.Popescu:

    The only thing I didn't try was installing the cert in the trusted Root Certs Store but after doing that it still didn't work. It always replaces the thumbprint with its own. I am using a SHA1 cert but that should work right?
  • In reply to brianf116:

    Hi brianf116:
    Sorry to hear that. Most likely you did not replace the correct thumbprints in the Agent Registry (hint: check the current certificate thumbprints to make sure you replace the correct ones). Unless the code has changed without warning (which may have happened), if the agent finds certificates with a thumbprint it already has in the Trusted Root Certs Store, it won't create new ones. As mentioned before, there are two (identical) thumbprints to replace.
  • In reply to Tudor.Popescu:

    I am only finding one server thumbprint under hklm\software\apprecovery\agent\certificateservice. There is a localserverthumbprint and localclientthumbprint. I was only changing the localserverthumbprint and deleting the localservercertificate key. Should I put the thumb in both server and client keys? Also, should I delete the certs that it created in the local store? There are 15 of them there. Thanks and I really appreciate your help.
  • In reply to Emte:

    Have you tried using chrome flags?

    I typed


    in the address bar, then CTRL-F to open the find box and searched for 'certificate'

    Got the following entry:

    Allow invalid certificates for resources loaded from localhost.
    Allows requests to localhost over HTTPS even when an invalid certificate is presented. – Mac, Windows, Linux, Chrome OS, Android

    I enabled it from the drop down box.
    Alternatively, I could have entered


    in the address bar and click 'enable' in the dropbox showing up.

    I am afraid that it won't work for remote cores, though.
  • In reply to brianf116:

    Quick update, I deleted all the certs it created, replaced the thumbprint again and started the service. It created two keys, one for the server and one for the client but it did not use the cert I generated. I don't understand why its not using the correct cert and am not sure what else to try. Thanks.
  • In reply to brianf116:

    Still waiting for my lab to come up (it may take a day or two as it was physically moved and there is a lot to do to have it running again). As soon as it available, I will try replacing the cert -- and will document every step so, if it works, we will have a reference document. Please let me know what agent version are you using. As I stated before, I have done this for AppAssure 5.4.3 agents only.
  • In reply to Tudor.Popescu:

    agentservice.exe is version Thanks.
  • In reply to Tudor.Popescu:

    Hi Tudor.
    I wanted to check in and see if you were able to get a certificate installed in your lab? Thanks.

  • In reply to brianf116:

    I tried the newest version of the Agent. You are correct, it replaces third party certificate with its own, even when all certificate elements (thumbprint and encoded value) are replaced. Will dig some more and get back to you.