Einleitung
Es gibt Admin-Routinen, die laufen und laufen, fast wie im Nebeneffekt. Das Erneuern, Ausrollen und Binden von RDP-Zertifikaten gehörte für mich definitiv dazu – bis mir bei neueren Windows-Server-Versionen aufgefallen ist, dass Microsoft da ordentlich nachgeschärft hat. Seit Windows Server 2025 wird da deutlich genauer hingeschaut, welche EKUs ein Zertifikat überhaupt haben darf, damit es vom RDP-Listener auch akzeptiert und sauber gebunden werden kann. Um das alles reibungslos zu gestalten, ist die korrekte Erstellung von RDP-Zertifikate erstellen unerlässlich. Und ganz ehrlich, es kann ganz schön knifflig werden.
Während ältere Windows-Versionen oft noch kulant waren und reine RDP-Zertifikate akzeptierten, solange die Microsoft-spezifische EKU Remote Desktop Authentication enthalten gewesen ist, erwartet Windows Server 2025 inzwischen zwingend die EKU Server Authentication im CA-Template. Das bedeutet konkret: Ein Template, das vorher funktioniert hat, ist plötzlich nicht mehr zuverlässig für neue Server. Gleichzeitig macht es natürlich Sinn, die Remote-Desktop-EKU weiterhin als optionalen Bestandteil beizubehalten – einfach, damit auch ältere Server noch davon profitieren. Mit der richtigen Konfiguration lassen sich RDP-Zertifikate erstellen, die einfach reibungslos funktionieren.
RDP-Zertifikat: Vor der Erstellung sind diese Punkte zu beachten
Vor Beginn der Konfiguration ist sicherzustellen, dass die erforderlichen Berechtigungen und Zertifikatsvorlagen bereitgestellt sind. Detaillierte Informationen sind in der Microsoft Dokumentation zu finden.
SAN-Attribute: Das A und O für ein korrektes RDP-Zertifikat
Die korrekte Konfiguration der SAN-Attribute ist beim Erstellen von RDP-Zertifikaten von entscheidender Bedeutung. Es ist sicherzustellen, dass sowohl der FQDN als auch der Kurzname des Servers angegeben werden.
Die Umstellung auf das richtige Template ist nur ein erster Schritt. Ein RDP-Zertifikat erfüllt erst dann alle Anforderungen, wenn zusätzlich ein solider Schlüsselalgorithmus (aus praktischen Gründen weiterhin RSA) verwendet wird und die SAN-Einträge korrekt gepflegt werden. Insbesondere die SAN-Attribute – mindestens cn=fqdn, dns=fqdn& und dns=kurzname – verhindern, dass moderne RDP-Clients Warnmeldungen anzeigen.
In diesem Leitfaden zeige ich meinen bewährten Ablauf, mit dem zuverlässig RDP-Zertifikate für Standalone- oder DMZ-Server erstellt werden können – inklusive aller notwendigen Template-Anpassungen und Platzhalter wie cn=fqdn, dns=fqdn& und dns=kurzname. Es entsteht eine sichere Remote-Verbindung, die einfach funktioniert. Bei Interesse, wie grundsätzlich ein neues CA-Template erstellt wird, kann gerne mein rund 10 Jahre alter Artikel helfen Remote Desktop Zertifikatsvorlage erstellen.
Kurz zusammengefasst: Was ich am CA-Template beachte
| Konfigurationselement | Anforderung / Vorgabe |
|---|---|
| Erforderlich | EKU Server Authentication |
| Optional (für Abwärtskompatibilität) | EKU Remote Desktop Authentication |
| Schlüsselalgorithmus | RSA (z.B. 2048/3072/4096) bleibt praxistauglich und breit kompatibel |
| SAN pflegen | mindestens |
Angepasste Anwendungsrichtlinienerweiterung:
(Serverauthentifizierung muss Bestandteil sein!)
Erstellung eines Remote-Zertifikats
Zur Erstellung des Offline-Zertifikats für z.B. ein Standalone Servers, sind die nächsten Schritte entscheidend.
1) INF-Datei auf dem Zielserver erstellen
- Datei als ANSI oder UTF-16 LE speichern
- Keine Leerzeile vor [Version]
- Nur gerade Anführungszeichen
"
Beispiel rdp.inf (Platzhalter anpassen):
[Version]
Signature="$Windows NT$"
[NewRequest]
Subject = "CN=FQDN"
KeyLength = 4096
Exportable = TRUE
MachineKeySet = TRUE
KeyUsage = 0xA0
KeyAlgorithm = RSA
HashAlgorithm = SHA256
RequestType = PKCS10
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication (Pflicht)
OID=1.3.6.1.4.1.311.54.1.2 ; Remote Desktop Authentication (optional)
[Extensions]
2.5.29.17 = "{text}"
_continue_ = "dns=FQDN&"
_continue_ = "dns=Kurzname"
[RequestAttributes]
CertificateTemplate = "TemplateName"Hinweise:
| Werte | Beispiele |
|---|---|
| CN=FQDN | CN=server01.example.tld |
| dns=FQDN& | dns=server01.example.tld& |
| dns=Kurzname | dns=server01 |
| TemplateName | ist der Anzeigename/LDAP-Name deiner CA-Vorlage |
2) CSR lokal erzeugen
(der Private Key bleibt auf dem Zielserver)
certreq -new rdp.inf rdp.reqKommt die Meldung „Template not found“, ist das auf Standalone-Servern normal → OK.
3) CSR auf einem CA-verbundenen System signieren
(Client mit einer gültigen CA-Anbindung)
certreq -submit rdp.req rdp.cerZertifikat wird erstellt und als rdp.cer im selben Verzeichnis gespeichert, in der die rdp.req liegt.
4) Zertifikat auf dem Zielserver installieren
(Standalone Server / System)
certreq -accept rdp.cerAusgabe-Bestätigung wie folgt:
Installed Certificate:
Serial Number: 12xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxa1
Subject: CN=FQDN (DNS Name=FQDN, DNS Name=HOSTNAME)
NotBefore: 24.01.2026 17:00
NotAfter: 23.01.2027 17:00
Thumbprint: e8xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxcafDamit liegt das Zertifikat (inkl. Private Key) automatisch in Cert:LocalMachineMy.
Den Fingerabdruck (Thumbprint) aus der Ausgabe kopieren.
5) Thumbprint nachträglich ermitteln (Platzhalter anpassen)
(optional – falls der Fingerabdruck (Thumbprint) aus Schritt 4 nicht kopiert worden ist!)
Get-ChildItem Cert:LocalMachineMy |
Where-Object { $_.Subject -match "< FQDN-oder-Teilstring >" } |
Select-Object Subject, ThumbprintWichtig: Thumbprint ohne Leerzeichen kopieren (40 Hex-Zeichen).
6) Zertifikat am RDP-Listener binden
$thumbprint = "THUMBPRINT_OHNE_LEERZEICHEN"
# Zertifikat aus dem lokalen Maschinenstore holen
$cert = Get-ChildItem Cert:LocalMachineMy$thumbprint
if (-not $cert) { throw "Zertifikat mit dem Thumbprint wurde nicht gefunden." }
# WMI/CIM Instanz für RDP-Tcp holen
$ts = Get-CimInstance -Namespace root/cimv2/TerminalServices `
-ClassName Win32_TSGeneralSetting `
-Filter "TerminalName='RDP-Tcp'"
# Zertifikat-Hash setzen
Set-CimInstance -InputObject $ts -Property @{ SSLCertificateSHA1Hash = $thumbprint }
# RDP-Dienst neu starten
Restart-Service TermService -ForcePrüfen:
(Get-CimInstance -Namespace root/cimv2/TerminalServices `
-ClassName Win32_TSGeneralSetting `
-Filter "TerminalName='RDP-Tcp'").SSLCertificateSHA1HashDer Wert muss exakt dem Fingerabdruck (Thumbprint) entsprechen.
Typische Stolpersteine – und meine schnellen Fixes
| Problem | Mögliche Ursachen / Lösungen |
|---|---|
| INF wird nicht akzeptiert / Parser-Fehler | Notepad öffnen, als ANSI/UTF-16 LE speichern. Keine Leerzeile vor [Version]. Nur gerade Anführungszeichen („), keine typografischen. |
| „Invalid parameter“ beim Binden | Falscher Thumbprint, kein Private Key, falscher Store oder fehlende EKU. Thumbprint säubern, auf „Sie besitzen einen privaten Schlüssel…“ prüfen, und EKU Server Authentication überprüfen. |
| Zertifikatswarnung im RDP-Client | SAN-Einträge prüfen: |
| Berechtigungen auf dem Private Key | NETWORK SERVICE benötigt Lesezugriff auf den Maschinen-Key. Bei sauberem Enrollment über die Vorlage ist dies in der Regel korrekt. |
Mein Fazit
- Mit der ServerAuth‑EKU im CA‑Template (optional zusätzlich RDA) und RSA als Schlüsselalgorithmus fährt man stabil – auch auf aktuellen Serverversionen.
- Das Offline‑Enrollment mit certreq ist leicht zu dokumentieren, auditierbar und funktioniert unabhängig von der Domänenanbindung.
- Wer SAN konsequent pflegt und beim Binden nur den Hash setzt, kommt zuverlässig ohne RDP-Warnungen ans Ziel.
— Update 09.02.2026 —
Warum?
Durch den Austausch mit dem Blog‑Autor Michael Waterman ist eine wichtige Beobachtung hinzugekommen.
Michael beschreibt in seinem Artikel die Aktualisierung von Remote‑Desktop‑Zertifikaten in Active‑Directory‑Umgebungen. In seinem Test funktionierten dabei weiterhin die klassischen CA‑Vorlagen, die ausschließlich die EKU „Remote Desktop Authentication“ enthalten. Die Zertifikate ließen sich ohne Probleme an den RDP‑Listener unter Windows Server 2025 binden.
Unterschied
Ich arbeite hier mit einem Standalone‑/Workgroup‑Server in einer DMZ. Bei diesem System verweigerte Windows Server 2025 hartnäckig die Bindung von Zertifikaten, die nur die Remote‑Desktop‑EKU enthalten. Erst nachdem ich die Vorlage um die EKU Server Authentication ergänzt hatte, akzeptierte der RDP‑Listener das Zertifikat.
Erkenntnis!
Windows Server 2025 zeigt ein unterschiedliches Verhalten, abhängig davon, ob der Server Mitglied einer Domäne ist oder nicht.
Standalone‑Server:
Erfordern ein Zertifikat mit Server Authentication, damit die Bindung an den RDP‑Listener gelingt.
Domänenmitglieder:
Arbeiten weiterhin problemlos mit Zertifikaten, die nur Remote Desktop Authentication enthalten.
Diese Unterscheidung erklärt, warum ältere Vorlagen in AD‑Umgebungen unverändert funktionieren, während Standalone‑Server seit Windows Server 2025 strengere Anforderungen an die RDP-Zertifikate stellen.
Hinterlasse einen Kommentar
An der Diskussion beteiligen?Hinterlasse uns deinen Kommentar!