Certificate warnings are annoying, regardless of the program. In this case, a remote desktop connection (RDP) warns of an invalid certificate.
Everyone is probably familiar with this message:
This is a "normal" Windows server, i.e. not a remote desktop host (terminal server), RDP is only activated here for administration. Windows uses a self-signed certificate in the standard configuration:
As the self-signed certificate is not accepted by the client, the warning appears as shown above.
In my case, it is an Exchange server that already has a valid certificate from a public CA for its host name:
So why not use this certificate for RDP as well and get rid of the warning? No, clicking on "Do not ask again" is not an option :-)
Of course, the following method also works with any other certificate and also with "non-Exchange" servers. Where the certificate comes from, from an internal PKI or public CA, does not matter. The main thing is that the corresponding host name is on the certificate and the revocation lists are accessible.
Use existing certificate for RDP
To assign a new certificate to the Remote Desktop Service, the thumbprint of the new certificate is required. The certificate must be in the computer's certificate store.
The thumbprints of the existing certificates can be displayed with the following command:
Get-ChildItem -Path cert:/LocalMachine/My
The output then looks something like this:
The thumbprint of the corresponding certificate can now be used to assign the certificate to the Remote Desktop Service:
$TSpath = (Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path
Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash="5C526C2AB97D100249B411EA11566D55846B5ED3"}
With the two commands above, only the thumbprint needs to be exchanged accordingly. The output should look like this:
Note: The PowerShell must be run as an administrator.
That was all. The new certificate is used for the next RDP connection and the certificate warning has disappeared.
Use standard certificate for RDP
The change can also be reversed by simply reassigning the old self-signed certificate.
The default certificate is saved in the computer's certificate store in the "Remote Desktop" folder. The thumbprint can be determined with the following command:
Get-ChildItem -Path "cert:/LocalMachine/Remote Desktop"
Now the original certificate can be assigned again (replace thumbprint in the second command):
$TSpath = (Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path
Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash="7E3044CDB0E5CF038D421E3E001F8DFE632E4A1D"}
The original certificate is used again for the next RDP connection.
Vielen Dank. Hat perfekt funktioniert. Hatte zwei Server ,die, obwohl sie ein neues SSL-Zertifikat erhalten, sich bei RDP immer das selbst erzeugte gegriffen haben. Jetzt ist die Verbindung sicher!
Hi, ich nutze einen Windows Server (2019) und kriege die Fehlermeldung wie oben beschrieben – das Zertifikat ist ein „ordentliches“ SSL-Zertifikat. Es ist freigegeben für Server- und Client-Zertifizierung. Geht das nicht für Remote Desktopverbindungen? Die Informationen (z.B. CN/Hostname) stimmen auch überein mit den Informationen in dem self-sign Zertifikat…Worauf kann das denn noch liegen? Fehlermeldung nochmal:
Set-WmiInstance : Invalid parameter
At line:1 char:1
+ Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash=“XXX …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Set-WmiInstance], ManagementException
+ FullyQualifiedErrorId : SetWMIManagementException,Microsoft.PowerShell.Commands.SetWmiInstance
schaut aus als wolltest auf das alte ausgelaufene Zertifikat zugreifen…
Ist das alte Zertifikat unter „Eigene Zertifikate“\“Zertifikate“ entfernt worden?
Ist das neue Zertifikat unter „Eigene Zertifikate“\“Zertifikate“ importiert worden?
(Zertifikat nicht unter Remotedesktop\zertifkate ablegen! Das zieht er hier nicht!)
Erst dann den Thumbprint beziehen, und so weiter wie oben beschrieben.
HTH & LG
Ab 2019 oder 2016, lässt es sich auch im Servermanger einrichten.
Unter Remotedesktopdienste > Übersicht > Aufgaben >Bereitstellungseigenschaften bearbeiten > Zertifikate > Remo…. einmaliges Anmelden, lässt es sich im PKCS12 einstellen, wichtig ist aber, dass du es eine .pfx Datei ist .p12 mag Microsoft nicht.
Das ganze lässt sich übrigens auch Remote erledigen.
Wenn das entsprechend vorgefertigte und exportierte Zertifikat bereit liegt (im folgenden c:\RDPAuth.pfx), kann mit folgendem „Einzeiler“ das Zertifikat remote importiert und gebunden werden:
Copy-Item -Path „C:\RDPAuth.pfx“ -Destination „\\SERVERNAME\c$\“; Invoke-Command -ComputerName „SERVERNAME“ -ScriptBlock { Import-PfxCertificate -FilePath „C:\RDPAuth.pfx“ -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString -String ‚PrivateKeyPasswort‘ -AsPlainText -Force) | Select-Object -ExpandProperty „Thumbprint“ -OutVariable „Thumbprint“; Set-WmiInstance -Path ((Get-WmiObject -Class „Win32_TSGeneralSetting“ -Namespace „root\cimv2\terminalservices“ -Filter „TerminalName=’RDP-tcp'“).__path) -Argument @{ SSLCertificateSHA1Hash=$($Thumbprint) }; Remove-Item -Path „C:\RDPAuth.pfx“ }
Das Zertifikat wird auf das Zielsystem kopiert, dort importiert, gebunden und die .pfx anschließend wieder gelöscht.
Ein vorheriges Ermitteln des Thumbprints ist nicht mehr nötig.
LG
..Achtung beim Kopieren.. Die durch die Kommentarfunktion gesetzten „ und “ Zeichen müssen durch entsprechende Hochkomma ersetzt werden.
Hallo, leider erhalte ich auf einem Remotedesktop-Server (Windows Server 2016) die folgende Meldung: (Der Thumbprint war im Original korrekt und vollständig). Hat jemand eine Idee? Der RD-Server ist als SAN im SSL-Zertifikat eingetragen und dieses ist im Bereich „Eigene Zertifikate“ installiert.
PS C:\Windows\system32> Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash=“53D……2″}
Set-WmiInstance : Der Parameter ist ungültig.
In Zeile:1 Zeichen:1
+ Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash=“53D …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Set-WmiInstance], ManagementException
+ FullyQualifiedErrorId : SetWMIManagementException,Microsoft.PowerShell.Commands.SetWmiInstance
Hallo Thomas,
wir haben das gleiche Problem.
Hast du eine Lösung gefunden?
Hallo,
ich bin vor dem selben Problem.
Set-WmiInstance : Der Parameter ist ungültig.
In Zeile:1 Zeichen:1
+ Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash=“093 …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [Set-WmiInstance], ManagementException
+ FullyQualifiedErrorId : SetWMIManagementException,Microsoft.PowerShell.Commands.SetWmiInstance
Wenn ihr diese Meldung bekommt, ist euer Zetifikat nicht kompatibel.
Stellt sicher, dass es ein Zertifikat ist, welches auch zur RemoteDesktop-Authentifizierung verwendet werden kann.
Super danke
Funktioniert sehr gut. Leider erhalte ich beim Ausführen auf einem Windows 2012 R2 Failover Cluster Node COMException. Sollte dies auf Clusterknoten genauso funktionieren? Habe dies das erste Mal auf einem Clusterknoten ausgeführt und kann das nicht richtig einschätzen.
Freue mich über eine Rückmeldung.
Viele Grüße
Mario
Perfekt, danke!!! Hatte Thinclients die nicht in der Domäne sein sollen und die haben sich immer das selbst ausgestellte Zertifikat des Servers gegriffen, welches aber nicht die alternativen DNS Namen enthielt. Auf diesem Weg hier alles so wie es sein soll!!!
Als Ergänzung wäre der Weg über die automatische Verteilung mit GPO mit einer RDPAuth Zertifikatsvorlage hilfreich..
https://www.darkoperator.com/blog/2015/3/26/rdp-tls-certificate-deployment-using-gpo
Hallo,
diese Schritte, bzw. der Weg über eine Windows-PKI und GPO, müssen doch noch zwangsläufig dieses Jahr gegangen werden, wenn Microsoft nächstes Jahr die SHA1-Unterstützung einstellt, oder?
Ich habe testweise mal auf einer Windows 7 und Windows 2008 Maschine SHA1-Hashes per Registry geblockt und war dann nicht mehr in der Lage eine RDP-Verbindung dorthin aufzubauen, da im Zertifikatsspeicher jeweils ein selbstsigniertes SHA1-Zertifikat für „Remote Desktop“ hinterlegt war.
Oder ist jemanden eine alternative Möglichkeit bekannt, wie man nächstes Jahr weiterarbeiten kann? Bei hunderten Windows 7-Rechnern manuell das Zertifikat zu tauschen, könnte lästig werden.
MfG Steve Weber