Auch die Kommunikation zu internen Diensten sollte verschlüsselt erfolgen. Selbstsignierte Zertifikate verursachen jedoch Warnmeldungen in den Anwendungen der Nutzer, allen voran Webbrowsern. Das Open-Source-Toolset FreeIPA mit dem integrierten Zertifikatsmanagement Dogtag erlaubt es Ihnen, mit wenig Aufwand SSL/TLS-Zertifikate für Intranetdienste zu erzeugen und im Netzwerk bekannt zu machen.
Interne wie auch externe Dienste verwenden durch die Bank eine verschlüsselte Kommunikation mit SSL und TLS. Bei externen Services greifen die Administratoren auf offiziell signierte Zertifikate zurück, wobei vielerorts auch Let's Encrypt völlig ausreicht. Bei internen Diensten auf der anderen Seite kommen überwiegend selbstsignierte Zertifikate zum Einsatz, die bei den Webbrowsern im LAN stets für Unmut sorgen und Meldungen wie "Ihre Verbindung ist nicht sicher" hervorrufen.
Nun möchten Administratoren aber auch bei Intranetanwendungen ein schönes Schlosssymbol für eine vertraute TLS-Verbindung im Browser sehen, anstatt den Nutzern zuzumuten, dass sie für jede einzelne interne Anwendung eine individuelle Ausnahme im Browser anlegen. Das lässt dann auch striktere Sicherheits-Policies für Browser im Unternehmens-LAN zu, sodass diese unvertraute Verbindungen überhaupt nicht mehr öffnen und auch keine Ausnahmeregeln erstellen können. Auch andere interne Dienste sollten mit vertrauenswürdigen Zertifikaten und SSL kommunizieren.
Alles, was Sie dafür brauchen, ist eine eigene CA (Certificate Authority) im Intranet, die für die angebundenen Dienste Zertifikate verwaltet und signiert. Interne Rechner müssen dann nur dieser eigenen Root-CA vertrauen, damit alle von ihr signierten Schlüssel als gütig anerkannt werden.
Interne wie auch externe Dienste verwenden durch die Bank eine verschlüsselte Kommunikation mit SSL und TLS. Bei externen Services greifen die Administratoren auf offiziell signierte Zertifikate zurück, wobei vielerorts auch Let's Encrypt völlig ausreicht. Bei internen Diensten auf der anderen Seite kommen überwiegend selbstsignierte Zertifikate zum Einsatz, die bei den Webbrowsern im LAN stets für Unmut sorgen und Meldungen wie "Ihre Verbindung ist nicht sicher" hervorrufen.
Nun möchten Administratoren aber auch bei Intranetanwendungen ein schönes Schlosssymbol für eine vertraute TLS-Verbindung im Browser sehen, anstatt den Nutzern zuzumuten, dass sie für jede einzelne interne Anwendung eine individuelle Ausnahme im Browser anlegen. Das lässt dann auch striktere Sicherheits-Policies für Browser im Unternehmens-LAN zu, sodass diese unvertraute Verbindungen überhaupt nicht mehr öffnen und auch keine Ausnahmeregeln erstellen können. Auch andere interne Dienste sollten mit vertrauenswürdigen Zertifikaten und SSL kommunizieren.
Alles, was Sie dafür brauchen, ist eine eigene CA (Certificate Authority) im Intranet, die für die angebundenen Dienste Zertifikate verwaltet und signiert. Interne Rechner müssen dann nur dieser eigenen Root-CA vertrauen, damit alle von ihr signierten Schlüssel als gütig anerkannt werden.
Eine simple Methode, um eine interne CA zu verwalten, liefert das Open-Source-Zertifikatsystem Dogtag [1], das sich nahtlos in das Benutzer-Directory FreeIPA [2] integriert. FreeIPA ist für Linux, was das Active Directory (AD) in der Windows-Welt darstellt. Es verwendet die gleiche Technologie mit einem LDAP-Backend und der Kerberos-Authentisierung. AD und IPA können einander via Cross Domain Trusts vertrauen, sodass Administratoren heterogener Netzwerke ein verbundenes Directory für Windows- und Linux-Maschinen betreiben können.
In diesem Artikel gehen wir auf die Basisfunktionen von FreeIPA ein und legen den Schwerpunkt auf Dogtag. Jeder Administrator einer Umgebung mit mehreren Linux-Servern sollte ohnehin ein IPA-Directory für die zentrale Nutzer-, Host- und Dienstverwaltung betreiben, wie es in Windows-Netzwerken mit dem AD auch üblich ist.
FreeIPA-Server installieren
Für das Setup des IPA-Servers verwenden wir eine Enterprise-Linux-Distribution in der Version 8 (EL8) wie Rocky- oder AlmaLinux. Der Installationstyp "Minimal" reicht völlig aus. Das Setup bedarf keiner besonderen Repositories wie EPEL, da alle benötigten Pakete im "Appstream"-Repository jeder EL8-Distribution zu finden sind. Der IPA-Server sollte über eine statische IP-Adresse verfügen. Sein DNS-Name muss korrekt konfiguriert sein und die DNS-Auflösung im LAN muss stimmen (forward und reverse lookup). Die Konfiguration der Zeitzone muss passen und der Server sollte via Crony die Zeit mit den Timeservern im Internet abstimmen.
Der Free-IPA-Server ist unter dem Namen "idm" (Identiti Management) als Modul im Appstream-Repository registriert. Als "Versionen" davon gibt es den Server und den Client. Via "dnf" aktivieren Sie das Servermodul und richten die benötigten Pakete ein:
dnf module enable idm:DL1
dnf distro-sync
dnf module install idm:DL1/server
Die eigentliche Installation erfolgt interaktiv mit dem Kommando:
ipa-server-install
Alternativ können Sie dem Kommando auch gleich alle Parameter auf der Kommandozeile mitgeben. An dieser Stelle müssen Sie entscheiden, ob der IPA-Server selbst die Rolle des DNS-Servers übernehmen soll, wie das beispielsweise beim AD üblich ist. Für unser Beispiel gehen wir jedoch davon aus, dass in Ihrem LAN bereits eine DNS-Installation läuft.
Um IPA-Clients und Servern die Kommunikation zu vereinfachen, sollten Sie dem bestehenden DNS-Server ein paar Einträge hinzufügen, die auf die IPA-Installation verweisen. Im Beispiel arbeitet der Server unter dem Namen "ipa.test.ip" und verwaltet den Realm "test.ip". Die passenden Einträge im DNS-Server sehen bei dnsmasq dann so aus:
Ein Bind-9-DNS-Server braucht die selben Einträge, allerdings in einem anderen Format:
_kerberos._udp.test.ip. 86400 IN SRV 0 100 88 ipa.test.ip.
[…]
Wichtig hierbei: Sowohl AD als auch IPA benötigen die gleichen SRV-Einträge für Kerberos im DNS. Verwenden Sie im LAN bereits ein Active Directory, dürfen Sie die genannten Einträge nicht neu vergeben, da sonst das AD nicht mehr funktioniert. FreeIPA kommt zur Not auch ohne DNS-Konfiguration aus. Sie müssen dann aber bei allen Operationen auf den Clients immer den Verweis auf den Realm und den IPA-Server mitgeben.
Damit die Clients auch mit dem IPA-Server kommunizieren können, öffnen Sie die benötigten Firewall-Ports auf der IPA-Maschine:
Jetzt erlangen Sie Zugang zur Web-UI des FreeIPA-Servers via "https://ipa.test.ip". Dort sehen Sie die Benutzer und Hosts Ihrer Domäne sowie die ausgestellten Zertifikate. Für weitere Tests mit dem Directory können Sie dort nun Benutzer und Gruppen erstellen. Über passende Regelwerke wie Sudo-Regeln können Sie einzelnen Nutzern oder Gruppen später erlauben, auf ausgewählten Hosts als root-User zu arbeiten.
Um nun einen bestehenden Linux-Server in das Directory hinzuzufügen, installieren Sie dort zunächst den IPA-Client. Wie beim Server finden Sie die nötigen Pakete im Appstream-Repository:
dnf install @idm:client
Haben Sie die IPA-Einträge in Ihrem DNS-Server vorgenommen, reicht ein simples Kommando aus, um den Server in der Domäne zu registrieren:
ipa-client-install --mkhomedir
Via DNS findet der Installer alle nötigen Informationen zur Domäne. Der Schalter "--mkhomedir" sorgt dafür, dass der Client die benötigten Home-Verzeichnisse der Domain-Nutzer auf dem lokalen System dynamisch erstellt. In der Praxis legen Administratoren hier aber eher eine Automount-Regel auf dem FreeIPA-Server an, die die Home-Verzeichnisse von einem zentralen NFS-Server beim Login einbindet. Damit haben Domain-User stets Zugriff auf ihre Dateien, egal von welchem PC innerhalb der Domain sie sich anmelden.
Ohne DNS-Einträge müssen sie dem Kommando die Informationen zum IPA-Server und der Domäne mitgeben:
Das Clientsetup fragt dann in beiden Fällen nach einem Domain-Admin-Nutzer und dessen Passwort, um die aktuelle Maschine im Verzeichnisdienst anzumelden.
Bei der Kickstart-Installation eines EL-8-Servers oder -Clients lässt sich dieser Schritt natürlich automatisieren. Richten Sie Fedora Linux oder ein EL8-Linux mit GUI von einem Live-OS Datenträger ein, erfolgt der Beitritt zur Domäne nach der Basisinstallation direkt über die Gnome-Konfiguration. Wenn Gnome den Anwender auffordert, einen neuen Nutzer anzulegen, taucht der Button "Unternehmenszugang" auf. Dieser führt dann interaktiv durch das IPA-Clientsetup.
IPA-Client-Rollout automatisieren
Wenn Sie ein FreeIPA-Verzeichnis in einem bestehenden LAN aufsetzen, möchten Sie natürlich nicht händisch alle bestehenden oder neue Maschinen am Verzeichnis anmelden. Der Prozess lässt sich relativ simpel automatisieren.
Zunächst erstellen Sie die passenden host-Einträge im Verzeichnis. Das erledigen Sie auf einem Rechner, der über den IPA-Client verfügt und mit Admin-Rechten am Verzeichnis authorisiert wurde.
Das vergebene Passwort verfällt nach dem ersten Versuch des Rechners, der Domäne beizutreten.
Installieren Sie auf bestehenden Linux-Hosts den IPA-Client via Ansible oder einem anderen Automatisierungstool. Führen Sie dann auf dem jeweiligen Client via Remote Execution (oder einer Ansible-Rolle) die Registrierung an der Domain durch:
Die Angaben wie "domain", "server" und "realm" brauchen Sie nur, falls Sie keine passenden DNS-Einträge für den IPA-Server haben. Nach dem selben Prinzip fügen Sie automatisch via Kickstart installierte Systeme in das Directory ein. Erst definieren Sie den Rechner samt Einmalpasswort im Verzeichnis. In die Kickstart-Datei fügen Sie die Optionen ein:
%packages
[...]
ipa-client
und gegen Ende
%post
[...]
/usr/sbin/ipa-client-install <Parameter wie oben>
Im Anschluss tritt das System am Ende der automatisierten Installation der Domäne bei.
In der Web-UI Ihres IPA-Servers erscheint nun der frisch angemeldete Server unter "Identität / Hosts". Über "Regeln / Sudo / Sudo-Regeln" könnten Sie jetzt beispielsweise einem ihrer Directory-User erlauben, auf dem neuen Server das Sudo-Kommando auszuführen und Aktionen als "root" durchzuführen. Das Regelwerk lässt sich auch sehr detailliert steuern, sodass Benutzer nur ausgewählte Kommandos oder Kommandogruppen via Sudo ausführen können, nicht aber den vollen Admin-Zugang zum System erlangen.
Zertifikat für Dienste erzeugen
Sobald der neue Server Teil der Domäne ist, können Administratoren für Dienste dieser Maschine Zertifikate erstellen und von der Root-CA im Free-IPA-Server signieren lassen. In unserem Beispiel betreiben wir auf einem frisch aufgesetzten AlmaLinux-8-Server, den wir soeben in der Domäne als "dhcp224" angemeldet haben, einen Webserver mit Nginx. Dieser soll ein offizielles Zertifikat für das HTTPS-Protokoll erhalten.
dnf install nginx
Für das Zertifikat erstellen Sie ein passendes Verzeichnis
mkdir -p /etc/nginx/cert
Da auf EL8-Systemen standardmäßig Selinux läuft, braucht das Verzeichnis den richtigen Kontext für Zertifikate, sonst kann der IPA-Client dort kein Zertifikat ablegen:
semanage fcontext -a -t cert_t "/etc/nginx/cert(/.*)?"
restorecon -v /etc/nginx/cert
Im nächsten Schritt melden Sie sich am Verzeichnis mit einem Admin-Account an: kinit admin. Jetzt wechseln Sie in das Zertifikatsverzeichnis, registrieren den Dienst und fordern das passende Zertifikat an. Für unser Fallbeispiel nehmen wir an, dass der Realm Ihrer Domäne "TEST.IP" lautet:
Damit Sie nicht den kompletten FQDN des Servers mehrfach eintippen müssen, packen Sie ihn in die Shell-Variable "$fqdn". Das Kommando ipa service-add registriert den gewünschten Dienst für den Server beim Directory. Es gibt eine Reihe vordefinierter Services wie eben "HTTP", der Nutzer kann aber jederzeit eigene Services anlegen, wie beispielsweise "REDIS/redis.test.ip".
Das Kommando ipa-getcert request erstellt den Request und fängt auch gleich die Antwort des Dogtag-Diensts auf dem IPA-Server ab. Nginx, wie viele andere Dienste, möchte das Zertifikat im PEM-Format in zwei Dateien für Zertifikat und Schlüssel. Heißt der Server "www.test.ip", erhalten Sie als Antwort eine www.test.ip.crt- und eine www.test.ip.key-Datei. Der langwierige Umweg über eine lokale NSS-Datenbank ist mit dem "Certmonger" damit nicht mehr nötig. Nähert sich das Zertifikat seinem Verfallsdatum, können Sie es mit dem Switch "-r" für "renew" erneuern lassen.
Damit der nginx-Serverdienst auf die Dateien zugreifen kann, muss er natürlich passende Rechte bekommen:
chown -R nginx. /etc/nginx/cert/*
Jetzt schalten Sie in der Standard-Konfigurationsdatei "/etc/nginx/nginx.conf" nur noch den auskommentierten Bereich "# Settings for a TLS enabled server." frei und fügen den Verweis auf Ihr Zertifikat ein:
Nach einem Neustart des Diensts beantwortet Ihr Webserver nun auch HTTPS-Anfragen mit dem IPA-signierten Zertifikat. Nach demselben Prinzip können Sie dann weitere Dienste wie beispielsweise IMAP, SMTP oder auch MQTT anlegen und passende Zertifikate generieren.
Vertrauen aufbauen
Damit Ihre angebundenen Clients die so erstellten Zertifikate akzeptieren, müssen Sie der Certificate Authority Ihres IPA-Servers vertrauen. Auf dem IPA-Server finden sie das "Root-CA" unter "/etc/ ipa/ca.crt". Jetzt hängt es ganz von der Anwendung ab, welche Methode Sie zum Import einer eigenen CA benötigen. Der Firefox-Browser erlaubt beispielsweise, dass Sie die "ca.crt" in einem bestimmten Verzeichnis ablegen. Unter Windows wären das beispielsweise:
Bei Linux-Systemen mit aktiviertem Selinux ist es dabei wiederum wichtig, dass das "certificates"-Verzeichnis und die enthaltenen Dateien über den korrekten Kontext "cert_t" verfügen – sonst kann Firefox sie nicht lesen. Anwendungen wie beispielsweise Redis übergeben den Pfad zur "ca.crt" entweder auf der Kommandozeile oder sichern ihn in der Konfigurationsdatei. Viele Anwendungen nutzen derweil den CA-Trust des Betriebssystems.
Auf einem EL8- oder Fedora-Linux-System kopieren Sie die "ca.crt" Ihres IPA-Servers in das Verzeichnis "/etc/pki/ca-trust/source/anchors" (Selinux-Kontext nicht vergessen) und führen als root oder via sudo das Kommando update-ca-trust aus. Anwendungen wie beispielsweise der Chrome- oder Chromium-Browser nutzen die Trust-Chain des Systems und brauchen dann keine individuelle Konfiguration. Unter Windows gibt es die Möglichkeit, eigene Zertifikate über eine Group Policy oder ein PowerShell-Skript zu importieren.
Fazit
FreeIPA mit den integrierten Dogtag-Diensten und dem Certmonger-Client vereinfacht das Zertifikatsmanagement im Intranet erheblich. Vorbei sind die Zeiten mit lokalen NSS-Datenbanken und langwierigen Arbeitsabläufen, um Requests und deren Antworten hin-und-her zu kopieren und die resultierenden PKS12-, PEM-, KEY- oder CRT-Dateien irgendwie im Format konvertieren zu müssen. Das Open-Source-Toolset erlaubt es Ihnen, mit nur wenigen Handgriffen für alle TLS-fähigen Dienste zügig Zertifikate zu erstellen und einzusetzen.