Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch

Transkript

1 Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch Red Hat Network Satellite Ausgabe 1 Landmann

2 Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch Red Hat Network Satellite Ausgabe 1 Landmann rlandmann@redhat.co m

3 Rechtlicher Hinweis Copyright 2010 Red Hat, Inc. T his document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux is the registered trademark of Linus Torvalds in the United States and other countries. Java is a registered trademark of Oracle and/or its affiliates. XFS is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project. T he OpenStack Word Mark and OpenStack Logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community. All other trademarks are the property of their respective owners. Z usammenfassung Willkommen beim Red Hat Network Satellite Client-Konfigurationshandbuch.

4 Inhaltsverzeichnis Inhaltsverzeichnis. Kapitel Einführung Kapitel Client-Applikationen Die neuesten Red Hat Network Client-RPMs einsetzen Client-Applikationen konfigurieren Registrieren mit Aktivierungsschlüsseln Die up2date --configure-option Die Konfigurationsdateien manuell aktualisieren Server-Ausfallsicherung implementieren Das Paket-Updater-Applet Das Red Hat Network Alert Notification T ool für Satellite konfigurieren 9. Kapitel SSL-Infrastruktur Eine kurze Einführung in SSL Das RHN SSL Maintenance Tool Erklärung zur SSL-Generierung RHN SSL Maintenance T ool-optionen Das CA SSL-Schlüsselpaar generieren Webserver SSL-Schlüssel-Sets generieren Das öffentliche SSL-Z ertifikat der CA auf Clients implementieren Client-Systeme konfigurieren 19. Kapitel Import angepasster GPG-Schlüssel Kapitel Verwendung von.... RHN..... Bootstrap Vorbereitung Generierung Verwendung des Skripts RHN Bootstrap Optionen 24. Kapitel Manuelles Erstellen der.... Konfiguration Kapitel Implementieren von..... Kickstart Beispiel für.... ein.... Bootstrap-Skript Versionsgeschichte Stichwortverzeichnis Symbole 38 A 38 B 38 C 38 G 38 K 38 R 39 S 39 1

5 2 Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch

6 Kapitel 1. Einführung Kapitel 1. Einführung Dieses Handbuch mit praktischen Anwendungsbeispielen soll RHN Satellite Server- und RHN Proxy Server-Kunden dabei helfen, ihre Client-Systeme einfacher konfigurieren zu können. Standardmäßig kommunizieren alle Red Hat Network Client-Applikationen mit den zentralen Red Hat Network-Servern. Wenn Clients stattdessen mit einem RHN Satellite Server oder RHN Proxy Server verbunden werden, müssen viele dieser Einstellungen verändert werden. Das Verändern der Client- Einstellungen für ein oder zwei Systeme ist relativ einfach. Eine Unternehmensumgebung dagegen, die hunderte oder gar tausende von Systemen umfassen kann, wird höchstwahrscheinlich von den hier beschriebenen Massenkonfigurationsschritten profitieren. Aufgrund der Komplexität dieses Unterfangens können Kunden ein bestehendes Skript einsetzen, welches viele der notwendigen Aufgaben automatisiert, die für eine Verbindung mit einem Proxy oder Satellite Server notwendig sind. Werfen Sie einen Blick auf Kapitel 5, Verwendung von RHN Bootstrap für weitere Details. Red Hat ist davon überzeugt, dass das Verständnis der notwendinge Änderungen und der damit verbundenen Implikationen für den Anwender äußerst hilfreich sein kann und beschreibt deshalb die manuellen Schritte für die Rekonfiguration in den anfänglichen Kapiteln dieses Handbuchs. Sie können somit nach eigenem Ermessen die für Ihr Unternehmen ideale Lösung bestimmen. Obwohl viele der in diesem Handbuch angeführten Befehle genau so angewendet werden können, wie sie in diesem Handbuch erscheinen, ist es nicht möglich, alle potenziellen Netzwerkkonfigurationen von Kunden vorauszusagen. Red Hat empfiehlt Ihnen daher, diese Befehle lediglich als Referenzen anzusehen und die individuellen Einstellungen Ihres Unternehmens zu berücksichtigen. Anmerkung Informationen zur Unix Client-Konfiguration finden Sie im RHN Satellite Server Referenzhandbuch im Unix-Support-Kapitel. 3

7 Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch Kapitel 2. Client-Applikationen Um die meisten Red Hat Network-Features im Unternehmensbereich nutzen zu können, wie beispielsweise die Registrierung für einen RHN Satellite, ist die Konfiguration der neuesten Client- Applikationen erforderlich. Der Erhalt dieser Applikationen noch vor der Registrierung des Clients bei Red Hat Network kann sich etwas schwierig gestalten. Dieses Paradox wird speziell dann problematisch, wenn Kunden eine geraume Anzahl von älteren Systemen auf Red Hat Network migrieren. Wichtig Red Hat empfiehlt dringend, dass Clients, die mit einem RHN Proxy Server oder RHN Satellite Server verbunden sind, das neueste Update von Red Hat Enterprise Linux besitzen, um eine einwandfreie Verbindungsfähigkeit zu gewährleisten. Falls zusätzlich Client-Firewalls eingerichtet wurden, sollten die Ports 80 und 443 geöffnet sein, damit Red Hat Network ordnungsgemäß funktioniert Die neuesten Red Hat Network Client-RPMs einsetzen Der Paket-Updater (pup), yum, und Red Hat Network Registration Client (rhn_register) auf Red Hat Enterprise Linux 5 (up2date auf früheren Versionen von Red Hat Enterprise Linux) sind Voraussetzungen für die Verwendung eines Großteils der Enterprise-Funktionalität von Red Hat Network. Dabei ist es äußerst wichtig, diese vor dem Versuch, RHN Proxy Server oder RHN Satellite Server in Ihrer Unternehmensumgebung zu verwenden, auf Client-Systemen zu installieren. Es gibt hierbei einige sinnvolle Vorgehensweisen für das Update der RHN Client-Software. Eine davon umfasst das Speichern der RPMs an einem Ort, an dem von allen Client-Systemen auf die RPMs zugegriffen werden kann und das Implementieren der Pakete mit dem einfachst möglichen Befehl. In nahezu allen Fällen ist eine manuelle Implementierung von yum, pup und rhn_register (up2date bei früheren Versionen von Red Hat Enterprise Linux) nicht notwendig. Diese Client-T ools sollten keine Probleme mit der Verbindung zu Ihrer RHN Satellite- oder Proxy-Umgebung haben. Die untenstehende Auseinandersetzung mit diesem T hema beruht auf der Annahme, dass die standardmäßigen T ools yum, pup, und rhn_register (oder up2date) nicht in den aktuellsten Versionen vorliegen und sich für Ihre Umgebung nicht eignen. Bitte vergessen Sie nicht, dass lediglich Systeme mit Red Hat Enterprise Linux 5 sich bei RHN registriert haben müssen in firstboot nach Installation, oder mittels rhn_register. Systeme mit Red Hat Enterprise Linux 3 und 4 können die im Red Hat Update Agent eingebaute Registrierungsfunktionalität verwenden. In dieser Dokumentation wird davon ausgegangen, dass sich zumindest ein RHN Satellite Server und/oder RHN Proxy Server im Netzwerk des Kunden befindet. Das untenstehende Beispiel illustriert eine einfache Vorgehensweise beim erstmaligen Einsatz von yum, pup und rhn_register (oder up2date) durch einen Administrator. Dabei wird davon ausgegangen, dass die Rechner noch kein funktionstüchtiges RHN besitzen. Der Administrator hat das /var/www/htm l/pub/-verzeichnis mit einer Kopie von yum, pup und rhn_register (oder up2date) RPMs bestückt, die von seinen Client- Systemen benötigt werden und hat diese RPMs mittels dem einfachen rpm -Uvh-Befehl auf seinen Clients implementiert. Auf einem Client ausgeführt, installiert dieser Befehl die RPM-Dateien auf diesem Client. Voraussetzung dafür sind der korrekte Domainname, Pfad und die entsprechenden RPM- Versionen: 4

8 Kapitel 2. Client-Applikationen rpm -Uvh Beachten Sie dabei, dass die Architektur (in diesem Fall i386) abhängig von den zu versorgenden Systemen eventuell abgeändert werden muss Client-Applikationen konfigurieren Es muss nicht jeder Kunde eine sichere Verbindung mit einem RHN Satellite Server oder RHN Proxy Server innerhalb des eigenen Unternehmens besitzen. Nicht jeder Kunde benötigt einen GPG-Schlüssel für angepasste Pakete. (Beide dieser T hemen werden später im Detail behandelt.) Jeder Kunde, der RHN Satellite Server oder RHN Proxy Server verwendet, muss den Red Hat Update Agent (up2date) neu konfigurieren und möglicherweise auch den Red Hat Network Registration Client (rhn_register), um diesen von Red Hat Network auf den eigenen RHN Satellite Server oder RHN Proxy Server umzulenken. Wichtig Obwohl dies nicht konfigurierbar ist, beachten Sie bitte, dass der vom up2date verwendete Port 80 für HTTP und 443 für sicheres HTTP (HTTPS) ist. Standardmäßig verwendet yum auf Red Hat Enterprise Linux 5 nur SSL. Aus diesem Grund sollten sich Benutzer zuerst davon überzeugen, das ihre Firewalls Verbindungen über den Port 443 zulassen. Um SSL zu umgehen, müssen Sie das Protokoll für serverurl in /etc/sysconfig/rhn/up2date von https auf http umändern. Ebenso müssen Sie beachten, dass für die Verwendung von Monitoring und Probes, die den Red Hat Network Monitoring Daemon benötigen, Client-Systeme Verbindungen auf dem Port 4545 (oder Port 22, falls stattdessen sshd verwendet wird) zulassen müssen. Standardmäßig verweisen rhn_register und up2date auf die Haupt-Red Hat Network-Server. Benutzer müssen daher Client-Systeme neu konfigurieren, sodass diese auf ihren RHN Satellite Server oder RHN Proxy Server verweisen. Beachten Sie bitte, dass die neueste Version des Red Hat Update Agent so konfiguriert werden kann, dass auch mehrere RHN Server verwendet werden können und dieser somit eine Art Ausfallsicherung darstellt, falls auf den primären Server nicht zugegriffen werden kann. Werfen Sie einen Blick auf Abschnitt 2.2.4, Server-Ausfallsicherung implementieren für nähere Instruktionen zur Aktivierung dieses Features. T he next sections describe different methods of configuring the client systems to access your RHN Satellite Server or RHN Proxy Server. T o see how virtually all reconfiguration can be scripted, see Kapitel 6, Manuelles Erstellen der Konfiguration Registrieren mit Aktivierungsschlüsseln Red Hat empfiehlt die Verwendung von Aktivierungsschlüsseln bei der Registrierung und der Konfiguration von Client-Systemen, die auf RHN Proxy Server oder RHN Satellite Server zugreifen. Aktivierungsschlüssel können zum Registrieren, Berechtigen und zum Anmelden von Systemen verwendet werden. Werfen Sie einen Blick auf den Abschnitt "Aktivierungsschlüssel" im RHN Satellite Server Referenzhandbuch für weitere Informationen über Aktivierungsschlüssel. Z ur Registrierung mit einem Aktivierungsschlüssel gehören 4 einfache Schritte: 5

9 Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch 1. Erstellen Sie einen Aktivierungsschlüssel. 2. Importieren Sie angepasste GPG-Schlüssel. 3. Laden Sie die SSL-Z ertifikats-rpm vom /pub/-verzeichnis des RHN Proxy Server oder RHN Satellite Server herunter und installieren diese. Der Befehl für diesen Schritt könnte ungefähr so aussehen: rpm -Uvh 4. Melden Sie Ihr System bei Ihrem RHN Proxy Server oder RHN Satellite Server an. Der Befehl für diesen Schritt könnte ungefähr so aussehen: rhnreg_ks --activationkey mykey --serverurl FQDN/XMLRPC Alternativ können die meisten der o.g. Schritte in einem Shell-Skript zusammengefasst werden, das die folgenden Z eilen enthält (Beachten Sie, dass dieser Befehl für den Druck und für PDF-Dokumente in mehrere Z eilen umgebrochen, er jedoch am Shell-Prompt in einer einzigen Z eile eingegeben werden muss). wget bash && rhnreg_ks --activation-key my_key --serverurl Das Bootstrap-Skript, das bei der Installation generiert wird und für RHN Satellite Server sowie auch RHN Proxy Server zur Verfügung steht, ist ein solches Skript. Das Skript und der von dem, erhn Bootstraps generiert wird, werden genauer in Kapitel 5, Verwendung von RHN Bootstrap besprochen. Warnung Systeme mit Red Hat Enterprise Linux 2.1 und Versionen von Red Hat Linux vor 8.0 können Schwierigkeiten bei der Verwendung von Aktivierungsschlüsseln zur Migration von SSL- Z ertifikateinstellungen von rhn_register auf up2date haben. Deshalb muss die Information der SSL-Z ertifikate auf diesen Systemen manuell festgelegt werden. Alle anderen Einstellungen, wie beispielsweise die Server-URL, werden einwandfrei übertragen Die up2date --configure-option Der Red Hat Update Agent in Red Hat Enterprise Linux 3 und 4 stellt eine Oberfläche zur Konfiguration unterschiedlicher Einstellungen bereit. Für eine vollständige Auflistung dieser Einstellungen werfen Sie bitte einen Blick auf die up2date-handbuchseite (m an up2date in der Befehlszeile). Um den Red Hat Update Agent neu zu konfigurieren, müssen Sie folgenden Befehl als 'root' ausführen: up2date --configure Es erscheint ein Dialogfenster, welches unterschiedliche Einstellungen anbietet, die neu konfiguriert werden können. Im Allgem ein-reiter unter Wählen Sie einen Red Hat Network Server aus ersetzen Sie den Standardwert durch dem FQDN des RHN Satellite Servers oder RHN Proxy Servers, 6

10 Kapitel 2. Client-Applikationen wie beispielsweise ain.com/xmlrpc. /XMLRPC am Ende sollte beibehalten werden. Klicken Sie anschließend auf OK. Abbildung 2.1. GUI-Konfiguration des Red Hat Update Agent Vergewissern Sie sich, dass Sie den Domainnamen Ihres RHN Satellite Server oder RHN Proxy Server richtig eingeben. Wenn Sie einen falschen Domainnamen eingeben oder das Feld leer lassen, kann es sein, dass up2date --configure nicht startet. Dieses Problem kann jedoch gelöst werden, indem Sie den Wert in der up2date-konfigurationsdatei abändern. Siehe Abschnitt 2.2.3, Die Konfigurationsdateien manuell aktualisieren für genauere Instruktionen. Warnung Systeme mit Red Hat Enterprise Linux 3 oder 4 besitzen Registrierungsfunktionalität, die in den Red Hat Update Agent eingebaut ist und installieren daher den Red Hat Network Registration Client nicht. Systeme mit Red Hat Enterprise Linux 5 verwenden up2date nicht, sie benötigen daher rhn_register, um ihre Systeme bei RHN oder Satellite zu registrieren, sowie yum und pup, um ihre Pakete zu aktualisieren Die Konfigurationsdateien manuell aktualisieren Alternativ zur zuvor erläuterten grafischen Benutzeroberfläche kann der Red Hat Update Agent auch neu konfiguriert werden, indem die Konfigurationsdateien der Applikationen bearbeitet werden. Um Red Hat Update Agent auf den Client-Systemen zu konfigurieren, die mit dem RHN Proxy Server oder RHN Satellite Server verbinden, bearbeiten Sie die Werte der serverurl- und nosslserverurl-einstellungen in der /etc/sysconfig/rhn/up2date-konfigurationsdatei als 'root'. Ersetzen Sie die standardmäßige Red Hat Network-URL mit dem FQDN für den RHN Proxy Server oder RHN Satellite Server. Z um Beispiel: 7

11 Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch serverurl[comment]=remote server URL serverurl= nosslserverurl[comment]=remote server URL without SSL nosslserverurl= Warnung Die httpproxy-einstellung in /etc/sysconfig/rhn/up2date bezieht sich nicht auf den RHN Proxy Server. Diese wird dazu verwendet, einen optionalen HT T P-Proxy für den Client zu konfigurieren. Wenn ein RHN Proxy Server vorhanden ist, muss die httpproxy-einstellung leer gelassen werden (es darf kein Wert erscheinen) Server-Ausfallsicherung implementieren Ab up2date kann der Red Hat Update Agent dahingehend konfiguriert werden, nach Updates von einer Reihe von RHN Servern zu suchen. Dies kann besonders hilfreich sein, wenn Ihr primärer RHN Proxy Server oder RHN Satellite Server offline ist und Sie trotzdem konstante Updates erhalten möchten. Wenn Sie dieses Feature verwenden möchten, müssen Sie zuerst überprüfen, ob Sie die erforderliche Version von up2date besitzen. Fügen Sie anschließend als 'root' manuell die sekundären Server zu den serverurl und nosslserverurl-einstellungen in der /etc/sysconfig/rhn/up2date- Konfigurationsdatei hinzu. Fügen Sie ebenso die FQDNs für den Proxy oder Satellite durch ein Semikolon (;) getrennt direkt nach dem primären Server ein. Z um Beispiel: serverurl[comment]=remote server URL serverurl= nosslserverurl[comment]=remote server URL without SSL nosslserverurl= Es wird versucht, die Verbindung zu den Servern in der hier angegebenen Reihenfolge herzustellen. Sie können ganz nach Wunsch eine beliebige Anzahl an Servern mitaufnehmen. Sie können die zentralen RHN Server ebenso auflisten. Dies macht jedoch nur dann Sinn, wenn die Client-Server mit dem Internet verbunden sind Das Paket-Updater-Applet Red Hat Enterprise Linux 5 bietet ein laufendes Programm auf der grafischen T askleiste, das regelmäßig nach Updates vom RHN oder Satellite Server sucht und Benutzer benachrichtigt, sobald ein neues Update verfügbar ist. 8

12 Kapitel 2. Client-Applikationen Abbildung 2.2. Paket-Updater-Applet Das Paket-Updater-Applet bleibt im Benachrichtigungsfeld der T askleiste und sucht regelmäßig nach neuen Updates. Das Applet ermöglicht Ihnen auch die Durchführung einiger Aufgaben zur Paketverwaltung im Applet, durch Klicken auf das Benachrichtigungs-Icon und Auswählen einer der folgenden Aufgaben: Aktualisieren Überprüfe RHN oder den Satellite auf neue Updates Updates anzeigen startet die Paket-Updater-Applikation, so dass Sie alle verfügbaren Updates detaillierter ansehen können und die Updates nach Ihren Spezifikationen konfigurieren können Updates anwenden Herunterladen und installieren aller aktualisierten Pakete. Beenden Schließen des Applets 2.4. Das Red Hat Network Alert Notification Tool für Satellite konfigurieren Das Red Hat Network Alert Notification Tool, das runde Symbol in der Taskleiste Ihres Red Hat Enterprise Linux 3 oder 4 Desktops, kann auf Systemen mit Red Hat Enterprise Linux 3 oder höher konfiguriert werden, um verfügbare Updates von angepassten Channels auf Ihrem RHN Satellite Server zu erkennen. Gehen Sie sicher, dass die Konfiguration des RHN Satellite Server dieses Feature unterstützt. (RHN Proxy Server unterstützt das Applet ohne Modifikation des Clients oder Servers.) Hier finden Sie die Schritte, um das Red Hat Network Alert Notification T ool zu konfigurieren: 1. Ihr RHN Satellite Server muss Version 3.4 oder höher sein, sodass das rhns-applet-paket auf dem Satellite installiert ist. Das Paket finden Sie im RHN Satellite Software-Channel für Versionen 3.4 und höher. 2. Das rhn-applet-actions-paket kann mit up2date oder mithilfe des Red Hat Network T ools Software-Channel abgefragt werden. Installieren Sie das Paket auf allen Red Hat Enterprise Linux 3 und neueren Client-Systemen, um über benutzerspezifische Updates mithilfe des Red Hat Network Alert Notification T ools benachrichtigt zu werden. Die Client-Systeme müssen zur Management- oder Provisioning-Servicestufe berechtigt sein. 3. Auf der Satellite-Version der RHN-Website gehen Sie zur System-Details-Seite eines jeden Systems und klicken auf den Link im RHN-Applet-Bereich, um das Red Hat Network Alert Notification T ool auf den Satellite umzulenken. Wenn das Applet das nächste Mal gestartet wird, wendet dieses die neue Konfiguration an und verbindet sich mit dem RHN Satellite Server für Updates. 9

13 Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch Kapitel 3. SSL-Infrastruktur Für Red Hat Network-Kunden sind Sicherheitsfragen von höchster Bedeutung. Eine der Stärken von Red Hat Network ist dessen Fähigkeit, jede einzelne Anfrage über SSL (Secure Sockets Layer) abzuwickeln. Um diesen Sicherheitslevel beizubehalten, müssen Kunden, die Red Hat Network innerhalb der eigenen Infrastruktur installieren, benutzerdefinierte SSL-Schlüssel und Z ertifikate generieren. Die manuelle Erstellung und die manuelle Z uordnung von SSL-Schlüsseln und Z ertifikaten kann sehr arbeitsaufwändig sein. RHN Proxy Server sowie auch RHN Satellite Server ermöglichen es Ihnen, Ihre eigenen SSL-Schlüssel und Z ertifikate basierend auf Ihrer eigenen, privaten Z ertifizierungsstelle (Certificate Authority oder im Folgenden kurz CA genannt) während der Installation zu erstellen. Z usätzlich dazu gibt es zu diesem Z weck das separate Befehlszeilendienstprogramm RHN SSL Maintenance T ool. Unabhängig davon müssen diese Schlüssel und Z ertifikate auf allen Systemen in Ihrer Infrastruktur eingesetzt werden. In vielen Fällen ist der Einsatz dieser SSL-Schlüssel und Z ertifikate bereits für Sie automatisiert. Dieses Kapitel beschreibt effiziente Verfahren zur Durchführung all dieser Aufgaben. Bitte beachten Sie, dass in diesem Kapitel das T hema SSL nicht tiefgreifend behandelt wird. Das RHN SSL Maintenance T ool wurde so entwickelt, dass das Aufsetzen und Verwalten dieser Public-Key- Infrastruktur (PKI) weniger komplex erscheint. Für detailliertere Informationen zu diesem T hema empfehlen wir auf einige der vielen, ausgezeichneten Referenzhandbücher, die in einem Buchhandel in Ihrer Nähe erhältlich sind, zurückzugreifen Eine kurze Einführung in SSL SSL oder Secure Sockets Layer ist ein Protokoll, das es Client-Servern ermöglicht, Informationen sicher weiterzugeben. SSL verwendet dabei ein System von öffentlichen und privaten Schlüsselpaaren, um die Kommunikation zu entschlüsseln, die zwischen den Clients und Servern stattfindet. Auf öffentliche Z ertifikate oder sog. Public Certificates kann frei zugegriffen werden, wohingegen private Schlüssel oder Private Keys gesichert aufbewahrt werden müssen. Dieses System basiert auf der mathematischen Beziehung (digitale Signatur) zwischen einem privaten Schlüssel und dem dazugehörigen öffentlichen Z ertifikat. Aufgrund dieser Beziehung kann eine vertrauenswürdige Verbindung hergestellt werden. Anmerkung Im Rahmen dieses Dokuments werden private SSL-Schlüssel und öffentliche Z ertifikate behandelt. Genau genommen können beide als Keys oder Schlüssel bezeichnet werden (öffentliche und private Schlüssel). Üblicherweise wird jedoch im Z usammenhang mit SSL die öffentliche Hälfte eines SSL-Schlüsselpaares (oder Schlüssel-Sets) als öffentliches Z ertifikat bezeichnet. Die SSL-Infrastruktur eines Unternehmens besteht generell aus folgenden SSL-Schlüsseln und Z ertifikaten: Privater SSL-Schlüssel und öffentliches Z ertifikat Ihrer CA ("Certificate Authority", Z ertifizierungsstelle) üblicherweise wird nur ein Set pro Unternehmen generiert. Das öffentliche Z ertifikat wird vom privaten Schlüssel digital signiert. Das öffentliche Z ertifikat wird an jedes System verteilt. Web Server privater SSL-Schlüssel und öffentliches Z ertifikat ein Set pro Applikationsserver. Das öffentliche Z ertifikat wird sowohl vom eigenen privaten Schlüssel als auch vom privaten SSL- Schlüssel Ihrer CA digital signiert. Wir verweisen des öfteren auf ein Key-Set oder Schlüssel-Set eines Webservers, da eine zwischengeschaltete Anfrage des SSL-Z ertifikats generiert wird. Die 10

14 Kapitel 3. SSL-Infrastruktur Verwendung ist in diesem Fall nicht allzu wichtig und wird daher auch nicht weiter im Detail besprochen. Alle drei werden einem RHN Server zugeordnet. Hier ist ein Beispielszenario: Sie besitzen einen RHN Satellite Server und fünf RHN Proxy Server. Sie generieren daher ein SSL-Schlüsselpaar Ihrer CA und sechs Webserver SSL-Schlüssel-Sets. Das öffentliche SSL-Z ertifikat der CA wird auf alle Systeme verteilt und von allen Clients dazu verwendet, eine Verbindung mit den jeweiligen Upstream-Servern aufzubauen. Jeder Server besitzt sein eigenes SSL-Schlüssel-Set, welches speziell an den Hostnamen dieses Servers gebunden ist und unter Verwendung des eigenen privaten SSL-Schlüssels in Verbindung mit dem privaten SSL-Schlüssel der CA generiert wurde. Dadurch entsteht eine auf digitaler Basis verifizierbare Beziehung zwischen dem öffentlichen SSL-Z ertifikats des Webservers und dem SSL-Schlüsselpaar Ihrer CA und dem privaten Schlüssel des Servers. Das Schlüssel-Set des Webservers kann nicht mit anderen Webservern gemeinsam verwendet werden. Wichtig Das Wichtigste an diesem System ist das SSL-Schlüsselpaar Ihrer CA. Ein Administrator kann anhand des privaten Schlüssels und öffentlichen Z ertifikats das SSL-Schlüssel-Set eines jeden Webservers generieren. Dieses CA-SSL-Schlüsselpaar muss sicher aufbewahrt werden. Sobald die gesamte RHN-Infrastruktur von Servern einmal vollständig aufgesetzt ist, wird strengstens empfohlen, dass Sie das SSL-Verzeichnis, das von diesem T ool angelegt wurde, auf einem separaten Medium archivieren. Schreiben Sie ebenso das CA-Passwort auf und bewahren das externe Speichermedium und das Passwort an einem sicheren Ort auf Das RHN SSL Maintenance Tool Red Hat Network bietet ein Befehlszeilen-T ool an, um Ihnen das Management Ihrer sicheren Infrastruktur zu erleichtern: das RHN SSL Maintenance T ool ist üblicherweise auch unter dem Befehlsnamen rhn-ssl-tool bekannt. Dieses T ool ist als T eil des rhns-certs-tools-pakets erhältlich. Dieses Paket kann in den Software-Channels des neuesten RHN Proxy Server und RHN Satellite Server (sowie auch das RHN Satellite Server ISO) gefunden werden. Das RHN SSL Maintenance T ool ermöglicht es Ihnen, Ihr SSL-Schlüsselpaar Ihrer CA sowie auch Webserver SSL- Schlüssel-Sets (manchmal auch als Schlüsselpaare bezeichnet) zu generieren. Es handelt sich hierbei um ein reines Build-T ool. Es generiert alle erforderlichen SSL-Schlüssel und Z ertifikate. Die Dateien werden zu einem Paket im RPM-Format zur raschen Verteilung und Installation auf allen Client-Rechnern zusammengefasst. Jedoch werden diese vom T ool nicht zugeordnet. Dies wird dem Administrator überlassen oder via RHN Satellite Server automatisiert. Anmerkung rhns-certs-tools, welches rhn-ssl-tool beinhaltet, kann auf jedem aktuellen Red Hat Enterprise Linux System unter minimalen Voraussetzungen installiert und eingesetzt werden. Es ist für Administratoren von Vorteil, die deren SSL-Infrastruktur von deren Arbeitsplatzrechnern aus oder auch von anderen Systemen und nicht den RHN Servern aus verwalten möchten. In diesen Fällen ist das Tool notwendig: Wenn Sie Ihr öffentliches Z ertifikat Ihrer CA aktualisieren - dies ist äußerst selten der Fall. Wenn Sie einen RHN Proxy Server Version 3.6 oder höher installieren, der sich mit den zentralen 11

15 Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch RHN Servern verbindet - in diesem Fall kann der gehostete Service aus Sicherheitsgründen nicht als Repository für den SSL-Schlüssel Ihrer CA und für Ihr Z ertifikat dienen. Wenn Sie Ihre RHN-Infrastruktur neu konfigurieren, die zuvor kein SSL verwendet hat. Wenn Sie RHN Proxy Server Versionen niedriger als 3.6 in Ihre Infrastruktur aufnehmen. Wenn Sie mehrere RHN Satellite Server in Ihre RHN-Infrastruktur aufnehmen - konsultieren Sie in diesem Fall einen Red Hat-Sachverständigen. In diesen Fällen ist das T ool nicht erforderlich: Während der Installation eines RHN Satellite Server - alle SSL-Einstellungen werden während des Installationsvorgangs vorgenommen. Die SSL-Schlüssel und Z ertifikate werden automatisch generiert und zugeordnet. Während der Installation eines RHN Proxy Servers der Version 3.6 oder höher, wenn dieser mit einem RHN Satellite Server Version 3.6 oder höher als dessen T op-level-service verbunden ist - der RHN Satellite Server beinhaltet sämtliche SSL-Informationen, die dazu benötigt werden, die SSL- Schlüssel und Z ertifikate des RHN Proxy Servers zu konfigurieren, zu generieren und zuzuordnen. Beide Installationsvorgänge, der des RHN Satellite Servers und der des RHN Proxy Servers gewährleisten, dass das öffentliche SSL-Z ertifikat der CA in jedem /pub-verzeichnis eines jeden Servers abgelegt wird. Dieses öffentliche Z ertifikat wird von den Client-Systemen dazu verwendet, sich mit den RHN Servern zu verbinden. Siehe Abschnitt 3.3, Das öffentliche SSL-Z ertifikat der CA auf Clients implementieren für weitere Informationen. Kurz gesagt, wenn Ihr Unternehmen die aktuellste Version des RHN Satellite Server als T op-level- Service einsetzt, dann werden Sie höchstwahrscheinlich das T ool nicht benötigen. Ansonsten sollten Sie sich mit dessen Anwendung vertraut machen Erklärung zur SSL-Generierung Der hauptsächliche Nutzen bei der Verwendung des RHN SSL Maintenance T ools liegt in der Sicherheit, Flexibilität und Portabilität. Sicherheit wird durch die Erstellung eindeutiger Webserver SSL- Schlüssel und Z ertifikate für jeden RHN Server gewährleistet, wobei alle von einem einzigen SSL- Schlüsselpaar Ihrer CA signiert sind, das von Ihrem Unternehmen erstellt wurde. Flexibilität erhalten Sie durch die Fähigkeit des T ools auf jeder Maschine eingesetzt werden zu können, die das rhns-certstools-paket installiert hat. Portabilität liegt in der Build-Struktur, die überall aufbewahrt und im weiteren Verlauf bei Bedarf installiert werden kann. Wenn also in Ihrer Infrastruktur Ihr T op-level RHN Server der aktuellste RHN Satellite Server ist, dann ist das Wiederherstellen Ihres ssl-build-baumes von einem Archiv in das /root-verzeichnis alles was Sie tun müssen. Machen Sie von den Konfigurations-T ools Gebrauch, die auf der Website des RHN Satellite Server zur Verfügung gestellt werden. Sie verwenden das RHN SSL Maintenance T ool am besten, indem Sie die folgenden Aufgaben in ungefähr dieser Reihenfolge ausführen. Für die notwendigen Details verweisen wir auf die verbleibenden Abschnitte: 1. Installieren Sie das rhns-certs-tools-paket auf einem System in Ihrem Unternehmen. Dies kann, muss aber nicht der RHN Satellite Server oder RHN Proxy Server sein. 2. Erzeugen Sie ein einzelnes SSL-Schlüsselpaar Ihrer CA für Ihr Unternehmen und installieren die daraus resultierende RPM-Datei oder das öffentliche Z ertifikat auf allen Client-Systemen. 3. Erzeugen Sie ein Webserver SSL-Schlüssel-Set für jeden der Proxy-Server und Satellite-Server und installieren die daraus resultierenden RPM-Dateien auf den Servern. Starten Sie anschließend den httpd-dienst neu: 12

16 Kapitel 3. SSL-Infrastruktur /sbin/service httpd restart 4. Archivieren Sie den SSL-Build-Baum - bestehend aus dem primären Build-Verzeichnis und allen Unterverzeichnissen und Dateien - auf externen, transportablen Medien, wie z.b. einer Diskette. (Speicherplatzanforderungen sind vernachlässigbar.) 5. Überprüfen Sie das Archiv und bewahren es an einem sicheren Ort auf, wie beispielsweise in den Abschnitten Zusätzliche Anforderungen des Proxy- oder auch Satellite-Installationshandbuchs beschrieben. 6. Notieren Sie das CA-Passwort und bewahren Sie es für die zukünftige Verwendung auf. 7. Löschen Sie den Build-Baum aus Sicherheitsgründen vom Build-System, aber nur wenn die gesamte RHN-Infrastruktur vorhanden und konfiguriert ist. 8. Wenn Sie zusätzliche Webser SSL-Schlüssel-Sets benötigen, dann stellen Sie den Build-Baum auf einem System mit dem RHN SSL Maintenance T ool wieder her und wiederholen die Schritte 3 bis RHN SSL Maintenance Tool-Optionen Das RHN SSL Maintenance T ool bietet eine Unmenge an Befehlszeilenoptionen zur Generierung Ihres CA SSL-Schlüsselpaares und zur Verwaltung Ihrer Server SSL-Z ertifikate und -Schlüssel an. Das T ool bietet grundsätzlich drei Befehlszeilenoptionen für zur Auflistung der Hilfe an: rhn-ssl-tool -- help (allgemein), rhn-ssl-tool --gen-ca --help (Certificate Authority) und rhn-ssl-tool -- gen-server --help (Webserver). Auch die Handbuchseite für 'rhn-ssl-tool' liefert eine detaillierte Beschreibung: m an rhn-ssl-tool. Die beiden untenstehenden T abellen unterteilen die Optionen nach Aufgaben, entweder CA oder Webserver SSL-Schlüssel-Set-Generierung. Diesen Optionen muss der --gen-ca-parameter vorangestellt werden: 13

17 Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch T abelle 3.1. SSL Certificate Authority (CA) Optionen (rhn-ssl-tool --gen-ca --help) Option --gen-ca -h, --help -f, --force -p=, --password=password -d=, --dir=build_directory --ca-key=filename --ca-cert=filename --cert-expiration=ca_cert_expire --set-country=country_code --set-state=state_or_province --set-city=city_or_locality --set-org=organization --set-org-unit=set_org_unit Beschreibung Generiert ein Certificate Authority (CA) Schlüsselpaar und ein öffentliches RPM. Diese Option muss in Z usammenhang mit irgendeiner der verbleibenden Optionen in dieser T abelle benutzt werden. Z eigt den Hilfebildschirm mit einer Liste von Basisoptionen in Z usammenhang mit der CA-Generierung und -Verwaltung an. Erzwingt die Erzeugung eines neuen privaten Schlüssels Ihrer CA und/oder öffentlichen Z ertifikats. Das CA-Passwort. Sie werden zur Eingabe des Passworts aufgefordert, wenn Sie dieses nicht von vornherein angeben. Bewahren Sie eine Kopie des Passworts an einem sicheren Ort auf. Für die meisten Befehle erforderlich - Das Verzeichnis, in welches Z ertifikate und RPM-Dateien beim Bauen gespeichert werden. Standard ist./ssl-build. Der Dateiname des privaten Schlüssels Ihrer CA. Standard ist RHN-ORG- PRIVAT E-SSL-KEY. Der Dateiname des öffentlichen Z ertifikats Ihrer CA. Standard ist RHN-ORG- T RUST ED-SSL-CERT. Die Gültigkeit des öffentlichen CA- Z ertifikats. Standard ist das Ablaufen der Gültigkeit einen Tag vor dem Epochenwechsel (bzw ). Der zweistellige Ländercode. Standard ist US. Der Staat oder das Bundesland des CA- Z ertifikats. Standard ist ''. Die Stadt oder der Ort. Standard ist ''. Die Firma oder das Unternehmen, wie beispielsweise Red Hat. Standard ist Example Corp. Inc. Die Unternehmenseinheit, wie beispielsweise RHN. Standard ist ''. --set-com m on-nam e=hostname Üblicherweise nicht für die CA gesetzt. - Der allgemeine Name. --set-em ail= --rpm-packager=packager Üblicherweise nicht für die CA gesetzt. - Die -Adresse. Die Person, die das generierte RPM paketiert hat, wie z.b. "RHN Admin (rhn- 14

18 Kapitel 3. SSL-Infrastruktur --rpm-vendor=vendor -v, --verbose --ca-cert-rpm =CA_CERT_RPM --key-only --cert-only --rpm-only --no-rpm Der Anbieter des generierten RPMs, wie z.b. "IS/IT Example Corp." Z eigt ausführliche Mitteilungen an. Akkumulierend - weitere hinzugefügte "v"s resultieren in noch umfangreicheren Details. Selten verändert - Name der RPM-Datei, die das CA Z ertifikat beinhaltet (der Basis- Dateiname und nicht filename-versionrelease.noarch.rpm). Selten verwendet - Generiert nur einen privaten CA-Schlüssel. Siehe --gen-ca - -key-only --help für weitere Informationen. Selten verwendet - Generiert nur ein öffentliches CA-Zertifikat. Siehe --gen-ca --cert-only --help für weitere Informationen. Selten verwendet - Generiert nur ein RPM zur Implementierung. Siehe --gen-ca -- rpm-only --help für weitere Informationen. Selten verwendet - Führt alle CA-Schritte aus, bis auf die RPM-Generierung. Den folgenden Optionen muss der --gen-server-parameter vorangestellt werden: 15

19 Red Hat Network Satellite 5.4 Client-Konfigurationshandbuch T abelle 3.2. SSL Web-Server-Optionen (rhn-ssl-tool --gen-server --help) Option --gen-server -h, --help -p=, --password=password -d=, --dir=build_directory --server-key=filename --server-cert-req=filename --server-cert=filename --startdate=yymmddhhmmssz --cert-expiration=server_cert_expire --set-country=country_code --set-state=state_or_province --set-city=city_or_locality --set-org=organization --set-org-unit=set_org_unit Beschreibung Generiert SSL-Schlüssel-Set, RPM und T ar-archiv des Webservers. Diese Option muss in Z usammenhang mit irgendeiner der verbleibenden Optionen in dieser T abelle benutzt werden. Z eigt den Hilfebildschirm mit einer Liste von Basisoptionen in Z usammenhang mit der Generierung und Verwaltung eines Server- Schlüsselpaares an. Das CA-Passwort. Sie werden zur Eingabe des Passworts aufgefordert, wenn Sie dieses nicht von vornherein angeben. Bewahren Sie eine Kopie des Passworts an einem sicheren Ort auf. Für die meisten Befehle erforderlich - Das Verzeichnis, in welches Z ertifikate und RPM-Dateien beim Bauen gespeichert werden. Standard ist./ssl-build. Der Dateiname des privaten SSL- Schlüssels des Webservers. Standardmäßig ist dies server.key. Der Dateiname des SSL-Z ertifikats des Webservers, das vom Client angefragt wird. Standardmäßig ist dies server.csr. Der Dateiname des SSL-Z ertifikats des Webservers. Standardmäßig ist dies server.crt. Das Startdatum der Gültigkeit für das Server-Z ertifikat im Beispielformat: Jahr, Monat, Datum, Stunde, Minute, Sekunde (zwei Z eichen pro Wert). Z ist erforderlich und steht für Z ulu. Standardmäßig wird dieses Datum auf eine Woche vor Generierung gesetzt. Das Ablaufdatum des Server-Z ertifikats. Standardmäßig ist dies ein Tag vor dem Epochenwechsel (oder ). Der zweistellige Ländercode. Standard ist US. Der Staat oder die Provinz. Der Standardwert lautet North Carolina. Die Stadt oder der Ort. Der Standardwert lautet Raleigh. Die Firma oder Organisation, wie z.b. Red Hat. Der Standardwert lautet 'Example Corp. Inc.' Die Unternehmenseinheit, wie 16

20 Kapitel 3. SSL-Infrastruktur --set-hostnam e=hostname --set-em ail= --rpm-packager=packager --rpm-vendor=vendor -v, --verbose --key-only --cert-req-only --cert-only --rpm-only --no-rpm --server-rpm =SERVER_RPM --server-tar=server_tar beispielsweise RHN. Standardmäßig ist dies 'unit'. Der Hostname des RHN Servers, der den Schlüssel erhält. Standardmäßig ist dies der dynamisch gesetzte Hostname des Build-Rechners. Die -Adresse für den Kontakt bezügl. des Z ertifikats. Der Standardwert lautet 'admin@example.com'. Die Person, die das generierte RPM paketiert hat, wie z.b. "RHN Admin (rhnadmin@example.com)." Der Anbieter des generierten RPMs, wie z.b. "IS/IT Example Corp." Z eigt ausführliche Mitteilungen an. Akkumulierend - weitere hinzugefügte "v"s resultieren in noch umfangreicheren Details. Selten verwendet - Generiert nur einen privaten Server-Schlüssel. Siehe --genserver --key-only --help für weitere Informationen. Selten verwendet - Generiert nur eine Anfrage für ein Server-Z ertifikat. Siehe -- gen-server --cert-req-only -- help für weitere Informationen. Selten verwendet - Generiert nur ein Server-Z ertifikat. Siehe --gen-server -- cert-only --help für weitere Informationen. Selten verwendet - Generiert nur eine RPM-Datei zur Implementierung. Siehe -- gen-server --rpm-only --help für weitere Informationen. Selten verwendet - Führt alle Serverbezogenen Schritte mit Ausnahme der RPM-Generierung durch. Selten verändert - Name der RPM-Datei, die das SSL-Schlüssel-Set des Webservers beinhaltet (der Basis- Dateiname und nicht filename-versionrelease.noarch.rpm). Selten verändert - Name des.tar Archivs, welches das Webserver SSL-Schlüssel-Set und das öffentliche CA-Z ertifikat beinhaltet und ausschließlich von den Installationsroutinen des gehosteten RHN Proxy Servers verwendet wird (der Basis- Dateiname und nicht filename-versionrelease.tar). 17