You trusted this server months ago, and this morning the warning is back. Do not read it as a broken fix - read it as a report. The certificate changed, so the client is asking again. Here is how to answer properly.
Of every popup in this guide set, this is the one to respect most: the repeat warning for a server you already trust. Your client holds that server's certificate fingerprint, and what arrived today does not match it. After a rebuild, a migration or a restore, that is expected and innocent - the new Windows installation generated a fresh self-signed certificate. The same mismatch is also exactly what a hijacked connection would look like. This page walks the calm middle path: assume it needs verifying, run the checks that take three minutes, then re-trust deliberately.
The self-signed RDP certificate is created by each Windows installation for itself. Rebuild the machine, restore it onto new hardware, or migrate the role to a fresh server, and a new certificate with a new thumbprint is born - even if the PC keeps the same name, the same address and the same data. Your client's saved CertHash still points at the old machine's identity, so the mismatch is total and the dialog returns. Nothing malfunctioned on either side.
The same applies, more quietly, when nothing was rebuilt at all: Windows renews and regenerates these certificates over time, and a renewal changes the fingerprint too. Rebuilds are just the loudest cause.
Do not tick the box on the first sight of the returning dialog. Run the checks that separate a rebuild from a red flag:
All three agree? The explanation is proven, and re-trusting is a decision, not a reflex.
Once verified, the renewal itself is the simplest step in this guide set: tick Don't ask me again for connections to this computer and click Yes. The client overwrites the saved CertHash with the new fingerprint, and the server is quiet again - for exactly as long as this certificate lives.
If you maintain the pin through a REG file instead - the video's route - regenerate it the same honest way: export the server's fresh key from Registry Editor after ticking the box once, and retire the old file. A folder of stale REG pins for certificates that no longer exist is a small museum of traps; each invites someone to trust a fingerprint nobody verified.
And tell your users before the next rebuild, not after. One line - the server was rebuilt, the warning will appear once, here is the new thumbprint to expect - turns a morning of alarmed calls into a fleet quietly re-trusting on schedule.
Sometimes the checks do not agree: nobody rebuilt anything, the certificate's issue date makes no sense, or the thumbprint on the server's console is not the one the dialog showed you. That last finding is the serious one - it means the machine answering at your server's address is presenting a different certificate from the server itself, and the honest possibilities narrow fast: a wrong machine has taken the address, a connection is being intercepted, or something on the network path is not what it was.
The response is discipline, not bravery: click No, do not type a password, and investigate from the network side. The companion page on the popup that should stop you covers this moment in full. A rebuild explains a new certificate. Silence explains nothing.
The full one minute fix, shown live on a real Windows 11 PC, step by step.
Watch Full VideoYes, unless you prepare. Each user's client holds the old fingerprint, so each will be asked once. You can smooth it by deploying the new CertHash through Group Policy preferences, or prevent it entirely by giving the rebuilt server a trusted certificate - but a surprise fleet-wide popup after a rebuild is normal, not a failure.
Investigate, then decide. Windows does renew and regenerate self-signed certificates on its own, which is innocent - check the certificate's issue date and compare the thumbprint at the server's console. If both line up with the server's own store, you have your explanation. If the console disagrees with the dialog, treat it as the stop case, not the renewal case.
No - the client stores one CertHash per server entry. That single-slot design is deliberate: at any moment your trust points at exactly one certificate, and any change forces a fresh decision. Systems that accumulated old trusts silently would quietly lose the protection this dialog exists to give.