Universität Hamburg - der Forschung, der Lehre, der Bildung, zur Homepage
RRZ
Regionales
Rechenzentrum

Foto: UHH, RRZ/MCC

Server-Zertifikat installieren

Wenn Sie Ihr Zertifikat erhalten haben, muss es installiert werden, so dass der jeweilige Dienst es verwenden kann. Dieser Vorgang ist natürlich hochgradig anwendungsspezifisch und kann daher hier nur an einem Beispiel diskutiert werden.

Gleichwohl ist das Beispiel insofern praxisnah, als dass einer der am weitesten verbreiteten Dienste betrachtet wird und die meisten Fallstricke und ihre Lösungen angesprochen werden, die hier bei der Verwendung von Zertifikaten auftreten können.

Verwenden eines Server-Zertifikats mit einem Apache 2.0 Web-Server

Häufig wird der Apache WWW-Server als Basis für Web-Auftritte verwendet. Möchte man die Datenübertragung von und zu diesem Server authentifizieren und verschlüsseln, sollte man für den Zugriff nicht das normale HTTP-Protokoll (vgl. RFC1945, RFC2616, RFC2817) , sondern das sicherere HTTPs-Protokoll verwenden. Beispielsweise sollte man Benutzerkennungen und dazugehörende Passworte grundsätzlich nur verschlüsselt übertragen.

HTTPs wiederum bedeutet, dass die oben referenzierten HTTP-Protokolle in einer SSL bzw. TLS-Verbindung (vgl. RFC2246, RFC2817, RFC2818, RFC3268) eingebettet sind. Im Zuge der Verbindungseröffnung (in unserem Beispiel vom Browser zum Web-Server) findet dann auch ein einseitiger oder zweiseitiger Zertifikatsaustausch statt, auf dessen Basis dann wiederum eine Verschlüsselung und Integritätssicherung der übertragenen Daten stattfinden kann.

  • Der einseitige Zertifikatsaustausch wird in diesem Beispiel konfiguriert. Hierbei präsentiert der Web-Server dem Browser der Anwender sein Zertifikat und vorbehaltlich der Akzeptanz durch den Browser werden anschließend die Daten gesichert übertragen. Der einseitige Zertifikatsaustausch reicht in all den Fällen aus, in denen der Web-Server die Identität der Benutzer entweder nicht benötigt oder mit Hilfe andere Mittel (beispielsweise HTTP-Passwort-Dialog) unabhängig von einem Client-Zertifikat ermittelt. Hierbei ist zu beachten, dass die Übertragung von Benutzerkennung und Passwort in einem HTTP-basierten Passwort-Dialog bereits bei diesem einseitigen Zertifikatsaustausch verschlüsselt erfolgt und somit gegen Mitlesen durch Dritte geschützt ist.
  • Der zweiseitige Zertifikatsaustausch wird verwendet, wenn nicht nut der Server über ein Server-Zertifikat verfügt, sondern die Benutzer ebenfalls über Benutzer-Zertifikate. In diesem Fall präsentiert der Server den Benutzern sein Zertifikat für die oben dargestellte Absicherung der Datenübertragung und kann optional, z.B. bei Zugriff auf geschützte Bereiche des Web-Auftritts, anstelle des HTTP-basierten Passwort-Dialogs ein Benutzer-Zertifikat anfordern. In diesem Szenario ist es möglich, dass sich Benutzer automatisch mit ihrem Zertifikat aufgrund der Anfrage des Servers bei Zugriffen auf geschützte Bereiche ausweisen, ohne dass die Benutzer interaktiv eingreifen müßten. Damit ist dieses Szenario die Grundlage für moderne "single-sign-on"-Zugriffsmethoden.

In den folgenden Abschnitten wird die Installation eines Apache-Web-Servers inklusive Server-Zertifikat auf einem UNIX-System beschrieben. Anschließend werden die wichtigsten Konfigurationsanweisungen für die "richtige Verwendung" der Zertifikate und Sperrlisten beschrieben.

Erforderliche Software

Die erforderliche Software ist frei verfügbar und setzt sich zusammen aus

  1. der Apache-Server-Software, die Sie hier finden,
  2. der für die TLS/SSL-Protokolle erforderlichen OpenSSL-Software, die Sie hier finden oder bereits auf Ihrem Rechner für die Erstellung des PKCS#10 Antrags installiert haben und
  3. optionaler Software, wie beispielsweise das häufig anzufindene PHP-Modul.

Falls Sie die Software --so wie hier dargestellt-- neu übersetzen, laden Sie bitte vorher möglichst aktuelle Quelldateien herunter.

Installation von OpenSSL

OpenSSL installieren Sie am besten durch Aufruf des mitgelieferten Konfigurationskommandos. Typischerweise lauten die Kommandos für die Übersetzung und Installation von OpenSSL:

kruemel:~/openssl-0.9.7g> ./config
[sehr viele Meldungen an dieser Stelle]

kruemel:~/openssl-0.9.7g> make
[noch mehr Meldungen aber hoffentlich keine Fehlermeldungen]

kruemel:~/openssl-0.9.7g> su root
Password:
# pwd
/usr/local/source/openssl-0.9.7g
# make install
[und noch einmal sehr viele Meldungen]
# ^Dkruemel:~/openssl-0.9.7g>

Falls die Übersetzung und Installation funktioniert hat, finden Sie anschließend im Verzeichnis /usr/local/ssl/ die OpenSSL-Installation. Mit dem folgenden Kommando können Sie prüfen, ob das "openssl"-Kommando funktioniert, dass Sie beispielsweise für die Erstellung des PKCS#10 Antrags verwenden können:

kruemel:~/openssl-0.9.7g> /usr/local/ssl/bin/openssl help
openssl:Error: 'help' is an invalid command.

Standard commands
asn1parse      ca             ciphers        crl            crl2pkcs7
dgst           dh             dhparam        dsa            dsaparam
enc            engine         errstr         gendh          gendsa
genrsa         nseq           ocsp           passwd         pkcs12
pkcs7          pkcs8          prime          rand           req
rsa            rsautl         s_client       s_server       s_time
sess_id        smime          speed          spkac          verify
version        x509

Message Digest commands (see the `dgst' command for more details)
md2            md4            md5            mdc2           rmd160
sha            sha1

Cipher commands (see the `enc' command for more details)
aes-128-cbc    aes-128-ecb    aes-192-cbc    aes-192-ecb    aes-256-cbc
aes-256-ecb    base64         bf             bf-cbc         bf-cfb
bf-ecb         bf-ofb         cast           cast-cbc       cast5-cbc
cast5-cfb      cast5-ecb      cast5-ofb      des            des-cbc
des-cfb        des-ecb        des-ede        des-ede-cbc    des-ede-cfb
des-ede-ofb    des-ede3       des-ede3-cbc   des-ede3-cfb   des-ede3-ofb
des-ofb        des3           desx           idea           idea-cbc
idea-cfb       idea-ecb       idea-ofb       rc2            rc2-40-cbc
rc2-64-cbc     rc2-cbc        rc2-cfb        rc2-ecb        rc2-ofb
rc4            rc4-40         rc5            rc5-cbc        rc5-cfb
rc5-ecb        rc5-ofb

kruemel:~/openssl-0.9.7g>

Installation des Apache-Servers

Die Übersetzung und Installation des Apache-Servers aus den Quellcodes ist dank der "autoconf"-Skripte normalerweise trivial. Um sicher zu gehen, dass die im vorigen Schritt erstellten OpenSSL-Bibliotheken vom Apache-Server für das Zertifikatsmanagement und die Sicherung der Verbindungen mit den SSL/TLS-Protokollen auch tatsächlich verwendet werden, sollten Sie dies dem Konfigurationsskript explizit mitteilen:

kruemel:~/httpd-2.0.54> ./configure --enable-ssl --enable-rewrite
[sehr viele Meldungen an dieser Stelle]

kruemel:~/httpd-2.0.54> make
[noch mehr Meldungen aber hoffentlich keine Fehlermeldungen]

kruemel:~/httpd-2.0.54> su root
Password:
# make install
[und noch einmal sehr viele Meldungen]
#^Dkruemel:~/httpd-2.0.54>

Anschließend finden Sie die Apache-Server-Installation im Verzeichnis /usr/local/apache2. Dort wird im Folgenden die Konfigurationsdatei editiert, um Verschlüsselung und Verwendung von Zertifikaten einzustellen.

Basiskonfiguration (httpd.conf)

Die folgenden Schritte zeigen die minimal erforderlichen Anpassungen an der Hauptkonfigurationsdatei des Apache-Servers. Wechseln Sie dazu in das Verzeichnis /usr/local/apache2/conf und editieren Sie die Datei "httpd.conf". Falls diese Datei nicht auffindbar ist, finden Sie möglicherweise eine Sicherungskopie unter dem Namen "httpd-std.conf".

  • Suchen Sie den Eintrag Group #-1 und tragen Sie hier eine gültige Gruppenkennung aus /etc/groupein. Es sollte sich um eine Kennung handeln, die Sie für keinen anderen Dienst auf dem System verwenden. Beispiel: 
    Group nobody
  • Suchen Sie den Eintrag ServerAdmin you@example.com und ersetzen Sie die E-Mail-Adresse durch die E-Mail-Adresse, die Sie im Zertifikatsantrag angegeben haben.
  • Suchen Sie den Eintrag #ServerName www.example.com:80und ersetzen Sie den "full-qualified-domain-name" durch den Namen des Rechners, den Sie im "DN"-Attribut des Zertifikatantrags angegeben haben. Beispiel: 
    ServerName kruemel.rrz.uni-hamburg.de:80
    Die im Beispiel hinter dem Namen angegebene Zahl bezeichnet die Standard-Portnummer für Web-Server. Sie sollten hier ebenfalls :80 hinter den Namen Ihres Rechners anhängen.
  • Entfernen Sie vor den oben genannten Schlüsselwörtern eventuell vorhandene Kommentarsymbole ("#"), damit der Server die Angaben auch findet.

Anschließend können Sie prüfen, ob ihr Server grundsätzlich betriebsbereit ist, indem Sie ihn starten und per Browser "ansurfen". Sie sollten dann eine Startseite des Apache-Servers sehen. Alternativ können Sie auch mit ein paar UNIX-Kommandos prüfen, ob Ihr Server funktioniert:

root@kruemel:/<1>local/apache2/conf# ls ../logs/access_log error_log ssl_request_log root@kruemel:/<1>local/apache2/conf# cat /dev/null > ../logs/error_log root@kruemel:/<1>local/apache2/conf# cat /dev/null > ../logs/access_log root@kruemel:/<1>local/apache2/conf# cat /dev/null > ../logs/ssl_request_log root@kruemel:/<1>local/apache2/conf# ../bin/apachectl start root@kruemel:/<1>local/apache2/conf# cat ../logs/error_log [Fri Jan 27 14:04:53 2006] [warn] Init: Session Cache is not configured [hint: SSLSessionCache] [Fri Jan 27 14:04:54 2006] [notice] Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7g configured \ -- resuming normal operations root@kruemel:/<1>local/apache2/conf# ps -ef | grep httpd nobody 1040 1038 0 14:04:55 ? 0:00 /usr/local/apache2/bin/httpd -k start root 1038 1 1 14:04:53 ? 0:01 /usr/local/apache2/bin/httpd -k start nobody 1043 1038 0 14:04:55 ? 0:00 /usr/local/apache2/bin/httpd -k start nobody 1039 1038 0 14:04:55 ? 0:00 /usr/local/apache2/bin/httpd -k start nobody 1042 1038 0 14:04:55 ? 0:00 /usr/local/apache2/bin/httpd -k start nobody 1041 1038 0 14:04:55 ? 0:00 /usr/local/apache2/bin/httpd -k start root@kruemel:/<1>local/apache2/conf#

Im ersten Befehlsblock werden eventuell vorhandene Log-Dateien gelöscht. Das sollten Sie vor Tests immer machen, damit Sie nach einem Test sofort erkennen, welchen Log-Daten der Server während des Tests geschrieben hat.

Mit dem darauf folgenden Befehl (/usr/local/apache2/bin/apachectl start) wird der Server gestartet. Die Ausgabe der Datei /usr/local/apache2/logs/error_log zeigt, das alles in Ordnung ist (resuming normal operations). Darüber hinaus erkennt man, dass der Server über das auf OpenSSL basierende Modul zur Verschlüsselung, Authentifikation und Zertifikatsverwaltung verfügt (mod_ssl/2.0.54 OpenSSL/0.9.7g configured), das wir im nächsten Abschnitt für die Verwendung des Server-Zertifikats konfigurieren werden.

Der letzte Befehlsblock zeigt noch einmal, dass tatsächlich Server-Prozesse aktiv sind, um Anfragen von Benutzern entgegen zu nehmen. Vor dem nächsten Schritt sollten Sie den Server nun wieder beenden. Das machen Sie am besten mit dem folgenden Kommando:

root@kruemel:/<1>local/apache2/conf# ../bin/apachectl stop

Basiskonfiguration (ssl.conf)

In der Datei /usr/local/apache2/conf/ssl.conf werden die Einstellungen für die Verwendung von Zertifikaten, Sperrlisten, verwendbare Verschlüsselungsalgorithmen usw. vorgenommen. Auch hier werden nur die notwendigsten Einstellungen gezeigt, die für einen sicheren Verbindungsaufbau zwischen Browser und Web-Server erforderlich sind.

Wechseln Sie in das Verzeichnis /usr/local/apache2/conf und editieren Sie die Datei "ssl.conf". Falls diese Datei nicht auffindbar ist, finden Sie möglicherweise eine Sicherungskopie unter dem Namen "ssl-std.conf".

  • Suchen Sie den Eintrag ServerAdmin you@example.com und ersetzen Sie die E-Mail-Adresse durch die E-Mail-Adresse, die Sie im Zertifikatsantrag angegeben haben.
  • Suchen Sie den Eintrag #ServerName www.example.com:443und ersetzen Sie den "full-qualified-domain-name" durch den Namen des Rechners, den Sie im "DN"-Attribut des Zertifikatantrags angegeben haben. Hier müssen Sie unbedingt den selben Namen verwenden, damit es später keine Warnhinweise durch die Browser der Benutzer gibt. Beispiel: 
        ServerName kruemel.rrz.uni-hamburg.de:443
    Bei :443 handelt es sich um die Standard-Portnummer für Web-Server, auf die mit den sichernden SSL/TLS-Protokollen zugegriffen werden kann. Browser wählen bei Angabe von URLs, die mit https:// beginnen, grundsätzlich diesen Port aus.
  • Suchen Sie den Eintrag SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crtund ersetzen Sie die Pfadangabe durch den vollständigen Pfad auf das von der CA ausgestellte Server-Zertifikat. Beispiel: 
        SSLCertificateFile /usr/local/apache2/conf/ssl.crt/kruemel.rrz.uni_hamburg.de.pem
    Das obige Beispiel geht davon aus, dass das von der CA (via akkreditiertem Vertreter Ihrer Organisation) zugestellte Zertifikat in das Verzeichnis ssl.crtkopiert wurde: 
        root@kruemel:/<1>local/apache2/conf# mkdir ssl.crt root@kruemel:/<1>local/apache2/conf# cp /from/somewhere/08154711.pem ssl.crt/kruemel.rrz.uni_hamburg.de.pem
  • Suchen Sie den Eintrag SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.keyund ersetzen Sie diesen Eintrag durch den vollständigen Pfad auf den privaten RSA-Schlüssel, der bei der Erstellung des PKCS#10 Antrags generiert wurde. Beispiel: 
        SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/kruemel.rrz.uni_hamburg.de.key.pem
    Das obige Beispiel geht davon aus, dass sie das Unterverzeichnis ssl.keyerstellt haben und den privaten RSA-Schlüssel dort hin kopiert haben: 
        root@kruemel:/<1>local/apache2/conf# mkdir ssl.key root@kruemel:/<1>local/apache2/conf# cp /from/somewhere/server-key.pem\ ssl.key/kruemel.rrz.uni_hamburg.de.key.pem
  • Falls Sie nicht bei jedem Start des Web-Servers das Passwort eingeben wollen, mit dem der private RSA-Schlüssel des Web-Server verschlüsselt ist, können Sie den privaten Schlüssel auch unverschlüsselt hinterlegen. In diesem Fall sollten Sie den Zugriff auf den Schlüssel so gut wie möglich einschränken. Beispiel: 
        root@kruemel:/<1>local/apache2/conf# pushd `pwd` /usr/local/apache2/conf /usr/local/apache2/conf root@kruemel:/<1>local/apache2/conf# cd /from/somewhere root@kruemel:/from/somewhere# ls server-key.pem root@kruemel:/from/somewhere# /usr/local/ssl/bin/openssl rsa\ ? -in server-key.pem \ ? -out /usr/local/apache2/conf/ssl.key/kruemel.rrz.uni_hamburg.de.key.pem Enter pass phrase for server-key.pem: writing RSA key root@kruemel:/from/somewhere# cd `popd` root@kruemel:/<1>local/apache2/conf# chmod 400 ssl.key/kruemel.rrz.uni_hamburg.de.key.pem
  • Suchen Sie nach der Zeile #SSLCertificateChainFile /usr/local/apache2/conf/ssl.crt/ca.crt und entfernen Sie das Kommentarsymbol ("#").
  • Laden Sie mit einem Browser die notwendigen CA-Zertifikate im "PEM"-Format durch Aufruf der URL CA-Chain herunter und speichern Sie diese als Datei ca.crt im Verzeichnis /usr/local/apache2/conf/ssl.crt/.
  • Suchen Sie die Zeile SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL und ersetzen Sie diese durch SSLCipherSuite !ADH!ANULL:!ENULL:!NULL:!IDEA:!DES:!RC2:!SSLv2:!EXP:RC4+RSA:TLSv1:SSLv3. Hierdurch werden unsichere Authentifikations- und Verschlüsselungsalgorithmen ausgeschlossen. Behilte man die Standardeinstellung bei, wären einige unsichere Kombinationen möglich und es wäre von den Einstellungen in den Browsern der Anwender abhängig, ob eine unsichere Algorithmenkombination im Zuge des SSL/TLS-Verbindungsaufbaus ausgehandelt wird. Beispiel für Algorithmen laut Standardeinstellung: 
        root@kruemel:/<1>local/apache2/conf# sh # /usr/local/ssl/bin/openssl ciphers -v 'ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL' DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-RC4-SHA SSLv3 Kx=DH Au=DSS Enc=RC4(128) Mac=SHA1 IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH Au=RSA Enc=DES(56) Mac=SHA1 EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH Au=DSS Enc=DES(56) Mac=SHA1 DES-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=DES(56) Mac=SHA1 DES-CBC3-MD5 SSLv2 Kx=RSA Au=RSA Enc=3DES(168) Mac=MD5 IDEA-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5 RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 RC4-64-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(64) Mac=MD5 DES-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=DES(56) Mac=MD5 EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512) Au=DSS Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA SSLv3 Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC2-CBC-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv3 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export EXP-RC2-CBC-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC2(40) Mac=MD5 export EXP-RC4-MD5 SSLv2 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export
    Hierbei sind insbesondere die Kombinationen mit "SSLv2"-Protokoll und geringer Schlüsselänge (<128 bit="" problematisch="" durch="" die="" obige="" einstellung="" ergibt="" sich="" eine="" sehr="" viel="" sicherere="" liste="" m="" glicher="" kombinationen:="" pre="" class="code"> # /usr/local/ssl/bin/openssl ciphers -v \ > '!ADH!ANULL:!ENULL:!NULL:!IDEA:!DES:!RC2:!SSLv2:!EXP:RC4+RSA:TLSv1:SSLv3' RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-RC4-SHA SSLv3 Kx=DH Au=DSS Enc=RC4(128) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA
  • Entfernen Sie vor den oben genannten Schlüsselwörtern eventuell vorhandene Kommentarsymbole ("#"), damit der Server die Angaben auch findet.

Test der Installation

Die oben dargestellten Einstellungen sorgen dafür, dass sie neben dem normalen Zugriff auf den Server mit HTTP-URLs nun auch einen sicheren Zugriff mit HTTPs-URLs anbieten können. Wenn die Benutzer die CA-Zertifikate (die gleichen, die Sie als ca.crt-Datei abgelegt haben) einmal in ihre Browser importiert haben, werden die Benutzer bei Zugriffen auf Ihre Server nicht mehr mit Meldungen verwirrt, dass die Authentizität der Server nicht gesichert sei.

Um zu prüfen, ob die obigen Einstellungen funktionieren, müssen Sie den Server mit der Option starten, das SSL/TLS-Protokoll zu aktivieren. Beispiel:

  root@kruemel:/<1>local/apache2/conf# ../bin/apachectl startssl root@kruemel:/<1>local/apache2/conf# ps -ef | grep httpd nobody 1962 1960 0 16:32:30 ? 0:00 /usr/local/apache2/bin/httpd -k start -DSSL nobody 1963 1960 0 16:32:30 ? 0:00 /usr/local/apache2/bin/httpd -k start -DSSL nobody 1965 1960 0 16:32:30 ? 0:00 /usr/local/apache2/bin/httpd -k start -DSSL nobody 1964 1960 0 16:32:30 ? 0:00 /usr/local/apache2/bin/httpd -k start -DSSL root 1960 1 1 16:32:29 ? 0:01 /usr/local/apache2/bin/httpd -k start -DSSL nobody 1961 1960 0 16:32:30 ? 0:00 /usr/local/apache2/bin/httpd -k start -DSSL

Die Option startssl schaltet die Unterstützung für das SSL/TLS-Protokoll beim Starten des Apache-Servers ein. Die Ausgabe des ps-Kommandos zeigt, dass entsprechende Server-Prozesse instanziiert wurden. Sollte dies nicht geschehen, löschen Sie die Log-Dateien und starten sie erneut. Anschließend sehen Sie in den Log-Dateien, was den erfolgreichen Start verhindert hat.

Test mit dem Browser

"Surfen" Sie Ihren neuen Server mit einem Browser an. Verwenden Sie jedoch nicht die normale HTTP-URL, sondern die entsprechende HTTPS-URL, also https://FQDN. Hierbei ist natürlich anstelle von FQDN der von Ihnen als "Common Name" im Zertifikatsantrag angegebene "full qualified domain name" anzugeben.

Wenn sich der Apache-Server dann mit seiner Startseite meldet, rufen Sie die Sicherheitsinformationen zu der Seite auf. Häufig müssen Sie dafür lediglich auf das kleine Schloß-Symbol im Browser "klicken" und es erscheint beispielsweise bei Firefox ein Fenster mit Angaben zur Authentizität der Web-Seite und zum Verschlüsselungsverfahren, dass für die "Download-Verbindung" verwendet wurde:

Weitere Details werden mit "View" aufgerufen. Die folgenden Abbildungen zeigen die im Zertifikat enthaltenen CA-Informationen ( hier zur UHH CA und der untergeordneten UHH Server-CA) und zum vom Server empfangenen Server-Zertifikat. Dort werden die Attribute, die Sie beim Zertifikatsantrag angeben mussten und weitere Attribute, die von der CA eingetragen werden, angezeigt.

Der "Detail"-Reiter und anschließendes Auswählen von "Subjekt" zeigt die Attribute des "Distinguished Names" des Server-Zertifikats.

Falls Sie oder Benutzer Ihres Dienstes allerdings die folgende Meldung (im Beispiel durch die deutsche Version des Firefox-Browsers angezeigt) oder eine vergleichbare Meldung bekommen, haben Sie wahrscheinlich vergessen, die CA-Zertifikate in Ihren Browser zu importieren.

Falls Sie sich die Details anzeigen lassen (hier: "Zertifikat untersuchen") sollten die gleichen Informationen wie in den vorigen Abbildungen angezeigt werden. Das wäre dann ein eindeutiger Hinweis darauf, dass Sie vergessen haben, die Zertifikate in Ihren Browser zu importieren. Sie können dies über die Infoseite der UHH-CA nachholen und dann diesen Test wiederholen.

Hinweis:Wenn Sie Ihren Web-Server wie oben dargestellt konfiguriert haben und insbesondere die Hinweise zur Verwendung der Konfigurationsoption SSLCertificateChainFile befolgt haben, reicht es aus, dass Sie (und Ihre Anwender) das Wurzelzertifikat der DFN-PKI importieren. Der Browser kann dann mit Hilfe der von Ihrem Server im Zuge des SSL/TLS-Verbindungsaufbaus an ihn gesendeten Zertifikate aus dem SSLCertificateChainFile auf die Authentizität Ihres Servers schließen. Es konnte ein sogenannter "Trusted Path" zwischen Ihrem Server und der DFN-PKI hergestellt werden, obwohl die dazwischenligenden Zertifikate der UHH CA und der UHH Server-CA nicht in den Browser importiert wurden.

Bei richtiger Konfiguration von Servern anderer Einrichtungen innerhalb der DFN-PKI aber außerhalb der UHH würden sich die Browser dann auch nicht mehr mit der obigen Meldung beschweren, da auch zu Ihnen bei Vorhandensein des Wurzelzertifikats der DFN-PKI eben dieser "Trusted Path" vom Browser abgeleitet werden kann.

Test des SSL/TLS-Protokolls

Falls Sie Probleme mit dem SSL/TLS-Verbindungsaufbau vermuten, beispielsweise weil der Browser anstelle der Startseite des Servers einen Verbindungsfehler anzeigt, können Sie versuchen, das Problem mit Hilfe von UNIX-Kommandos zu erforschen.

Prüfen Sie dazu erneut, ob auf dem Server-Rechner überhaupt Apache-Server-Prozesse laufen und sich keine Fehlermeldungen in den Log-Dateien befinden.

Falls alles richtig aussieht, können Sie einen SSL/TLS-Verbindungsaufbau von Hand simulieren und die dabei gesendeten und empfangenen Informationen, sowie eventuell auftretendende Fehler anzeigen lassen. Das folgende Beispiel zeigt einen geglückten Verbindungsaufbau:

cookie:~/pkihome/server-ca> openssl s_client -host kruemel.rrz.uni-hamburg.de -port 443
CONNECTED(00000003)
depth=3 /C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Classic - G01
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=DE/ST=Hamburg/L=Hamburg/O=Universitaet Hamburg/OU=Regionales \
Rechenzentrum/CN=kruemel.rrz.uni-hamburg.de
   i:/C=DE/ST=Hamburg/L=Hamburg/O=Universitaet Hamburg/OU=Regionales \
Rechenzentrum/CN=UHH Server-CA
 1 s:/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Classic - G01
   i:/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Classic - G01
 2 s:/C=DE/ST=Hamburg/L=Hamburg/O=Universitaet Hamburg/OU=Regionales \
Rechenzentrum/CN=UHH CA/E-MailAddress=uhh-ca@uni-hamburg.de
   i:/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Classic - G01
 3 s:/C=DE/ST=Hamburg/L=Hamburg/O=Universitaet Hamburg/OU=Regionales \
Rechenzentrum/CN=UHH Server-CA
   i:/C=DE/ST=Hamburg/L=Hamburg/O=Universitaet Hamburg/OU=Regionales \
Rechenzentrum/CN=UHH CA/E-MailAddress=uhh-ca@uni-hamburg.de
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFizCCBHOgAwIBAgIEB/2uSTANBgkqhkiG9w0BAQUFADCBizELMAkGA1UEBhMC
REUxEDAOBgNVBAgTB0hhbWJ1cmcxEDAOBgNVBAcTB0hhbWJ1cmcxHTAbBgNVBAoT
FFVuaXZlcnNpdGFldCBIYW1idXJnMSEwHwYDVQQLExhSZWdpb25hbGVzIFJlY2hl
bnplbnRydW0xFjAUBgNVBAMTDVVISCBTZXJ2ZXItQ0EwHhcNMDYwMTMwMTUyODU4
WhcNMDgwMTMwMTUyODU4WjCBmDELMAkGA1UEBhMCREUxEDAOBgNVBAgTB0hhbWJ1
cmcxEDAOBgNVBAcTB0hhbWJ1cmcxHTAbBgNVBAoTFFVuaXZlcnNpdGFldCBIYW1i
dXJnMSEwHwYDVQQLExhSZWdpb25hbGVzIFJlY2hlbnplbnRydW0xIzAhBgNVBAMT
GmtydWVtZWwucnJ6LnVuaS1oYW1idXJnLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAtMwR1HaDcsT/x2TYsdiAR4o9qY718QweTb2i9xxMPcn87ImZ
XbPIa8VLJ0RfsgfQJTDgQjsayrle2d0Zkr2Ep81uLS+M4kjlS8GlpPB0kBwrccFU
EsV9n/ggKx3ltINSngvYX7Dd2TFGsqN8BfWp5OfFVtnBbEM0dpOWavtcO1DfMi1R
GmLWBmy165MdKcZEe8hq49vc9Os2DMUtP6LJwZDx7YAO/Ma8NRT70JRdGs+qa1gE
D1xrRB09tVbooZErTVQMarsbJmItvAT/f1yECG1Y174vIKjd6Bl2bNd7y+Su7IdP
wgZ8j2+C3tpsAH7mWPLl2EGUJh4ZkJ+o+fNupwIDAQABo4IB5jCCAeIwCQYDVR0T
BAIwADALBgNVHQ8EBAMCBPAwEwYDVR0lBAwwCgYIKwYBBQUHAwEwHQYDVR0OBBYE
FIz+7+AUvC5ex7Om/5J7BVS49iAaMB8GA1UdIwQYMBaAFAY95ghLw7zJmJ0c+cJ3
wcTSq5Z6MCYGA1UdEQQfMB2BG25ldGdyb3VwQHJyei51bmktaGFtYnVyZy5kZTCB
lwYDVR0fBIGPMIGMMESgQqBAhj5odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1o
YW1idXJnLXNlcnZlci1jYS9wdWIvY3JsL2NhY3JsLmNybDBEoEKgQIY+aHR0cDov
L2NkcDIucGNhLmRmbi5kZS91bmktaGFtYnVyZy1zZXJ2ZXItY2EvcHViL2NybC9j
YWNybC5jcmwwgbAGCCsGAQUFBwEBBIGjMIGgME4GCCsGAQUFBzAChkJodHRwOi8v
Y2RwMS5wY2EuZGZuLmRlL3VuaS1oYW1idXJnLXNlcnZlci1jYS9wdWIvY2FjZXJ0
L2NhY2VydC5jcnQwTgYIKwYBBQUHMAKGQmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUv
dW5pLWhhbWJ1cmctc2VydmVyLWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq
hkiG9w0BAQUFAAOCAQEAmMvW6BQRpQkkWDrgjbHKDS/ghFIzNFmb/MpcM5L6a1AL
XnMyuMtfeezlNI7hnBVztj2vI/WZ9hkLXwSgOrnXNECjYgwrhgmawmFgj81vq/V2
2qavnT8MILhrXCvNjB3RyhUU+JFa5jHJ6hMO0mYqv2R/mKBAOSNwX/nFKBpim+hC
U26iKydi6z72+6N3TIb7ksLqE4U38u0W/sqJ8vHQcFX+ck7Hpvit6D5tddyW7QhH
oMrVnsiaHjHgeLGImCjGVDn8PEKGgEjMdNW++Il7Ia/iBHjoCpLwy2sXHmKZyu54
nb9Yq0T+3cb6Q2m7ML8wyKpH+osEu9T+CVGLwiPZDg==
-----END CERTIFICATE-----
subject=/C=DE/ST=Hamburg/L=Hamburg/O=Universitaet Hamburg/OU=Regionales \
Rechenzentrum/CN=kruemel.rrz.uni-hamburg.de
issuer=/C=DE/ST=Hamburg/L=Hamburg/O=Universitaet Hamburg/OU=Regionales \
Rechenzentrum/CN=UHH Server-CA
---
No client certificate CA names sent
---
SSL handshake has read 6121 bytes and written 346 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DHE-RSA-AES256-SHA
    Session-ID: 73356FA03D23408D77FA66110C260C443B90B71B7CE31866214F0D7DBD8A90C0
    Session-ID-ctx:
    Master-Key: 7FFE4ED9424FF21F157DED349C23A313A2C10FC251C49390\
                FE3FA659C4809C3C6F8221D6CC5976AE5B18624E3C808861
    Key-Arg   : None
    Start Time: 1138705467
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

Der Aufruf des OpenSSL-Kommandos mit der Option s_client transkribiert die SSL/TLS-Verbindung, so dass die wichtigsten Inhalte für die Fehlerfindung lesbar sind. Hier wurde das Kommando mit den Parametern -host FQDN mit der Angabe des Server-Rechners und -port 443 mit der Angabe des Standardports für SSL/TLS-Verbindungen zur Absicherung von HTTP aufgerufen.

Die wichtigsten Informationen stehen am Anfang der Ausgabe des Kommandos:

  • CONNECTED: Die Verbindung wurde hergestellt.
  • Certificate chain: Es wurden vier Zertifikate ("depth=3") empfangen. Beginnend mit Server-Zertifikat des Rechners (als "Subject", kurz s: taucht hier der CN "kruemel.rrz.uni-hamburg.de" auf) folgt die Zertifikatskette vom Wurzelzertifikat hinunter zur Server-CA der UHH. Man erkennt nun auch, dass der Browser durch Import des Wurzelzertifikats den "Trusted Path" anhand der Zertifikatskette errechnen kann, indem von dem "Issuer (i:)" (Austeller) das jeweils untergeordnete Zertifikat ("Subject" c:) signiert wurde und schließlich die UHH Server-CA als Issuer den Server (Subject) signiert hat.
  • No client certificate CA names sent: Es handelt sich um eine einseitige Authentifikation, bei der sich lediglich der Server beim Client authentifiziert.
  • New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA: Es wurde eine neue Verbindung aufgebaut, bei der für den AES-Sitzungsschlüssel mit einer Länge von 256 Bit (AES256) ein Diffie-Hellman-Schlüsselaustausch (DHE) mit einer digitalen "Rivest-Shamir-Adleman-Signatur (RSA) verwendet wurde. Die Integritätskontrolle der über diese Verbindung übertragenen Daten wird mit Hilfe des "Secure-Hash"-Algorithmus (SHA) durchgeführt.
  • Server public key is 2048 bit: Der für die Digitale Signatur im Zuge des Diffie-Hellman-Schlüsselaustausches verwendete RSA-Schlüssel des Servers ist 2048 Bit lang.
  • Protocol : TLSv1: Es wurde das TLS Protokoll in der Version 1 verwendet.

An dieser Stelle können Sie nun von Hand eine HTTP-Anfrage an den Server stellen, die über die verschlüsselte Verbindung zum Server gesendet wird. Im folgenden Beispiel wird die deutsche Index-Seite des Servers abgerufen. Der Server sendet die Seite als HTML-Text zurück:

---
GET /index.html.de HTTP/1.0

HTTP/1.1 200 OK
Date: Tue, 31 Jan 2006 13:18:24 GMT
Server: Apache/2.0.54 (Unix) mod_ssl/2.0.54 OpenSSL/0.9.7g
Last-Modified: Sun, 21 Nov 2004 14:35:21 GMT
ETag: "12e72-89a-3e965a64a7c40"
Accept-Ranges: bytes
Content-Length: 2202
Connection: close
Content-Type: text/html
Content-Language: de

[...]

closed
cookie:~/pkihome/server-ca>

Nur noch sicher

Zum Schluß dieser Installationshilfe noch ein Tip. Da Sie nun über einen Server verfügen, der Ihren Benutzern einen sicheren Zugriff auf die Web-Inhalte bietet, könnten Sie sich überlegen, den unsicheren Zugriff mittels HTTP-URLs abzuschalten. Dies würden Sie über die httpd.conf einstellen.

Besser ist es jedoch, unsichere Zugriffe zuzulassen, zu erkennen und den Browsern dann mitzuteilen, lieber den gesicherten Weg zu gehen.

Wenn Sie das konfigurieren möchten, wechseln Sie erneut in das Verzeichnis /usr/local/apache2/conf und fügen in der httpd.conf-Datei hinter der Zeile DocumentRoot "/usr/local/apache2/htdocs" folgende Anweisungen ein:

# mod_rewrite aktivieren und alles auf https-gesicherte Seiten umlenken.
RewriteEngine On
RewriteRule ^/(.*)$     https://FQDN/$1 [R=301]

Anstelle von FQDN tragen Sie hier wiederum Ihren Rechnernamen ein, so wie er im CN-Attribut des Zertifikatantrags eingegeben wurde. Starten Sie anschließend den Server neu (s.o.). Ab sofort wird der Server bei allen HTTP-Anfragen anstelle der angeforderten Seite die Meldung zurücksenden, dass sich die Inhalte der angeforderten Seite über eine entsprechende HTTPs-URL abrufen lassen. Die Browser der Anwender laden diese URL i.d.R. ohne weitere Rückfragen.

Bemerkenswert ist hieran, dass während der ersten ungesicherten Anfrage keine Inhalte über die ungesicherte Verbindung gesendet werden. Es wird lediglich der Hinweis gesendet, wo der Browser die gesuchten Informationen findet, nämlich die HTTPs-URL. Anschließend stellt der Browser völlig transparent für die Benutzer eine sichere Verbindung her und fragt darüber die angeforderte Seite erneut ab. Diese wird dann auch ausgeliefert und im Browser-Fenster erscheinen die typischen Merkmale für gesicherte Kommunikation (beispielsweise gelb hinterlegte URL bei Firefox oder auch das geschlossene Schloß-Symbol).