Zertifikatswarnungen nerven, egal von welchem Programm. In diesem Fall warnt eine Remote Desktop Verbindung /RDP) vor einem ungültigen Zertifikat.
Diese Meldung dürfte wohl jeder kennen:
Es handelt sich hier um einen „normalen“ Windows Server, also keinen Remote Desktop Host (Terminal Server), RDP ist hier nur für die Administration aktiviert. Windows verwendet in der Standard Konfiguration ein selbstsigniertes Zertifikat:
Da das selbst signierte Zertifikat vom Client nicht akzeptiert wird, erscheint die Warnung wie oben zu sehen.
In meinem Fall handelt es sich um einen Exchange Server, der für seinen Hostnamen schon ein gültiges Zertifikat von einer öffentlichen CA besitzt:
Warum nicht also dieses Zertifikat auch für RDP nutzen und damit die Warnung loswerden? Nein, auf „Nicht erneut fragen“ klicken ist keine Option :-)
Natürlich klappt folgende Weg auch mit jedem anderen Zertifikat und auch mit „Nicht-Exchange“-Servern. Woher das Zertifikat stammt, von einer internen PKI oder öffentlichen CA, spielt dabei keine Rolle. Hauptsache der entsprechende Hostname steht auf dem Zertifikat und die Sperrlisten sind erreichbar.
Vorhandenes Zertifikat für RDP nutzen
Um dem Remotedesktopdienst ein neues Zertifikat zuzuweisen, wird der Thumbprint des neuen Zertifikats benötigt. Das Zertifikat muss sich im Zertifikatsspeicher des Computers befinden.
Die Thumbprints der vorhandenen Zertifikate lassen sich mit dem folgenden Befehl anzeigen:
Get-ChildItem -Path cert:/LocalMachine/My
Die Ausgabe sieht dann in etwa so aus:
Der Thumbprint des entsprechenden Zertifikats kann jetzt genutzt werden, um dem Remotedesktopdienst das Zertifikat zuzuweisen:
$TSpath = (Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash="5C526C2AB97D100249B411EA11566D55846B5ED3"}
Bei den beiden Befehlen oben, muss nur der Thumbprint entsprechend ausgetauscht werden. Die Ausgabe sollte wie folgt aussehen:
Hinweis: Die PowerShell muss als Administrator ausgeführt werden.
Das war schon alles. Das neue Zertifikat wird bei der nächsten RDP Verbindung genutzt und die Zertifikatswarnung ist verschwunden.
Standard Zertifikat für RDP nutzen
Die Änderung lässt sich auch wieder Rückgängig machen, hier kann einfach das alte selbstsignierte Zertifikat wieder zugewiesen werden.
Das Standardzertifikat wird im Zertifikatsspeicher des Computers im Ordner „Remote Desktop“ gespeichert. Mit dem folgenden Befehl kann der Thumbprint ermittelt werden:
Get-ChildItem -Path "cert:/LocalMachine/Remote Desktop"
Jetzt kann wieder das Original Zertifikat zugewiesen werden (Thumbprint im zweiten Befehl austauschen):
$TSpath = (Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash="7E3044CDB0E5CF038D421E3E001F8DFE632E4A1D"}
Bei der nächsten RDP Verbindung wird wieder das Original Zertifikat verwendet.
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
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
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!!!
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
Super danke
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