8
Zertifikat für Voice-Server erstellen
Guten Abend,
Ich bin im Thema Zertifikaten etc. ein Anfänger. Von daher verstehe ich hier vieles noch nicht und freue mich über ausführliche oder für andere - vielleicht banale - Erklärungen.
Folgendes ist gegeben:
- Windows Server 2019 DC mit CA Authority.
- Linux Ubuntu Server 24 LTS
Der Ubuntu Server dient als TK/SBC/CTI Server.
Dort wird die Software als Web-Adresse zur Verfügung gestellt. Die User können sich die Webadresse dann als WebApp / Verknüpfung speichern. Die Adresse wird mit dem DNS Namen aufgerufen (name.domäne.local).
Damit die Anwendung sauber funktioniert und die Kommunikation verschlüsselt ist, wird hier ein Zertifikat benötigt. Derzeit steht beim Aufruf immer noch "Nicht sicher" im Browser.
Der Domänencontroller hat bereits eine Zertifikatsverwaltung (CA).
Wenn ich das richtig verstehe muss jetzt auf dem Linux Server ein Zertifikats-Request erstellt werden. Wie mache ich das?
Dieses Request (die Datei) muss doch dann irgendwie mit der CA verkettet und am DC beantwortet werden. (Tasks -> "Submit new request"- hat leider alles nicht funktioniert).
Wie gehe ich hier vor?
Und wo muss ich das "fertige" Zertifikat dann ablegen, damit alle Benutzer in der Domäne das Zertifikat erkennen und als vertrauenswürdig einstufen?
Ich wäre über Unterstützung sehr dankbar!
Viele Grüße
Ich bin im Thema Zertifikaten etc. ein Anfänger. Von daher verstehe ich hier vieles noch nicht und freue mich über ausführliche oder für andere - vielleicht banale - Erklärungen.
Folgendes ist gegeben:
- Windows Server 2019 DC mit CA Authority.
- Linux Ubuntu Server 24 LTS
Der Ubuntu Server dient als TK/SBC/CTI Server.
Dort wird die Software als Web-Adresse zur Verfügung gestellt. Die User können sich die Webadresse dann als WebApp / Verknüpfung speichern. Die Adresse wird mit dem DNS Namen aufgerufen (name.domäne.local).
Damit die Anwendung sauber funktioniert und die Kommunikation verschlüsselt ist, wird hier ein Zertifikat benötigt. Derzeit steht beim Aufruf immer noch "Nicht sicher" im Browser.
Der Domänencontroller hat bereits eine Zertifikatsverwaltung (CA).
Wenn ich das richtig verstehe muss jetzt auf dem Linux Server ein Zertifikats-Request erstellt werden. Wie mache ich das?
Dieses Request (die Datei) muss doch dann irgendwie mit der CA verkettet und am DC beantwortet werden. (Tasks -> "Submit new request"- hat leider alles nicht funktioniert).
Wie gehe ich hier vor?
Und wo muss ich das "fertige" Zertifikat dann ablegen, damit alle Benutzer in der Domäne das Zertifikat erkennen und als vertrauenswürdig einstufen?
Ich wäre über Unterstützung sehr dankbar!
Viele Grüße
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 669309
Url: https://administrator.de/contentid/669309
Ausgedruckt am: 23.11.2024 um 08:11 Uhr
8 Kommentare
Neuester Kommentar
Hi,
Zuerst einmal gibt es hier verschiedene Wege, aber der Reihe nach.
Ich empfehle dir die CA nach Möglichkeit weg vom DC zu migrieren und sie im besten Fall zweistufig aufzubauen, da gibt es genug Anleitungen im Netz, Grundlagen müssen jedoch zuerst geschaffen werden, also lies dich ordentlich ein, CA ist ein komplexes Thema. Im besten Fall hast du am Ende eine Offline Root CA, die du als VM auf einen verschlüsselten Stick in einen Safe legst und nur bei Komprimittierung der Issuing CA in Betrieb nimmst.
Das ist aber schon anspruchsvoll. Um auf deine eigentliche Frage einzugehen.
Du kannst per OpenSSL oder auch anderen Tools einen CSR erstellen, hier muss unbedingt der FQDN als CN im Zertifikat auftauchen. Diesen CSR importierst du auf deine CA und lässt sie signieren. Am Ende erhält du das ausgestellte Zertifikat, das schlussendlich importiert werden muss.
Die Vertrauensstellung ergibt sich automatisch, die Windows CA ist in der AD registriert, die Clients sehen sie somit als vertrauenswürdig an, am Ende musst du das ausgestellte Zertifikat noch im richtigen Pfad ablegen, das sollte in Linux unter /etc/ssl/certs importiert werden, kann aber abhängig von der Applikation sein. Da wirst du mit Sicherheit im Netz fündig.
Am Ende musst du wahrscheinlich den Webserverdienst neu starten.
Das waren aus meiner Sicht grob die Schritte. Insbesondere die Erstellung der CSR geht über verschiedene Wege. Such dir da einfach raus, was für dich am einfachsten ist, geht auch mit Powershell, der Kommandozeile oder auch per Webrequest, sofern deine CA mit Webserver konfiguriert wurde.
Zuerst einmal gibt es hier verschiedene Wege, aber der Reihe nach.
Ich empfehle dir die CA nach Möglichkeit weg vom DC zu migrieren und sie im besten Fall zweistufig aufzubauen, da gibt es genug Anleitungen im Netz, Grundlagen müssen jedoch zuerst geschaffen werden, also lies dich ordentlich ein, CA ist ein komplexes Thema. Im besten Fall hast du am Ende eine Offline Root CA, die du als VM auf einen verschlüsselten Stick in einen Safe legst und nur bei Komprimittierung der Issuing CA in Betrieb nimmst.
Das ist aber schon anspruchsvoll. Um auf deine eigentliche Frage einzugehen.
Du kannst per OpenSSL oder auch anderen Tools einen CSR erstellen, hier muss unbedingt der FQDN als CN im Zertifikat auftauchen. Diesen CSR importierst du auf deine CA und lässt sie signieren. Am Ende erhält du das ausgestellte Zertifikat, das schlussendlich importiert werden muss.
Die Vertrauensstellung ergibt sich automatisch, die Windows CA ist in der AD registriert, die Clients sehen sie somit als vertrauenswürdig an, am Ende musst du das ausgestellte Zertifikat noch im richtigen Pfad ablegen, das sollte in Linux unter /etc/ssl/certs importiert werden, kann aber abhängig von der Applikation sein. Da wirst du mit Sicherheit im Netz fündig.
Am Ende musst du wahrscheinlich den Webserverdienst neu starten.
Das waren aus meiner Sicht grob die Schritte. Insbesondere die Erstellung der CSR geht über verschiedene Wege. Such dir da einfach raus, was für dich am einfachsten ist, geht auch mit Powershell, der Kommandozeile oder auch per Webrequest, sofern deine CA mit Webserver konfiguriert wurde.
- Windows Server 2019 DC mit CA Authority.
- Linux Ubuntu Server 24 LTS
Warum macht der DC "CA" ? - finde ich fatal - hier sollte eine separate CA gewählt werden..- Linux Ubuntu Server 24 LTS
Der Ubuntu Server dient als TK/SBC/CTI Server.
What?.. Was habt Ihr für eine Telefonanlage - wurde nicht erwähnt....
Dort wird die Software als Web-Adresse zur Verfügung gestellt. Die User können sich die Webadresse dann als WebApp / Verknüpfung speichern. Die Adresse wird mit dem DNS Namen aufgerufen (name.domäne.local).
Damit die Anwendung sauber funktioniert und die Kommunikation verschlüsselt ist, wird hier ein Zertifikat benötigt.
Damit die Anwendung sauber funktioniert und die Kommunikation verschlüsselt ist, wird hier ein Zertifikat benötigt.
Derzeit steht beim Aufruf immer noch "Nicht sicher" im Browser.
Damit sie im Browser "sicher" erscheinen, mußt Du das Zertifikat in die "Vertrauenswürdigen Stammzertifizierungsstellen" auf jedem Client installieren (geht auch via GPO)
Der Domänencontroller hat bereits eine Zertifikatsverwaltung (CA).
Wenn ich das richtig verstehe muss jetzt auf dem Linux Server ein Zertifikats-Request erstellt werden. Wie mache ich das?
Dieses Request (die Datei) muss doch dann irgendwie mit der CA verkettet und am DC beantwortet werden. (Tasks -> "Submit new request"- hat leider alles nicht funktioniert).
Wie gehe ich hier vor?
Wie gehe ich hier vor?
Was hast Du für eine TK? - Wo ist Dein Support?
Und wo muss ich das "fertige" Zertifikat dann ablegen, damit alle Benutzer in der Domäne das Zertifikat erkennen und als vertrauenswürdig einstufen?
Bitte beantworte die offenstehenden Fragen..
Ich wäre über Unterstützung sehr dankbar!
Viele Grüße
Viele Grüße
Ich helfe Dir gerne,
Gruss Globe!
Damit sie im Browser "sicher" erscheinen, mußt Du das Zertifikat in die "Vertrauenswürdigen Stammzertifizierungsstellen" auf jedem Client installieren (geht auch via GPO)
Das ist nicht nötig, wenn die CA Member der Domäne ist. Die ist dann automatisch vertrauenswürdig, das sorgt aber nicht dafür dass ein Aufruf per HTTP(s) mit einer sicheren Verbindung quittiert wird. Dafür muss der entsprechende Webserver sich mit einem vertrauenswürdigen Zertifikat ausweisen, welches von einer CA ausgestellt wird, denen die Clients trauen, GPO ist nur bei externen CAs notwendig.
Hi AK-XY ?
Kennst Du seine Umgebung ? - Ich nicht..
Gruss Globe!
Kennst Du seine Umgebung ? - Ich nicht..
Gruss Globe!
Hi Globejackson,
du hast doch im vorherigen Post geschrieben, wie ich auch, dass es keine gute Idee ist die CA auf den DC zu legen. Der ist logischerweise Mitglied der Domäne und wird als CA in dieser registriert. Das ist der Kenntnisstand zu den bisherigen, mageren Informationen zum Netz und der Domäne.
Damit ist dieser für die Clients vertrauenswürdig.
Aber ich gebe dir recht, schaden kann die GPO nicht.
du hast doch im vorherigen Post geschrieben, wie ich auch, dass es keine gute Idee ist die CA auf den DC zu legen. Der ist logischerweise Mitglied der Domäne und wird als CA in dieser registriert. Das ist der Kenntnisstand zu den bisherigen, mageren Informationen zum Netz und der Domäne.
Damit ist dieser für die Clients vertrauenswürdig.
Aber ich gebe dir recht, schaden kann die GPO nicht.
Aber ich gebe dir recht, schaden kann die GPO nicht.
AK-4711 ?
Dann sind wir uns einig - der TO muss liefern..
Gruss Globe!
Certmonger kann das ähnlich dem Autorenrollment von Windows Servern automatisieren.
Ansonsten müsste man wissen, wie der Webserver heißt.
Ansonsten müsste man wissen, wie der Webserver heißt.
Servus @ApoCalyps3.
Achtung: Die minimale Schlüssellänge sollte dabei nur angepasst werden wenn man für die Generierung des private Keys unter Linux ECDSA-Keys verwenden möchte.
Voraussetzung hierfür ist eines halbwegs installiertes openssl auf halbwegs aktuellem Stand. Man öffne einen Terminal und erstelle den Private-Key und Request mittels folgender Befehle (je nach gewünschtem Key eine Variante wählen):
Dabei sind der FQDN des Servers anzupassen, als auch der Name des Zertifikats-Templates den wir in der CA vergeben haben. Die Dateinamen für den private Key als auch des Requests lässt sich ebenfalls nach eigenem Gusto anpassen.
Den erstellen Signing-Request (CSR) kopieren wir nun auf die CA. Dort reichen wir ihn bei der CA ein.
Im Dialog übergibt man den Dateipfad zum Request und erhält dann die Möglichkeit das ausgestellte Zertifikat zu speichern. Diese kopieren wir zurück auf den Linux-Server.
Damit der Linux-Server unserer CA vertraut exportieren wir zusätzlich das CA-Zertifikat in eine Datei, welches wir gleich auf dem Linux-Server in die vertrauenswürdigen Stammzertifizierungsstellen importieren werden.
Bitte darauf achten das man dem CA-Zertifikat die Endung.crt verpasst, das wird wichtig wenn wir das Zertifikat gleich importieren.
Der folgende Step ist zwar optional, aber es ist immer gut wenn der Server selbst der CA auch vertraut von der er selbst Zertifikate verwendet. Die geschilderte Variante ist auf Debian-/Ubuntu-Servern anwendbar, auf anderen Linux kann diese aber leicht abweichen.
Wir kopieren das CA-Zertifikat als erstes in den entsprechenden Ordner den der Update-Prozess auf neue Root-Zertifikate prüft.
und importieren dieses dann mittels
in den Trust-Store des Servers. Sollte hier gemeldet werden das kein Zertifikat importiert wurde hat das Zertifikat entweder keine *.crt Endung oder jemand hat es bereits importiert.
Abschließend verifizieren wir noch das unserem Server-Zertifikat nun vertraut wird:
Eine positive Rückmeldung von openssl sollte uns das bestätigen.
Wenn man das ganze dagegen auf einer Windows-Maschine vollziehen möchte ist die folgende Variante ein Weg zum Ziel. Das Erstellen des Templates erspare ich mir hier, dazu kann das oben bereits erstellte Template genutzt werden, wobei man die Schlüssellänge hier wieder auf 2048 setzen sollte sonst gibt es ohne weitere Anpassung des Templates einen Fehler beim Erstellen über die MMC.
Wir erstellen uns eine MMC mit den Maschinen-Zertifikaten und fordern dort ein neues Zertifikat an:
geben unsere Details für das auszustellende Zertifikat an
und klicken dann abschließend auf "Registrieren". Das Zertifikat sollte nun in der MMC unter "Eigene Zertifikate > Zertifikate" auftauchen, über das Kontextmenü exportieren wir dieses nun wie gehabt inklusive private Key und vergeben ein Export-Passwort.
Auf dem Linux Server wird in der Regel der private als auch der public Key des Zertifikates als getrennte Dateien benötigt. Das konvertieren des *.pfx Containers erledigen wir hier im Terminal erneut mit dem Schweizer-Messer für Zertfikate openssl.
Das CA Zertifikat importieren wir wie in Variante A unter "Import des CA Zertifkats auf dem Linux-Server" beschrieben auf dem Linux-Server in den lokalen Trust-Store.
Je nach verwendeter Server-Anwendungen müssen Zertifikat und Private-Key dann in die passenden Verzeichnisse kopiert und in der Konfiguration auf diese verwiesen werden. Nach einem abschließendem Neustart des jeweiligen Dienstes, sollten diese verwendet werden.
Hoffe das gibt dir einen kleinen Überblick wir das Prozedere in d. Regel aussieht.
Falls du Fragen hast zögere nicht diese hier zu stellen.
Grüße Uwe
Wenn ich das richtig verstehe muss jetzt auf dem Linux Server ein Zertifikats-Request erstellt werden. Wie mache ich das?
Es gibt hier natürlich diverse Varianten. Ich greife hier mal zwei möglich davon auf, und zwar absichtlich erst einmal ohne dabei auf Drittanbieter-Tools zurückzugreifen, damit der TO auch davon auch etwas mitnehmen kann:
Variante A: Generieren des Certificate-Signing-Requests direkt auf der Linux-Maschine und Einreichung des CSR in der MS Zertifizierungsstelle
Anlegen eines passenden Certificate-Templates auf der CA
Duplizieren der Vorhandenen WebServer-Vorlage
Anpassen von Eigenschaften für die Registrierung
Achtung: Die minimale Schlüssellänge sollte dabei nur angepasst werden wenn man für die Generierung des private Keys unter Linux ECDSA-Keys verwenden möchte.
Erstellen des Private-Key und Certificate-Request auf dem Linux-Server
Voraussetzung hierfür ist eines halbwegs installiertes openssl auf halbwegs aktuellem Stand. Man öffne einen Terminal und erstelle den Private-Key und Request mittels folgender Befehle (je nach gewünschtem Key eine Variante wählen):
- Für ECDSA-Keys
openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:P-256 -keyout server.key -out server.req -addext "keyUsage=critical,digitalSignature,keyEncipherment" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth" -addext "subjectAltName=DNS:mydomain.tld" -subj "/CN=mydomain.tld" -addext "1.3.6.1.4.1.311.20.2=ASN1:PRINTABLESTRING:Linux-Webserver" -nodes -sha256- Für RSA Keys
openssl req -new -newkey RSA:4096 -keyout server.key -out server.req -addext "keyUsage=critical,digitalSignature,keyEncipherment" -addext "basicConstraints=critical,CA:FALSE" -addext "extendedKeyUsage=serverAuth" -addext "subjectAltName=DNS:mydomain.tld" -subj "/CN=mydomain.tld" -addext "1.3.6.1.4.1.311.20.2=ASN1:PRINTABLESTRING:Linux-Webserver" -nodes -sha256Dabei sind der FQDN des Servers anzupassen, als auch der Name des Zertifikats-Templates den wir in der CA vergeben haben. Die Dateinamen für den private Key als auch des Requests lässt sich ebenfalls nach eigenem Gusto anpassen.
Einreichen des Requests an der CA
Den erstellen Signing-Request (CSR) kopieren wir nun auf die CA. Dort reichen wir ihn bei der CA ein.
Im Dialog übergibt man den Dateipfad zum Request und erhält dann die Möglichkeit das ausgestellte Zertifikat zu speichern. Diese kopieren wir zurück auf den Linux-Server.
Damit der Linux-Server unserer CA vertraut exportieren wir zusätzlich das CA-Zertifikat in eine Datei, welches wir gleich auf dem Linux-Server in die vertrauenswürdigen Stammzertifizierungsstellen importieren werden.
Bitte darauf achten das man dem CA-Zertifikat die Endung.crt verpasst, das wird wichtig wenn wir das Zertifikat gleich importieren.
Import des CA Zertifikats auf dem Linux-Server
Der folgende Step ist zwar optional, aber es ist immer gut wenn der Server selbst der CA auch vertraut von der er selbst Zertifikate verwendet. Die geschilderte Variante ist auf Debian-/Ubuntu-Servern anwendbar, auf anderen Linux kann diese aber leicht abweichen.
Wir kopieren das CA-Zertifikat als erstes in den entsprechenden Ordner den der Update-Prozess auf neue Root-Zertifikate prüft.
sudo cp ca.crt /usr/local/share/ca-certificates/sudo update-ca-certificatesAbschließend verifizieren wir noch das unserem Server-Zertifikat nun vertraut wird:
openssl verify server.cerserver.cer OK
Variante B: Erstellen des Zertifikats auf einer Windows-Maschine inkl. anschließendem Export und Umwandlung für den Linux Server
Wenn man das ganze dagegen auf einer Windows-Maschine vollziehen möchte ist die folgende Variante ein Weg zum Ziel. Das Erstellen des Templates erspare ich mir hier, dazu kann das oben bereits erstellte Template genutzt werden, wobei man die Schlüssellänge hier wieder auf 2048 setzen sollte sonst gibt es ohne weitere Anpassung des Templates einen Fehler beim Erstellen über die MMC.
Ausstellen des Zertifikates über eine MMC
Wir erstellen uns eine MMC mit den Maschinen-Zertifikaten und fordern dort ein neues Zertifikat an:
geben unsere Details für das auszustellende Zertifikat an
und klicken dann abschließend auf "Registrieren". Das Zertifikat sollte nun in der MMC unter "Eigene Zertifikate > Zertifikate" auftauchen, über das Kontextmenü exportieren wir dieses nun wie gehabt inklusive private Key und vergeben ein Export-Passwort.
Extrahieren von Private- und Public-Key auf dem Linux Server
Auf dem Linux Server wird in der Regel der private als auch der public Key des Zertifikates als getrennte Dateien benötigt. Das konvertieren des *.pfx Containers erledigen wir hier im Terminal erneut mit dem Schweizer-Messer für Zertfikate openssl.
# export CA public key
openssl pkcs12 -in server.pfx -out ca.crt -nokeys -cacerts
# export server public key
openssl pkcs12 -in server.pfx -out server.pem -nokeys -clcerts
# export private key
openssl pkcs12 -in server.pfx -out server.key -nocerts -nodesJe nach verwendeter Server-Anwendungen müssen Zertifikat und Private-Key dann in die passenden Verzeichnisse kopiert und in der Konfiguration auf diese verwiesen werden. Nach einem abschließendem Neustart des jeweiligen Dienstes, sollten diese verwendet werden.
Hoffe das gibt dir einen kleinen Überblick wir das Prozedere in d. Regel aussieht.
Falls du Fragen hast zögere nicht diese hier zu stellen.
Grüße Uwe
1
