Every client-side trick in this guide set manages one machine at a time. The permanent answer fixes the server once: replace the self-signed certificate with one your PCs already trust, and the popup disappears for everyone - with the warning still guarding every other server.
The popup exists because the server's identity card was signed by itself. Pinning its fingerprint works, but it is a promise each user repeats on each PC, and it expires the day the certificate changes. The professional fix removes the cause: give the server a certificate from an authority your clients already trust, and bind the RDP listener to it. This page covers the two realistic sources - an internal certificate authority and Let's Encrypt - and the binding step Microsoft documents, honestly including the maintenance each route carries.
If your office runs a domain, the cleanest answer is a certificate issued by your own certification authority, deployed through Group Policy - the subject of a companion page in this set. The CA's certificate is already trusted by every domain PC, so a server certificate it issues is accepted silently. Templates exist precisely for this: the server requests or is auto-enrolled for a certificate in its own name, and no user ever meets the popup.
Scope honesty: this route needs a CA, which a three-PC workgroup does not have and should not build for this alone. It is the right answer at office scale and overkill below it - for one or two PCs, trusting the fingerprint per user is entirely respectable.
A free certificate from Let's Encrypt is a real, trusted certificate - but it carries two conditions a self-signed one never imposes. The server needs a public DNS name you control, matching the name users connect to; a bare IP address on a home network does not qualify. And the certificate lives for 90 days, so the install-and-bind routine must repeat on every renewal - in practice, a small script that copies the renewed certificate into the Remote Desktop store and re-binds the listener.
Skipping the renewal step does not break anything dramatically; the server simply falls back into warning territory when the expired certificate stops being accepted, and the popup returns to tell you so - one more example of the warning working as designed.
Installing a certificate is not enough; the RDP service keeps using its self-signed one until told otherwise. The certificate must sit in the server's Local Computer store, in the folder named Remote Desktop. Then the listener is bound to its thumbprint through the SSLCertificateSHA1Hash value - Microsoft's documented PowerShell route is shown in the panel above.
One byte-level trap, straight from Microsoft's own documentation: the thumbprint you copy from the certificate's Details tab arrives with spaces between the byte pairs and often an invisible character hiding at the very start. Pasted in carelessly, the binding fails for a reason you cannot see. Paste the thumbprint into a text editor first, remove every space, and make sure the string begins with its first real hex character. Then reconnect - if the binding took, the warning is gone because the check now passes, not because it was skipped.
A trusted certificate ends the popup for this server because the identity question is now answered by an authority. It changes nothing about your exposure elsewhere: connections to other machines still face the full check, which is exactly what you want. It also does not make the server itself more secure in any other respect - patching, passwords and network exposure are separate jobs that a certificate does not perform.
And one maintenance truth for the internal-CA route: certificates expire there too, just on a longer clock. Put the renewal date in the same diary as every other expiry you track, or one morning the whole office will meet a popup that is, once again, simply telling the truth.
The full one minute fix, shown live on a real Windows 11 PC, step by step.
Watch Full VideoUsually not. For one server and one or two users, trusting the self-signed certificate's fingerprint - the checkbox or the REG pin - gives you the same practical protection with none of the infrastructure. The real-certificate route pays off when many users connect, or when the server's certificate keeps changing.
Only if the certificate covers that address, which most do not - certificates are normally issued to names. This is a quiet argument for connecting by name: connect to the name on the certificate, and the identity check can actually succeed.
Yes - the binding is a stored setting, not a per-boot state, and restarts do not clear it. What ends it is the certificate expiring or being replaced; at that point the new certificate must be bound in its place, which is why renewal belongs in your maintenance routine.