Azure Site Recovery: Expired Authentication Certificate and Restoration Challenges

Question

Azure Site Recovery: Expired Authentication Certificate and Restoration Challenges

HelpDesk 0

Problem description

I am experiencing issues with my Azure Site Recovery setup due to an expired authentication certificate for my registered server (MCMCH2). I want to replace this expired certificate and restore its existing registration without losing protected items or replication relationships. Additionally, I am unsure about the current status of the certificate renewal job and how to proceed.

Environment

Azure Site Recovery with a Recovery Services vault and a registered source-side component, region not specified.

What I've already tried

I have performed the standard portal action to renew the Hyper-V host certificates for MCMCH2. The job started but remains in progress, and no new certificate has appeared locally. I have also reviewed the recovery environment, confirmed that the server is still running the Site Recovery service and agent, and checked the last heartbeat. No host/site deletion or unregistration has been performed. Troubleshooting steps like running renewcerts.exe or cspsconfigtool.exe locally on MCMCH2 do not apply in this Hyper-V host scenario.

Current status

I am seeking guidance on whether the active renewal job is progressing or requires intervention, how to replace the expired certificate while preserving existing registration and relationships, and what steps to take if the renewal process is stuck or unsuccessful.

Lakshma Reddy Vattijonnala 1,665 Reputation points Microsoft External Staff Moderator

2026-09-30T16:36:03.0166667+00:00

Hi @HelpDesk Thank you for reaching out to Microsoft Q&A. We are looking into the issue and we will get back to you shortly with an update

1 answer

Your answer

Lakshma Reddy Vattijonnala 1,665 Reputation points Microsoft External Staff Moderator

2026-09-30T16:36:03.0166667+00:00

Hi @HelpDesk Thank you for reaching out to Microsoft Q&A. We are looking into the issue and we will get back to you shortly with an update

Answer 1

For a HyperV to Azure Site Recovery deployment, preserving the existing Hyper-V host registration is the key objective. Since MCMCH2 remains registered, the Site Recovery services are running, and the Hyper-V site has not been deleted or unregistered, avoid any action that would create a new registration unless recovery of the current registration proves impossible

Recommended approach

In the Recovery Services vault, navigate to Site Recovery Infrastructure > Hyper-V Hosts and confirm the status of MCMCH2.
Review the corresponding Site Recovery Jobs entry for the certificate renewal operation. The most important question is whether the job is still showing progress updates or whether it has stopped advancing for an extended period.
While the renewal operation is active, avoid:
- Unregistering and re-registering the host
- Deleting and recreating the Hyper-V site
- Attempting certificate replacement procedures intended for Configuration Servers or VMware-to-Azure scenarios
Verify that:
- The Azure Site Recovery Provider and Recovery Services Agent services are running.
- The host can reach the required Azure Site Recovery endpoints over HTTPS.
- Recent heartbeats are still being received by the vault.
Review Event Viewer logs under the Azure Site Recovery and Recovery Services components for authentication, connectivity, certificate, or provider-related errors that occurred during the renewal attempt.

If the renewal operation appears stalled

If the vault job remains in an In Progress state without any status changes and no new host state is reflected in the vault, avoid starting additional renewal operations. Instead:

Confirm that communication between the host and Azure remains healthy.
Check for provider or agent version issues and ensure the installed components are on a currently supported release.
Continue troubleshooting the existing registration rather than attempting a fresh registration.

Important point regarding replication relationships

The good news is that your current environment still appears to retain the metadata that links the Hyper-V host, protected items, and replication configuration. As long as the host remains registered and the Hyper-V site is not removed, you have the best chance of preserving existing replication relationships. Re-registration should be treated as a last-resort recovery action because it can require re-establishing protection for replicated workloads.

In summary, focus on validating whether the existing Renew Certificates job is actively progressing or genuinely stalled, keep the current registration intact, and avoid any unregister/re-register actions while recovery of the existing registration remains possible.

Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.

HelpDesk 0 Reputation points

2026-10-01T13:50:58.0233333+00:00

Hi - Thanks for the reply. We have completed the checks and need guidance following failed certificate renewal.

This is a standalone Hyper-V-to-Azure Site Recovery deployment without VMM. The existing host remains registered in its original vault and Hyper-V site, but shows Not Connected.

Confirmed findings:

The ASR_SRSAUTH_CERT_KEY_CONTAINER certificate expired on 28 September 2026. Its private key is present, and no replacement certificate was found in LocalMachine\My.

The separate ASR_HYPER_V_HOST certificate used by the Recovery Services Agent is valid until January 2029.

VMMS, Microsoft Azure Site Recovery Service and Microsoft Azure Recovery Services Agent are running.

Installed versions are ASR Provider 5.1.8153.0 and Recovery Services Agent 2.0.9964.0.

The host clock is currently correct and synchronised.

Portal certificate-renewal attempts on 29 and 30 September both failed after approximately two hours with Error 25018. Refresh server details also failed.

The Provider setup summary records a Registration operation on 29 September with Success and ExitCode 0, retaining the original Provider and Site IDs. However, the host remains disconnected and the authentication certificate remains expired.

A protected VM previously reported local replication as Normal.

Could you provide the supported procedure to replace the expired ASR_SRSAUTH certificate and restore the existing registration when portal renewal fails. And could you clarify whether it preserves the existing Provider ID and protected-item relationships, and what service interruption, if any, is involved.

If Provider runtime diagnostics are needed first, could you specify the logging procedure and errors to capture. We need to preserve running production VMs and existing replication configuration.
HelpDesk 0 Reputation points

2026-10-02T14:13:06.9566667+00:00

Hi - Just checking to see if there is any help available?