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.
Soweit so gut.. jedoch meckert er, wenn man die Zertifikate nicht über Windows verwaltet:
„Es konnte keine Sperrprüfung für das Zertifikat durchgeführt werden.“
Selbst wenn man die ROOT CA auf no CRL/OSCP gesetzt hat und das Zertifikat in vertr. Herausgeber ebenso…
wie bekommt man diese Meldung weg?
Meine eigene ROOT CA hat natürlich keine CRL.. wozu auch?
Ich bin deutlich vertrauenswürdiger, als jeder andere.. und wenn was kompromittiert wird, mache ich halt alles manuell neu.
Wie bekomme ich diese Meldung weg bzw. nur für meine Zertifikate?
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