It is the smallest fix in this whole guide set - one tick in a dialog you were going to click through anyway. Graded honestly: for your own server it is genuinely good, with exact limits you should know before you rely on it.
Every guide about the RDP popup eventually arrives at the checkbox: Don't ask me again for connections to this computer. Some treat it as a guilty shortcut; others tick it without a thought. Both reactions skip the interesting part - what the tick actually does is precise, narrow and, for the right situation, completely respectable. This page grades it properly: what it writes, what it still protects, where it legitimately falls short, and the two situations where your finger should stop before ticking.
Ticking the box and clicking Yes writes one value into your user registry: the server certificate's fingerprint, saved as CertHash under HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers, inside a key named after the exact server name or address you connected to. Nothing system-wide changes. No setting is lowered. The next connection is compared against that fingerprint, and only that fingerprint.
That precision is why the checkbox grades well. Compare it with client-wide tweaks that soften authentication for every connection: the checkbox is a scalpel, they are a hammer. It also grades well for accountability - the trust lives in your registry branch, so your decision never silently disarms the warning for a colleague signing in on the same PC.
The checkbox does not switch the check off; it stores the answer. If the server's certificate is ever different - replaced, regenerated, or served by a different machine entirely - the comparison fails and the warning returns in full, with the box unticked, asking you to decide again. That is not the fix failing. That is the fix doing the second half of its job.
It also protects its scope: the trust covers the server as you addressed it. Connect later by a different name or IP and you will be asked again, because as far as the client knows, that is a different introduction. Slightly inconvenient, entirely honest.
Three real limits, none of them hidden. First, it is per user: five people sharing one PC each earn the popup until each ticks it. Second, it is per client PC: trust does not travel with you to the next machine. Third, it depends on the server's self-signed certificate staying stable, and Windows renews and regenerates that certificate over time - each regeneration is a fresh popup for every user, and offices that hit this regularly are telling you they have outgrown the checkbox and belong on the real-certificate route.
Notice what is not on the list: security. Within its limits the checkbox is not a compromise - it is the mechanism the REG file and every fleet deployment in this guide set are built on.
Moment one: the popup is unexpected. The server you connect to daily suddenly asks again. That is a changed certificate until proven otherwise - the exact event the checkbox exists to surface. Ticking through it reflexively throws away the one warning that matters most, and a companion page covers the checks to run instead.
Moment two: the machine is not yours. A client's server, a borrowed VPS, a machine a stranger configured. You have no basis to vouch for it and no business making the question disappear - for all you know, you will connect to that address again in worse circumstances. Answer Yes per session if you must connect at all, and let the dialog keep asking.
The full one minute fix, shown live on a real Windows 11 PC, step by step.
Watch Full VideoIn effect, yes - the REG route writes the same CertHash value the checkbox writes, just in advance and in bulk. The checkbox is the safer teacher of the two, because the fingerprint is captured from the certificate actually presented to you, rather than from a file whose contents you have to verify.
Because the comparison failed - the server's certificate no longer matches the fingerprint you saved. The usual innocent cause is the self-signed certificate being regenerated or renewed. Verify the server is unchanged in every other respect, view the certificate, and tick again to trust the new one.
Effectively, yes - the same CertHash entries can be deployed through Group Policy preferences, and offices with a certificate authority can skip pinning entirely by issuing trusted certificates. Both routes are covered in the fleet page of this guide set. What no admin should deploy is a client-wide warning disable.