Most people read the RDP certificate popup as an obstacle. It is actually a question - the only identity question Windows can ask about a PC that issued its own certificate. Here is what every line of that dialog really means.
You type an address, press Connect, and before any password is asked, Windows stops you: the remote computer could not be authenticated. If you have clicked Yes a hundred times without reading it, you are not alone - but each Yes is an answer to a real question, given on your behalf to whatever machine answered at that address. This page translates the dialog into plain words: what the certificate is, why your own PC fails the check, what Yes actually grants, and what the certificate cannot tell you at all.
The remote computer could not be authenticated due to problems with its security certificate. Before showing your desktop, the remote PC presented a certificate as its identity card. Windows examined it and could not vouch for it.
It may be unsafe to proceed. Not because the connection is broken - the session would still be encrypted - but because an encrypted tunnel to the wrong machine protects the wrong machine's conversation with your password.
Certificate error: The certificate is not from a trusted certifying authority. This is the specific finding. The certificate was signed by the PC itself, and self-issued identity cards prove nothing on their own. A certificate from a recognised authority would have been checked against Windows' built-in trust list and passed silently.
View certificate opens the actual card - who issued it, who it was issued to, and its thumbprint, the fingerprint every fix in this guide set revolves around.
Out of the box, Windows creates a self-signed certificate for Remote Desktop so the service can run without anyone buying or configuring anything. That is a deliberate, reasonable default for a home PC. The cost of the convenience is this dialog: since no trusted authority issued the certificate, the only person who can vouch for the machine is you.
There is an important exception worth knowing. On a domain network, the client usually authenticates the server through Kerberos first, and this certificate dialog often never appears for domain PCs. The popup is mostly the experience of workgroup PCs, home servers and machines reached by IP address - exactly the setups where no other identity system exists to do the vouching.
Yes does not say this certificate is genuine. It says: connect anyway, this once. Your password then travels through an encrypted session to a machine whose identity rests entirely on the address you typed and your own judgement.
That judgement is sound when the facts are sound - your own PC, on your own network, at the address you expected. It is unsound in one specific situation: when any of those facts changed without you knowing. A different machine answering at the same address, a redirected connection, a server rebuilt by someone else - the dialog cannot tell these apart, and it is not trying to. It is asking the one witness who might know: you.
Ticking Don't ask me again for connections to this computer converts your one-time Yes into a standing instruction, but a narrow one - Windows stores that certificate's fingerprint (CertHash) for that server alone, and will ask again the moment the fingerprint differs. It is a memory of one verified answer, not a general permission.
Honesty cuts both ways. Even a perfectly trusted certificate would not prove the machine is safe - only that it is the machine named in the certificate. It says nothing about whether that PC is patched, clean or well run. And the thumbprint you trust is only as good as the moment you verified it: trusting a fingerprint copied from a random webpage would be worse than clicking Yes yourself, because it outsources the one judgement the dialog exists to request.
So the working rule is short. Read the address. Ask whether anything changed. If the server is yours and nothing changed, Yes - or the checkbox - is a reasonable answer. If anything is unexpected, the honest answer is No, and a different page in this set explains the checks to run before you ever connect again.
The full one minute fix, shown live on a real Windows 11 PC, step by step.
Watch Full VideoThe certificate still does the heavy lifting of encryption, and it gives the server a consistent identity you can recognise and pin. The weakness is only in who issued it - itself. Once you verify and trust that exact certificate, the identity check becomes meaningful for every later connection.
On a domain, Kerberos usually authenticates the server before certificates enter the picture, and company servers often carry certificates from the internal authority that every domain PC already trusts. Both routes answer the identity question silently - which is why the popup is mostly a home and small-office experience.
For your own machine at its expected address on your own network, it was a reasonable judgement each time - just a slow one. The risk the dialog guards against is the changed situation, not the routine one. Trusting the certificate once, deliberately, is simply making that same judgement permanent for that server.