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 - der Apache-Server-Software, die Sie hier finden,
- 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
- 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".
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 eMail-Adresse durch die eMail-Adresse, die Sie im
Zertifikatsantrag angegeben haben.
-
Suchen Sie den Eintrag
#ServerName www.example.com:443
und 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.crt und 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.crt kopiert 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.key und 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.key erstellt
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:
# /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 SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
-
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/emailAddress=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/emailAddress=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).
Autor: UHH-CA, Stand: 10.09.2007 17:21 Uhr |
