Windows Admin Center 1809 selfsigned Zertifikat installieren und verteilen

The estimated reading time 3 minutes

Windows Admin Center 1809 selfsigned Zertifikat installieren und verteilen

Hallo zusammen,

da nun immer mehr WAC (Windows Administrative Center) Implementierungen aufkommen, habe ich mir heute die Frage gestellt, ob und wie es möglich ist das Zertifikat innerhalb des WAC zu tauschen, bzw. zu erneuern.

Für mein Testszenario habe ich mit OpenSSL und einer Konfigrationsdatei ein SSL Zertifikat für meinen WAC Server erstellt. Kann aber auch mit einem offiziellen Zertifikat so durchgeführt werden.

Ziel also folgendes Setup innerhalb der Domäne.

Meine Konfigurationsdatei sieht aktuell so aus.

###### config file

[req]

default_bits = 2048 prompt = no default_md = sha256 x509_extensions = v3_req distinguished_name = dn

[dn]

C = DE ST = BW L = Mengen O = IT emailAddress = XX@demo01.it-koehler.com CN = wac01-74.demo01.it-koehler.com

[v3_req]

subjectAltName = @alt_names

[alt_names]

DNS.1 = demo01.it-koehler.com DNS.2 = *.demo01.it-koehler.com DNS.3 = wac01-74 DNS.4 = localhost

OpenSSL mit folgenden Parametern starten (kann auf einem Rechner gestartet werden).

openssl req -new -x509 -newkey rsa:2048 -sha256 -nodes -keyout "C:\temp\wac01-74.key" -days 3560 -out "C:\temp\wac01-74.crt" -config "C:\temp\wildcard.cfg"

Danach noch umwandeln in eine PFX Datei (mit Passwort):

openssl pkcs12 -export -out "C:\temp\wac01-74.pfx" -inkey "C:\temp\wac01-74.key" -in "C:\temp\wac01-74.crt"

Nun sollte im angegebenen Verzeichnis folgende Dateien vorhanden sein.

Diese PFX Datei kann nun auf dem WAC Server eingespielt werden. Dazu auf die Festplatte des Servers kopieren und das PFX auf dem Server installieren.

Der Schlüssel muss nicht zwingend exportierbar markiert werden, das kann aber unter Umständen helfen, falls die Originaldatei /Passwort verloren geht.

Die Datei muss in den Persönlichen Speicher der WAC Maschine geladen werden.

Für die Installation des Zertifikates benötigt man den Fingerabdruck (auf englisch Thumbprint)

Dieser lässt sich einfach per Powershell oder über die MMC (certlm.msc) auslesen.

Hier die Powershell Variante.

Get-ChildItem -Path cert:\LocalMachine\My\

In meinem Fall ist der Fingerabdruck schnell identifiziert.

Nun auf dem WAC Server die Installation des WAC nochmals starten (Install). Die bisherige Konfiguration bleibt vorhanden!

SSL Gateway Zertifikat mit dem kopierten Fingerabdruck ersetzen und dann „Ändern“.

Nur weil wir das Zertifikat auf dem Server installiert haben, heißt das noch lange nicht, dass dieses auch vertrauenswürdig ist. Deshalb erscheint nun beim aufrufen diese nette Warnung im Chrome.

Nun gibt es mehrere Möglichkeiten das Selfsigned Zertifikat zu verteilen. In meiner Demo Domäne entscheide ich mich für die Verteilung per GPO.

Dazu GPO Verwaltung auf dem DC öffnen und eine neue GPO erstellen.

In diese muss dann das Zertifikat bei Vertauenswürdige Stammzertifizierungsstellen importiert werden (dazu die vorher erstellte .CRT Datei auf einem Share oder auf den DC legen).

Diese GPO kann nun auf die Server/Client OU Verlinkt werden, dass das Zertifikat auf den gewünschten Maschinen als gültig erkannt wird.

Noch ein GPUPDATE /Force auf der Maschine hinterher und tadaa der Zugriff aufs WAC funktioniert ohne unschöne Zertifikatsmeldung.

Das Zertifikat sollte nun auch im WAC auftauchen.

Auf den anderen Servern kann nun ebenfalls mit dem richtigen Zertifikat zugegriffen werden (vorausgesetzt die GPO wird auf diesen angewendet).

Viel Spaß beim nachbauen, wenn euch der Artikel gefallen hat, dann drückt auf „Helpful“.

Vielen dank.

Was this article helpful?
YesNo
5 1 vote
Article Rating
Abonnieren
Benachrichtige mich bei
guest
8 Comments
Newest
Oldest Most Voted
Inline Feedbacks
View all comments
nwwt
nwwt
17 Tage zuvor

Die Darstellung der Konfigurationsdatei hat es über die Jahre leider zerschossen.

Wenn ich sie (entspr. abgeändert) mir ohne Leerzeilen zusammenfüge, kommt leider auch:

Error: No objects specified in config file
Error making certificate request
nwwt
nwwt
Reply to  nwwt
13 Tage zuvor

Okay, hab dann doch begriffen, dass alles bloß auf eine eigne Zeile muss.

[v3_req] lässt sich noch ergänzen um:

extendedKeyUsage = serverAuth, clientAuth

(so macht’s auch das WAC-eigne Testzertifikat)

Arg komisch ist WAC v2410 schon. Mit 2048bit sha512 produzierte RSA-Zertifikate funktionieren, RSA mit 4096bit geschweige AES (prime256v1) verweigert der Server/Installer bei mir geflissentlich (→ Browserfehler, da WAC dann gar kein Zertifikat anbietet).

WinRM-over-HTTPs (bei dem prime256v1 funktioniert) ist ebenso sehr komisch. Ich habe WAC als Gateway auf einem Server A, und steuere damit ihn selbst plus Server B. Auf B kann ich den HTTP-Listener löschen. Auf A hingegen läuft WAC weiter, beim Aufrufen des eignen Eintrags zerbricht es dann aber (wahlweise u. a.: Einloggen schlägt fehl, ajax 400). Nicht mal den generellen Listener durch einen auf die Loopback-Adressen beschränkten funktioniert.

Daniel
Daniel
3 Jahre zuvor

Hi Danke für die tolle Anleitung. Leider habe ich auf keinen Server / Client Zugriff es kommt immer die Meldung das Winrm Quickconfig ausgeführt werden soll.

Die Firewall und die Windows Remoteverwaltung läuft allerdings ohne Probleme…

Was kann das Problem sein?

Daniel
Daniel
Reply to  A.K.
3 Jahre zuvor

Hallo Danke für die Antwort.

Ich bin jetzt soweit das HTTPS nicht ohne AD Zertifizierungsstelle funktioniert. Sprich ohne Zertifikate auf den Zielhosts funktioniert WinRM nicht. Können Sie das bestätigen? Haben Sie die AD Zertifizierungsstelle im Einsatz?

Viele Grüße
Daniel

Daniel
Daniel
Reply to  A.K.
3 Jahre zuvor

Hallo Herr Köhler,

hier nochmal da der Kommentar verschwunden ist. Ich bin mir nach Recherche sicher das es daran liegt das keine AD Zertifizierungsstelle eingerichtet ist und somit die Verbindung über HTTPS auf die Zielrechner nicht funktioniert. Nutzen Sie selber ein AD Zertifizierungsstelle und können das bestätigen? WinRM lässt sich per HTTPs nicht konfigurieren.

Viele Grüße
Daniel