Registrierungsstelle der TU Braunschweig CA

Transkript

1 Version vom: 2014/06/19 13:25 Seite: 1/15 für DV-Koordinatoren Zertifizierungsstelle der TU Braunschweig CA Im Rahmen seiner Public Key Infrastruktur erbringt der DFN-Verein Dienstleistungen für eine sichere, DFN-weite Kommunikation in abgestuften und anwendungsabhängigen Sicherheitsniveaus. Dabei liegt der Schwerpunkt auf fortgeschrittenen Zertifikaten auf Basis des X.509 Standards. Die TU Braunschweig CA ist eine Zertifizierungsstelle der Technischen Universität Braunschweig innerhalb der DFN-PKI. In der DFNPKI wird eine Zertifizierungshierarchie verwendet, bei der das Zertifikat der TU Braunschweig CA von der Wurzelzertifizierungsstelle des DFN-PKI, der DFNPCA, ausgestellt wird. Zertifikate des DFN sind wiederum von der Zertifizierungsstelle der Deutschen Telekom signiert. Letztere ist wiederum bei den meisten Anwendungen als sichere Zertifizierungsstelle bekannt und beispielsweise im Webbrowser oder Betriebssystem verankert. Die TU Braunschweig CA (Certification Authority) ist als Teil der PKI (Public Key Infrastructure) des DFN Vereins verantwortlich für die Verwaltung von Zertifikaten für die TU Braunschweig. Das betreibt eine Registrierungsinstanz für die Ausstellung von Server-Zertifikaten. Für den Betrieb der TU Braunschweig CA sind folgende Dokumente relevant: CP der DFN-PKI CPS der DFN-PCA CPS der TU Braunschweig CA Das CPS der TU Braunschweig CA enthält die abweichenden Regelungen zum CPS der DFN-PCA. Die an DFN ausgelagerten Informationsseiten zur TU Braunschweig CA finden Sie unter Andere Teilnehmer der DFN-PKI sind unter mit den zugehörigen Informationsseiten veröffentlicht. Registrierungsstelle der TU Braunschweig CA Der Betrieb einer CA wie der TU Braunschweig CA erfordert neben dem Betrieb der CA selbst auch die Einrichtung einer Registrierungsstelle (Registration Authority, RA). Die Aufgabe der Registrierungsstelle ist es, Zertifikate auszustellen und auf die Einhaltung der

2 Seite: 2/15 Zertifizierungsrichtlinien zu achten. Dies beinhaltet die Überprüfung (Registrierung) der Identität und Authentizität der Antragsteller von Zertifikaten (DV-Koordinatoren). Die beantragten Zertifikate werden nach der positiven Identitätsüberprüfung von einem Mitarbeiter der RA elektronisch signiert und per dem Antragsteller zugestellt. Zu beachten ist, dass die RA des s ausschliesslich Zertifikate für Server signiert. Andere Zertifikate (Personengebundene Zertifikate, Zertifikate untergeordneter CA's) werden nicht signiert. Die Authentifizierung der DV-Koordinatoren muss gemäß Abschnitt 3.2 der DFN-PKI Policy erfolgen. Für die Authentifizierung der Identität einer natürlichen Person gibt es mehrere in der DFN-PKI Policy benannte Verfahren, wobei an der TU Braunschweig CA stets das folgende in der DFN-PKI Policy unter angegebene Verfahren Anwendung finden soll: Die Authentifizierung eines Institutes bzw. einer Einrichtung der TU Braunschweig erfolgt im Rahmen der Registrierung durch die Vorlage aussagekräftiger Unterlagen. Dies geschieht durch entsprechende Mitteilungen der Verwaltung und liegen gewöhnlich bereits vor. In Einzelfällen (Neugründungen, Zusammenlegungen, Kooperationsvorhaben) kann eine entsprechende Bestätigung jedoch nötig sein. Das Institut/die Einrichtung benennt gemäß 2(1) der Nutzungsordnung zur Informationstechnologie der Technischen Universität Braunschweig einen DV-Koordinator (Meldung an das über ein entspr. Formular). Falls entsprechende Zertifikate benötigt werden, werden diese stets online über das Benutzerinterface der TU Braunschweig CA beantragt. Sofern entsprechende Zertifikate benötigt werden, müssen diese durch den DV-Koordinator als Beauftragten der Einrichtung/des Instituts erfolgen und werden stets online über das Benutzerinterface der TU Braunschweig CA beantragt. Der DV-Koordinator muss jeden Zertifikatsantrag persönlich bei der zuständigen RA (im IT-Service- Desk) vorlegen. Ein Mitarbeiter des IT-Service-Desk führt die Identitätsprüfung anhand eines amtlichen Ausweispapiers mit Lichtbild (Personalausweis oder Reisepass) durch. Warum Zertifikate für Server wichtig sind Wenn Sie vertrauliche Informationen wie beispielsweise persönliche Daten und Passworte an einen Webserver oder Mailserver übermitteln, sollte die Verbindung zum Server stets verschlüsselt sein. Dies ist notwendig, damit böswillige Dritte die Informationen nicht abhören und missbrauchen können. Verschlüsselung alleine ist jedoch nicht ausreichend. Mit geschickten Manipulationen ist es möglich, dass Angreifer Abfragen von beispielsweise Passwörtern auf gefälschte Webseiten/Server umlenken. Angreifer können so über eine verschlüsselte aber von einem gefälschten Server angebotene Verbindung an vertrauliche Informationen gelangen, ohne dass Sie als Benutzer davon etwas merken. Manipulationen dieser Art sind unter dem Schlagwort Phishing bekannt geworden. Sicher haben auch Sie schon von Angriffen auf Homebanking Angebote verschiedener Banken gehört oder sogar eine entsprechende erhalten, mit der man Sie auf einen gefälschten Server locken wollte. Daher ist es nicht ausreichend, die Kommunikation zwischen Ihrem Rechner und dem Server zu verschlüsseln. Genau wie Sie sich mit Ihrem Personalausweis, Benutzerkennungen und Passwörtern, Zugangsnummern sowie PINs und TANs ausweisen und authentifizieren, muss auch ein Server sich authentifizieren und beweisen, dass er wirklich derjenige Server ist, für den er sich ausgibt. Zertifikate sind in diesem Sinne digitale Ausweise und erfüllen den gewünschten Zweck.

3 Seite: 3/15 Probleme mit selbst erstellten Zertifikaten Die Verwendung so genannter selbst signierter Zertifikate ist vergleichbar mit dem Erstellen eigener Ausweisformulare, wie dies beispielsweise bei Mitarbeiterausweisen, Bibliotheksausweisen und anderen der Fall ist. Diese Dokumente sind nur innerhalb einer Organisation bekannt und anerkannt. Die Organisation muss selbst dafür sorgen, dass alle Mitglieder über Art und Beschaffenheit der Ausweise informiert ist. Es ist daher richtig und wichtig, dass Programme bei der Nutzung von selbst erstellten Zertifikaten als eine Art Ersatzausweis den Benutzer mit Warnungen auf die Problematik hinweisen. Der Benutzer hat so die Möglichkeit, die Legitimität dieser Zertifikate selbst zu überprüfen. Aufgrund von praktiziertem Missbrauch (Phishing bei Banking-Portalen) und einer Mischung aus Gewohnheit und Arglosigkeit sahen sich u.a. die Browser-Hersteller offenbar gezwungen, auf selbstsignierte Zertifikate mit mehr Nachdruck in Form von Fehlermeldungen hinzuweisen. Zertifikatskette Im Sinne der oben beschriebenen Zertifikatshierarchie gehören die von der TU Braunschweig CA ausgestellten Serverzertifikate zu einer Zertifikatskette. Informationen zur Zertifikatskette erhalten Sie auch auf den Info-Seiten der TU Braunschweig CA innerhalb der DFN-PKI. Die Zertifikatskette für alle Zertifikate der TU Braunschweig CA muss die folgenden Zertifikate enthalten: Wurzelzertifikat Deutsche Telekom Root CA 02 Zertifikat der DFN-PCA Global Zertifikat der TU Braunschweig CA siehe hierzu auch die entsprechende Info-Seite der TU Braunschweig CA beim DFN e.v. In der Vergangenheit war es in Ausnahmefällen nötig, dass Sie das Zertifikat Deutsche Telekom Root CA 02 auf Ihrem Gerät manuell installieren mussten. Die Zertifikatsdateien sind Online auf den Seiten verfügbar. Da alle neuen Zertifikate innerhalb der DFN-PKI ausgestellt werden und beispielsweise bei Windows Betriebssystemen, in neueren MacOS-Versionen und auch in aktuellen Versionen des Firefox-Browsers das Wurzelzertifikat der Deutschen Telekom Root CA 02 bereits mitgeliefert wird, ist die manuelle Installation nur noch in sehr

4 Seite: 4/15 wenigen Ausnahmefällen nötig. Zertifikat für Server beantragen Um ein Zertifikat für einen Server zu beantragen, müssen folgende Arbeitsschritte durchgeführt werden: 1. Sie sind von Ihrem Institut bzw. Ihrer Einrichtung als DV-Koordinator schriftlich benannt worden (vergl. entsprechendes Antragsformular). 2. Sie tragen einige Basisinformationen über den Server, für den Sie ein Zertifikat beantragen wollen, zusammen. Es wird der Name CN, eine Adresse für Kontaktmöglichkeiten benötigt. Ferner legen Sie den Einsatzzweck über das Zertifikatsprofil (u.a. Web-, LDAP- oder Mail-Server) fest. 3. Sie generieren einen Zertifikatsantrag (certificate request). 4. Sie beantragen das Zertifikat über die Online-Schnittstelle der TU Braunschweig RA für DV-Koordinatoren. 5. Bei der Beantragung legen Sie eine Sperr-PIN fest. Mit dieser können Sie das Zertifikat später selbst der Sperrung zuführen. Die Sperr-PIN hat den Charakter eines Passwortes und ist sicher zu verwahren. 6. Ein Mitarbeiter der Registrierungsstelle der TU Braunschweig CA prüft die von Ihnen persönlich im IT-Service-Desk vorgelegten Anträge. Die Zertifizierungsrichtlinien schreiben vor, dass Sie bei jeder Beantragung eines Zertifikates für Ihre Einrichtung persönlich mit einem gültigen, amtlichen Lichtbildausweis und dem ausgedruckten und unterschriebenen Antrag vorstellig werden müssen. 7. Das Zertifikat wird digital signiert und Ihnen per zugestellt. Diese enthält auch die Seriennummer, die u.a. für Rückfragen bei uns oder auch für eine Sperrung des Zertifikates durch Sie benötigt wird. 8. Sie installieren das Zertifikat auf dem Server Während die eigentliche CA, die Zertifizierungsstelle, an den DFN-Verein ausgelagert ist, ist im der Teilnehmerservice der Registrierungsstelle der TU Braunschweig CA (RA) untergebracht. Aufgabe des Teilnehmerservice der RA ist es, Zertifikate auszustellen und auf die Einhaltung der Zertifizierungsrichtlinien zu achten. Die Zertifizierungsrichtlinien enthalten externe Vorgaben. Die Einhaltung dieser Vorgaben sind Grundlage dafür, dass die Zertifikate in Betriebssystemen und Browsern verankert sind. Die Basisinfos für einen Zertifikatsantrag Laut CA-Policy sind etliche Zertifikatsattribute vorgegeben, die den Rechner bzw. Server identifizieren sollen: countryname-attribut Das countryname-attribut benennt den Ländernamen im sog. 2 letter country code, siehe auch

5 Seite: 5/15 Hier steht für Zertifikatsanträge an die TU Braunschweig CA: DE stateorprovincename-attribut Das Attribut stateorprovincename benennt für Anträge in der TU Braunschweig CA das Bundesland in dem die TU Braunschweig ihren Sitz hat: Niedersachsen localityname-attribut Für das Attribut localityname ist Braunschweig anzugeben. CN-Attribut Das CN-Attribut ist das wichtigste Attribut Es muss den vollständigen Namen des Servers beinhalten. Gemeint ist dabei der vollständige Servername mit Domainangabe (FQDN, fully qualified domain name ). Dieser ist beispielsweise im KDD nachzuschlagen oder mit den Kommandos nslookup bzw. host per DNS abzufragen. In Ausnahmefällen kann auch der Name gesetzt werden, unter dem der Dienst im Netz erreichbar sein soll (Stichworte DNS-Alias, Virtual Host ). In der Regel werden Namen, unter denen der Dienst im Netz erreichbar sein soll, nicht als CN über den FQDN angegeben, sondern über sog. alternative Attribute. Diese teilen Sie uns bitte als schriftliche Ergänzung zum Zertifikatsantrag (formlos) mit. Beispiel FQDN zur Verwendung als CN-Attribut: server01.inst.misc.tu-bs.de Beispiel alternatives Attribut (vom Typ DNS): CN-Attribute müssen zwingend auf eine der auf die TU Braunschweig registrierten Domains tu-bs.de oder tu-braunschweig.de enden. -Attribut Das -Attribut benennt eine administrative -Adresse, an welche Anfragen zu richten sind, falls es Probleme mit dem angebotenen Dienst des Servers gibt. Diese - Adresse muss auf tu-bs.de oder tu-braunschweig.de enden. Achten Sie darauf, dass der Empfänger bereits zur Beantragung des Zertifikates erreichbar ist. OU-Attribut Laut Policy sind mehrere OU-Attribute (organisational unit) erlaubt. 1. Es dürfen nur etablierte Namen und Kurzformen verwendet werden. 2. Umlaute sind nicht erlaubt.

6 Seite: 6/15 3. Die OU-Attribute dürfen sich nicht widersprechen. Zertifikatsantrag erzeugen Zertifikatsantrag und privaten Schlüssel erzeugen Wenn Sie noch kein SSL auf Ihrem Server einsetzen, verfahren Sie bitte, wie im Folgenden beschschrieben. Zertifikatsanträge müssen in einem maschinell verarbeitbaren Format bei der RA eingereicht werden, dem Public Key Cryptography Standard Nr 10, PKCS#10, und werden bei Verwendung eines geeigneten Werkzeuges automatisch erstellt. Der Zertifikatsantrag setzt sich aus 4 Teilen zusammen: 1. dem Subject Distinguished Name, kurz DN, die teilweise durch die Policy vorgegeben sind, wie Landesbezeichnung, Country, C=de; die Ortsbezeichnung O=Technische Universitaet Braunschweig 2. den optionalen Attributen 3. einer digitalen Signatur mit dem privaten Schlüssel (der später auch auf dem Server abgelegt wird) 4. einer Kennzeichnung des verwendeten Signaturalgorithmus Insbesondere wenn Sie mehrere Zertifikate beantragen, sollten Sie sich beispielsweise eine Konfigurationsdatei für OpenSSL erstellen, in der die wesentlichen Angaben bereits enthalten sind. Im Unterabschnitt OpenSSL-Konfigurationsdatei ist ein Beispiel angegeben. Zertifikate für einen Windows-Dienst erstellen Sie am besten mit Unterstützung dieses Supportartikels (D307267) von Microsoft. Falls Sie Ihren Dienst bisher ohne Zertifikat betreiben, müssen Sie ein entsprechendes Schlüsselpaar nach dem RSAVerfahren erzeugen. Das folgende openssl-kommando führt die Schlüsselgenerierung, die Abfrage eines Passwortes für diesen Schlüssel, die Attribut-Abfrage und die anschliessende Erstellung des Zertifikatsantrages durch: openssl req -config rzkey.conf -newkey rsa:2048 -sha1 -outform pem -out certreq.pem Die einzelnen Befehlsteile bedeuten folgendes: 1. openssl: Programmname des Openssl-Kommandos, evtl. muss der komplette Pfad, z.b. /usr/local/bin/openssl angegeben werden. 2. req: erstellt einen PKCS#10-Antrag 3. -config: verweist ggf. auf die ssl-konfig-datei für Voreinstellungen, siehe Abschnitt OpenSSL Konfigurationsdatei 4. -newkey rsa:2048: neues Schlüsselpaar mit RSA und einer Key-Länge von 2048 Bit 5. -sha: Secure Hash Algorithm Nr. 1 wird als Streumechanismus für die Erstellung kryptographisch sicherer Prüfsummen verwendet 6. -outform PEM: Privacy Enhanced Mail Ausgabeformat 7. -out certreq.pem: speichert den Antrag unter certreq.pem. Achtung: die Konfigurationsdatei enthält die Direktive, den neu zu erstellenden privaten Schlüssel in server-key.pem zu speichern.

7 Seite: 7/15 Sollen mehrere Anträge hintereinander erstellt werden, müssen die Dateien nach jedem Durchgang umbenannt werden, um ein Überschreiben zu vermeiden! Zertifikatsantrag ohne erneute Erzeugung eines privaten Schlüssel erzeugen Setzen Sie bereits SSL auf Ihrem Server ein und möchten Sie den dafür verwendeten private key weiter verwenden, so erzeugen Sie den Zertifikatsrequest wie in diesem Abschnitt beschrieben. Läuft der Dienst mit einem selbst signierten Zertifikat und haben Sie bereits einen RSA-Schlüssel erstellt mit einer Länge von 2048 Bit, können Sie diesen Schlüssel für Ihr neues Zertifikat weiter verwenden. Mit folgendem Kommando kann dann eine Zertifizierungsanfrage für den vorhandenen Key (server.key) erstellt werden: openssl req -new -config rzkey.conf -key server.key -keyform PEM -sha1 -outform pem -out certreq.pem Mit -keyform PEM bzw. -keyform DER sollten Sie das Format des vorhandenen Schlüssels berücksichtigen. Entfernen der Passphrase für automatischen Start von Diensten Beachten Sie bitte auch, dass Sie den Dienst den Sie mit dem so beantragten Zertifikat ausstatten beim Start/Neustart stets die Angabe der Passphrase erfordert. Um einen Dienst auch ohne manuelle Eingabe der Passphrase starten zu können, muss man ggf. auf die Passphrase verzichten. Für den Betrieb von Diensten, die auch nach einem ungeplanten Neustart des Servers (z.b. Stromausfall, Softwarefehler) sofort und ohne manuelle Intervention erreichbar sein sollen, muss die Passphrase entfernt werden. Darüber hinaus setzen manche Produkte voraus, dass man zuvor die Passphrase entfernt. Das Entfernen der Passphrase ist kritisch und aus Sicht der IT-Sicherheit nicht empfehlenswert. Das Zertifikat auf dem Server ist dann ungeschützt hinterlegt und kann bei einer Kompromittierung des Servers besonders einfach kopiert und für Angriffe genutzt werden. Grundsätzlich - ob mit oder ohne Passphrase - gilt: Sollte der Server gehackt werden, so ist das Zertifikat samt private key nicht mehr vertrauenswürdig. Das Zertifikat muss dann umgehend gesperrt werden. Sie müssen in einem solchen Fall sowohl einen neuen private key generieren, als auch ein neues Zertifikat beantragen. Das Entfernen der Passphrase kann man mit dem folgenden Kommando durchgeführt werden: openssl rsa -in serverkey.pem -out serverkey_nopass.key In Abhängigkeit von der Version von OpenSSL kann die genaue Kommandosyntax leicht abweichen. OpenSSL Konfigurationsdatei

8 Seite: 8/15 In manchen der zuvor aufgeführten Kommandos wird eine Konfigurationsdatei referenziert:... -config rzkey.conf... Der Inhalt einer solchen Datei könnte wie folgt aussehen: # # opensslkey.conf # HOME =. RANDFILE = $ENV::HOME/.rnd #################################################################### [ req ] default_bits = 2048 default_keyfile = server-key.pem distinguished_name = req_distinguished_name attributes = req_attributes # nombstr : PrintableString, T61String (no BMPStrings or UTF8Strings). string_mask = nombstr # req_extensions = v3_req # The extensions to add to a certificate request [ req_distinguished_name ] countryname = Laendername (bitte nicht aendern) countryname_default = DE countryname_min = 2 countryname_max = 2 0.organizationName aendern) 0.organizationName_default = Name der Organisation (bitte nicht = Technische Universitaet Braunschweig 0.organizationalUnitName = Offizieller Name Einrichtung oder Institut (ohne Umlaute) 0.organizationalUnitName_default = 1.organizationalUnitName = Optional Abteilung des Instituts oder Arbeitsgruppe im Institut 1.organizationalUnitName_default = stateorprovincename = Bundesland (ausgeschrieben) stateorprovincename_default = Niedersachsen localityname = Locality Name - Stadt (Sitz der TU Braunschweig) localityname_default = Braunschweig commonname = Voll qualifizierter DNS-Name unter dem der Service erreichbar ist commonname_max = 64 address = -Adresse der Einrichtung (Support- oder Sammeladresse bevorzugt)

9 Seite: 9/15 address_max = 40 address_default = # SET-ex3 = SET extension number 3 [ req_attributes ] # unstructuredname = An optional company name [ v3_req ] # Extensions to add to a certificate request basicconstraints = CA:FALSE keyusage = nonrepudiation, digitalsignature, keyencipherment Zertifikat sperren Sollte Ihr Server kompromittiert worden sein oder sollte es Zweifel geben, dass der private key möglicher Weise offen gelegt worden ist, ist die Sperrung des auf diesem privaten Schlüssel basierenden Zertifikat notwendig. Sie haben bei der Beantragung des Zertifikates entsprechende Handlungsanweisungen unterschrieben. Auch sollten Sie bei Beantragung eines neuen Zertifikats als Ersatz oder Erneuerung für ein bereits bestehendes das vorherige Zertifikat sperren. Für die Beantragung der Sperrung benötigen Sie die bei der Beantragung angegebene Sperr-PIN. Durch die Sperrung eines Zertifikats wird dessen eindeutige Seriennummer auf einer Sperrliste/Widerrufsliste (certificate revocation list, CRL) veröffentlicht. Bezüglich der Umsetzung der Sperrung von Zertifikaten bei Clients ist zur Zeit in manchen Fällen noch einiges im Argen. Im Idealfall ist bei einem gesperrten Zertifikat weitere Verwendung des Zertifikates aufgrund der Prüfung der Sperrliste seitens der Clients verhindert. Die Sperrung eines Zertifikats lässt sich nicht rückgängig machen. Sollte ein Zertifikat irrtümlich gesperrt worden sein, müssen Sie ein neues Zertifikat beantragen. Zur Durchführung einer Sperrung halten Sie bitte die Sperr-PIN und die Seriennummer des zu sperrenden Zertifikates bereit. Gehen Sie mit einem Webbrowser auf die Seite der Online-Schnittstelle der TU Braunschweig CA Wählen Sie aus dem Menü auf der linken Seite den Eintrag Zertifikate aus. Auf dieser Seite können Sie u.a. über den Reiter Zertifikat sperren unter Angebe von Seriennummer, Sperrgrund und im Folgenden Sperr-PIN ein Zertifikat zur Sperrung einreichen. Wenn Sie die Seriennummer nicht zur Hand haben, können Sie auch über den Reiter Zertifikat suchen anhand von CN oder im Zertifikat angegebener Adresse das Zertifikat suchen. Dies funktioniert allerdings nur, wenn das Zertifikat veröffentlicht wurde. Für Zertifikate, die nicht als öffentlich eingetragen sind, brauchen Sie grundsätzlich die Seriennummer des Zertifikats. Die Seriennummer wurde Ihnen auch in der Mail mitgeteilt, die Sie nach der Freischaltung des Zertifikates erhalten haben. Wenn Sie die Sperr-PIN nicht beibringen können, so stellen Sie sich bitte darauf ein, dass seitens des Teilnehmerservice der CA geeignete Methoden zur Verifikation und Absicherung durchgeführt werden müssen. Dies soll verhindern, dass Zertifikate unberechtigt gesperrt werden.

10 Seite: 10/15 Zertifikate installieren Dieser Abschnitt ist für DV-Koordinatoren gedacht und soll das Installieren von Zertifikaten auf Servern und Clients unterstützen. Installation eines Zertifikats für Apache2 unter SLES10 Die Konfiguration der Zertifikate ist prinzipiell bei allen Apache2 Installationen sehr ähnlich hier wird ein SuSE Linux Enterprise Server mit Service Pack 1 verwendet. Folgende Dateien werden benötigt: cacertchain.crt: Diese Datei enthält alle über dem Server liegenden Zertifikate bis zum Root Zertifikat der Telekom. Die entsprechende Datei können Sie sich über das Benutzerinterface der TU Braunschweig CA herunterladen. cert-xxxxxxxxx.pem: Diese Datei erhalten Sie von der TU Braunschweig CA per Mail nachdem Ihr Zertifikatsantrag erfolgreich bearbeitet wurde. privkey.pem: Der private Schlüssel des Servers. Zur Installation sind die folgenden Schritte nötig: 1. Stoppen Sie einen eventuell gestarteten Apache2 (z.b. mit apache2ctl stop oder /etc/init.d/httpd stop ) 2. Kopieren Sie die drei Zertifikatsdateien in einen Unterordner des Apache Webservers (z.b. :/etc/apache2/ssl.key/) 3. Editieren Sie bzw. legen Sie eine neue V-Hosts-Datei unter /etc/apache2/vhosts.d an. In der Konfigurationsdatei des V-Hosts werden unter anderem die Zertifikate mit angegeben. Wichtig ist, dass der ServerName genau mit dem Namen angegeben wird, für den Sie das Zertifikat beantragt haben. Den Aufbau der Datei (Beispielkonfiguration) finden Sie weiter unten. 4. Aktivieren Sie Mod_SSL für den Apache-Webserver (diese Einstellung können Sie u.a. auf einfache Weise unter Yast setzen). 5. Starten Sie den Apache2 neu mit dem Befehl apache2ctl -DSSL 6. Installation eines Zertifikats für Apache2 unter SLES10 Beispielkonfiguration: vhost-ssl.conf <IfDefine SSL> <IfDefine!NOSSL> <VirtualHost _default_:443> DocumentRoot "/srv/www/htdocs" ServerName rzbeispiel.rz.tu-bs.de:443 ServerAdmin flo.haake@tu-braunschweig.de ErrorLog /var/log/apache2/error_log TransferLog /var/log/apache2/access_log SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:

11 Seite: 11/15 +SSLv2:+EXP:+eNULL SSLCertificateFile etc/apache2/ssl.key/certxxxxxxxxx.pem SSLCertificateKeyFile /etc/apache2/ssl.key/privkey.pem SSLCertificateChainFile /etc/apache2/ssl.key/cacertchain.crt <Files ~ "\.(cgi shtml phtml php3?)$"> SSLOptions +StdEnvVars </Files> <Directory "/srv/www/cgi-bin"> SSLOptions +StdEnvVars </Directory> CustomLog /var/log/apache2/ssl_request_log ssl_combined SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 </VirtualHost> </IfDefine> </IfDefine> Zertifikate für Clients installieren Die hier wiedergegebene Liste ist exemplarisch für einige wenige Programme. Das Vorgehen beim Installieren der Zertifikate geschieht wie folgt: Internet Explorer Der Internet Explorer nutzt den Zertifikatsspeicher von Microsoft Windows. Die Installation der oben angegebenen Zertifikate sollte nicht notwendig sein. Windows Vista lädt die Zertifikate automatisch im Hintergrund nach, auch hier sollte kein manuelles Installieren nötig sein. Falls Sie doch manuell installieren wollen oder müssen: Nutzen Sie die Info-Seiten der TU Braunschweig CA, um die Zertifikate im DER-Format herunterzuladen. Klicken Sie dann auf Zertifikat installieren.

12 Seite: 12/15 Es meldet sich der Zertifikatsimport-Assistent. Klicken Sie auf Weiter. Im nächsten Fenster wählen Sie die Option Zertifikatspeicher automatisch auswählen, dann wieder Weiter.

13 Seite: 13/15 Im nächsten Fenster (Abb. 5) bekommen Sie die Einstellungen angezeigt und können den Vorgang fertigstellen. Zum Abschluss bekommen Sie eine Erfolgsmeldung. Firefox-Browser (und analog Thunderbird) Nutzen Sie den Link zum Wurzelzertifikat Deutsche Telekom Root CA 02 zum direkten Import oder nutzen Sie die Info-Seiten der TU Braunschweig CA und speichern Sie das zu installierende Zertifikat

14 Seite: 14/15 auf Ihrem Rechner. Zertifikate werden über den Zertifikats-Manager importiert. Diesen rufen Sie direkt auf, wenn Sie den Link Wurzelzertifikat Deutsche Telekom Root CA 02 nutzen oder Sie gehen wie folgt vor: Rufen Sie in der Menü-Zeile des Browsers die Einstellungen und dort unter der Schaltfläche Erweitert die Reiterkarte Verschlüsselung auf. Im Abschnitt des Zertifikats-Manager lassen Sie sich die Zertifikate anzeigen. Unter Zertifizierungsstellen klicken Sie auf Importieren, um die zuvor heruntergeladene Zertifikatsdatei einzubinden. Im Nachfolgenden Importdialog setzen Sie mindestens den Haken bei Dieser CA vertrauen, um Websites zu identifizieren. Überprüfen Sie ggf. über Ansicht das Zertifikat. Klicken Sie auf OK. Zertifikate müssen über den Firefox Browser nur für die Benutzung im Firefox Browser selbst installiert werden. Die Installation der Zertifikate ist nur bis Firefox Version 2.0.X erforderlich. Die Installation bei Thunderbird erfolgt analog. Das Stammzertifikat der Telekom Root CA ist in den aktuellen Versionen des Firefox Browsers (seit Version 3.*) und des Mail-Programms Thunderbird mit enthalten. SecureW X-Supplikant Das Tool SecureW2 nutzt den Zertifikatsspeicher von Microsoft Windows. Hier muss beim Verbinden lediglich angegeben werden, welchen Zertifikaten das Programm vertrauen soll. Beim Verbinden mit den SSIDs eduroam und 802.1X wird die Zertifikatskette in einem Fenster nur dann angezeigt, wenn nicht der von uns bereitgestellte Installer benutzt wird. Bei der Anmeldung am Netzwerk wird Ihnen die Zertifikatskette angezeigt. Klicken Sie in einem solchen Fall bitte auf Install All Certificates und bestätigen die dann folgende Meldung mit OK. (Sie sollten jedoch die Fingerabdrücke der Zertifikate mit denen auf den Info-Seiten der TU Braunschweig CA vergleichen.) Intel(R) PROSet/Wireless Das Tool für Wireless LAN auf Geräten mit Intels Centrino Chipsätzen nutzt den Zertifikatsspeicher von Microsoft Windows. Gehen Sie bei der Installation der Zertifikate wie beim Internet Explorer vor, jedoch sollte das Betriebssystem dieses Zertifikat bereits enthalten.

15 Seite: 15/15 Benutzerzertifikate Benutzerzertifikate werden nicht ausgestellt, da hier seitens des s enge Verknüpfungen zu Projekten des Identity Managements gesehen werden.