Diese Artikel beschreib einen Zertifikatswechsel mit Hilfe der Unternehmens PKI. Das neue Zertifikat wird über die Unternehmens CA beantragt. Dann wird das Zertifikat auf dem Sessionbroker und auf den RDS-Servern (Terminal Server) ausgerollt.
Dies ist Draft 1 und wird wenige Tage anch dem Wechsel erstellt. Evtl. vergesse ich irgendwas. Den nächsten Zertifikatswechsel werde ich anhand dieses Artikels durchführen und Abweichungen korrigieren.
Alle Dateien, die wir hier erstellen bitte in demselben Verzeichnis speichern.
1. CSR erstellen
Den CSR erstelle ich gerne einfach mit OpenSSL. Das wichtigste ist hier der Common Name. Es muss die Domäne angegeben werden, unter der das Active Directory läuft (CN=*.domäne.de). Wir erstellen das Zertifikat mit 1024 Bit, da wir in der PKI die Zertifikatvorlage „Webserver“ verwenden. Die basiert auf Schemaversion 1.0. Etwas anderes unterstützt der IIS Dienst certsrv nicht. Wenn die Vorlage „Webserver“ nicht wählbar ist, siehe Apendix.
openssl req -out CSR.csr -new -newkey rsa:1024 -keyout privateKey.key Generating a RSA private key …………………………………………………………………++++ …………………………………………………………………………………………………….++++ writing new private key to 'privateKey.key' Enter PEM pass phrase: Verifying - Enter PEM pass phrase: (PW für den private Key) You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. Country Name (2 letter code) [XX]:DE State or Province Name (full name) []:Land Locality Name (eg, city) [Default City]:Stadt Organization Name (eg, company) [Default Company Ltd]:Company Name Organizational Unit Name (eg, section) []: leer lassen Common Name (eg, your name or your server's hostname) []:*.domain.de Email Address []: leer lassen Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: leer lassen An optional company name []: leer lassen
Es werden dabei 2 Dateien erstellt:
- Der Certificate Signing Request
- Der private Key
Für den privaten Key muss ein Passwort vergeben werden. Damit wird der Key kryptografisch verschlüsselt.
Den Certificate Signing Request reichen wir im nächsten Schritt bei der Unternehmen CA ein.
2. CSR einreichen
Ein Unternehmen hat normahlerweise eine Unternehmens-PKI. Also eine Certificate Authority, dem das Unternehmen vertraut. Das CA zertifikat wird normalerweise über die Default Domain Policy an die Clients verteilt. Wenn das nicht der Fall ist, muss das nachgeholt werden.
Die CA ist eine Windows Server Rolle, die auf einem Windows Server einfach installiert werden kann. Nennt sich Zertifikatsdienste oder sowas, will jetzt nich nachsehen. Bei kleineren Unternehmen läuft das oft auf dem Domaincontroller.
Wir rufen das Webinterface der CA auf:
Es werden Zugangsdaten verlangt. Hier einen Domänen-Admin angeben. Dann klicken auf „Zertifikat anfordern“->“erweiterte zertifikatsanforderung“. Als zertifikatvorlage wählen wir „Webserver“. Nun öffnen wir die oben generierte Datei CSR.csr, kopieren den kompletten Inhalt und fügen diesen hier ein unter „gespiecherte Anforderung“. Dann auf „Einsenden“ klicken.
Im nächsten Schritt werden wir gefragt, ob wir das Zertifikat DER-Codiert oder Base64-Codiert (PEM) speichern wollen. Wir wählen Base64 (PEM). Dies ist der öffentliche Key für das Zertifikat. Es bildet zusammen mit dem privaten Schlüssel aus Schritt 1 das private/public Keypair. Die gehören also untrennbar zusammen. Windows benötigt aber beide Dateien zusammengefasst in einer PFX-Datei. Diese erstellen wir im nächsten Schritt.
3. PFX-Datei erstellen
Wir haben ja alle Dateien im selben Verzeichnis, gelle? Also über die Shell in das Verzeichnis wechseln und folgenden Befehl eingeben:
openssl pkcs12 -inkey privateKey.key -in certnew.crt -export -out cert.pfx Enter pass phrase for private.key: Enter Export Password: Verifying - Enter Export Password:
Als Passwort wird 3 Mal das PW des privaten Keys eingegeben. Der private Key wird ja in die PFX integriert.
4. Zertifikat auf Session Broker bereitstellen
Über den Session Broker konfiguriert man die Remote Desktop Services im Idealfall. Wir kopieren die PFK auf den Desktop des Session Brokers, öffnen den Server Manager, wählen den Punkt Remotedesktop-Dienste. Im Unterpunkt Sammlungen wählen wir rechts Bereitstellungseigenschaften bearbeiten.
Pro Rollendienst klicken wir auf „vorhandenes Zertifikat auswählen…“, wählen das PFX, geben das PW ein und klicken auf Anwenden. Danach sollte für alle Rollendienste der Status „OK“ sein und die Stufe „Vertrauenswürdig“.
5. Zertifikatwechsel auf den RDS-Servern
ACHTUNG: wird ein neuer RDS-Server aus einem Goldenimage geklont, muss das Zertifikat erneut importiert werden, da der private Schlüssel bei dem Clonvorgang verloren geht.
Kurz mal etwas Theorie:
Wenn sich alle Clients über den Session Broker verbinden reicht das schon aus. Kommen mehere RDS-Server zum Einsatz gibt es meistens ein DNS Round Robin. Man hat also einen DNS Namen, wie z.B. wts.domäne.de für jede einzelne Server IP im DNS hinterlegt. Wenn sich nun ein Client mit den RDS verbindet, kontaktiert er auf Zufallsbasis eine der hinterlegten IP’s. Der Server, zum dem die IP gehört, leitet die Anfrage zum Session Broker um. Der Session Broker guckt nach, wie die Lastverteilung ist und weist die Anfrage dann einem Server mit wenig Last zu.
Die initiale Verbindung geschieht also nicht zu dem Session Broker, sondern zu einem zufälligen RDS-Server. Dieser liefert erstmal sein eigenes RDS Zertifikat aus. Und damit ist klar, wieso wir auch die RDS-Server mit dem Zertifikat betanken müssen.
Bei der Übergabe vom Session Broker an einen RDS-Server findet übrigens keine erneute Zertifikatsprüfung statt. Die Verbindung wird verschlüsselt übergeben, wie auch immer das intern funktioniert.
So, nun schreiten wir zur Tat. Bitte auf jedem Server folgende Schritte ausführen.
5.1 Zertifikat importieren
Wir öffnen die MMC, öffnen das zertifikate Snap-In, wählen den lokalen Computer, gehen unter Eigene Zertifikate->Zertifikate und importieren dort das PFX. Oder alternativ:
CERTUTIL -f -p passwort -importpfx "somePfx.pfx"5.2 Zertifikat für RDP Dienste setzen
jedes Zertifikat hat einen einzigartigen Fingerabdruck. Diesen Fingerabdruck brauchen wir nun. Wir klicken im Zertifikate Snap-In doppelt auf das Zertifikat und können im Tab Details den Fingerabdruck raus kopieren:
Dann führen wir folgenden Befehl aus, um das Zertifikat für den RDP Dienst zu setzen:
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="5d3b7b021633953e49631190727e29e9eac92dcd"
Der Fingerabdruck ändert sich für dieses Zertifikat nicht. Man kann den Befehl also auf allen Servern ausführen, hat man sich einmal den Fingerabdruck besorgt.
Appendix
Anpassung des Zertifikatstemplates „Webserver“
ACHTUNG: ich wollte hier eigentlich erklären, wie man eine mordne Zertifikatvorlage erstellt. Dabei stellte sich heraus, dass die IIS Webseite certsrv bis mindestens Server 2012R2 nur Zertifikate der Schemaversion 1 unterstützt. Folgende Zeilen habe ich dazu im Netz gefunden, nachdem ich mich wunderte, warum das neue Template nicht in der Liste auftaucht:
The two most common problems I see with this are either permissions related or template version related.
The user logged into the certsrv site needs to have both Read and Enroll permissions on the certificate template. If they don’t, it won’t show up in the list of available templates.
Also when duplicating the template, you were likely asked what version to make it and given an option of „Windows Server 2003“ or „Windows Server 2008“. The certsrv web site is only compatible with the Windows Server 2003 based templates which I think corresponds to version 2. Ironically, this same limitation is present all the way through Windows Server 2012 R2. The certsrv site still can’t use version 3 templates.
Das Standardtemplate „Webserver“ basiert auf der Schemaversion 1.0, was sogar noch für WindowsXP kompatibel ist. Wir werden diese Vorlage nun duplizieren und das neue Zertifikat mit einer neuen Schemaversion anpassen. In diesem Beispiel mit der Version 4.0 für mindestens Windows Server 2012R2, bzw. Windows 8.1. Dazu öffnen wir das MMC für die Zertifikatsvorlagen:
certtmpl.msc
Rechtsklick auf das Template „Webserver“->duplizieren. Es öffnen sich die Eigenschaften der neuen Vorlage. Die Kompatibilitätseinstellungen werden angepasst:
Unter dem Reiter Allgemein wird der Vorlagenname angepasst. Auch kann hier die Gültigkeitsdauer angepasst werden, falls gewünscht.
Unter dem Reiter Sicherheit wird nun definiert, wer anhand dieser Vorlage Zertifikate anfordern darf. In Deutsch heißt der Punkt „Registrieren“, im Englischen etwas bezeichnender „Enroll“, also ausrollen.
