Das mod_ssl-Paket Version 1 wurde im April 1998 von Ralf S. Engelschall durch Portierung der Apache-SSL 1.17 Source-Patches für Apache 1.2.6 bis Apache 1.3b6 von Ben Laurie erstellt. Aufgrund von Konflikten mit Ben Laurie's Entwicklungszyklus wurde es für Apache 1.3.0 insgesamt neu zusammengestellt, indem die alte mod_ssl-Version 1.x mit der neueren Apache-SSL-Version 1.18 vermischt wurde. Von diesem Punkt an führte mod_ssl mit der Version 2 ein eigenes Leben. Die erste veröffentlichte Version war am 10. August 1998 mod_ssl 2.0.0. Im August 1999 war die mod_ssl-Version 2.4.0 die aktuelle Version.

Nach einem Jahr mit intensiver Entwicklung mit über 1000 Arbeitsstunden und über 40 Neufassungen erreichte mod_ssl den aktuellen Stand. Das Ergebnis ist eine bereits sehr saubere Quellcodebasis, die sehr umfangreiche Funktionalität implementiert. Der Umfang hat sich um den Faktor 4 auf derzeit insgesamt über 10.000 Zeilen ANSI C-Code vergrößert (70% Code und 30% Dokumentation). Vom ursprünglichen Apache-SSL-Code sind nur zirka 5% übrig geblieben.

Nach dem die US-Bestimmungen für den Export von kryptografischer Software aufgehoben wurden, wurde mod_ssl 2001 in den Code der Apache-Version 2 integriert.

Ja, mod_ssl ist Jahr-2000-kompatibel.

Zum einen weil mod_ssl intern Jahreszahlen niemals mit zwei Zahlen speichert. Es wird immer der numerische Datentyp von ANSI C und POSIX (time_t) verwendet, der bei fast allen Unix-Betriebssystemen zur Zeit den Typ signed long hat (normalerweise 32 Bit) und die seit dem 1. Januar 1970 00:00 Uhr UTC vergangene Zeit angibt. Dieser Vorzeichenwert läuft frühsten im Januar 2038 und nicht im Jahr 2000 über. Zum anderen erfolgen die Datums- und Zeitdarstellungen (zum Beispiel die Variable %{TIME_YEAR}) mit vollständiger Angabe der Jahreszahl und nicht mit einer zweistellligen Abkürzung.

Außerdem ist nach einer Jahr-2000-Erklärung der Apache Group der Apache-Webserver ebenfalls Jahr-2000-kompatibel. Ob allerdings OpenSSL oder das zugrundeliegende Betriebssystem (Unix oder Win32) Jahr-2000-kompatibel sind, ist eine andere Frage, die hier nicht beantwortet werden kann.

Zuerst soll erklärt werden, was das Wassenaar-Abkommen über Exportkontrollen für konventionelle Waffen und "dual use" Güter und Technologien ist: Im Jahr 1995 wurde eine internationale Organisation eingerichtet, die den Handel mit konventionellen Waffen und zivilen Gütern sowie Technologien, die auch waffentauglich sind, kontrollieren soll. Sie ersetzt die frühere CoCom. Das Abkommen wurde von 33 Ländern unterzeichnet: Argentinien, Australien, Belgien, Bulgarien, Kanada, Dänemark, Deutschland, Finnland, Frankreich, Griechenland, Großbritannien, Irland, Italien, Japan, Korea, Luxemburg, Niederlande, Neuseeland, Norwegen, Polen, Portugal, Rumänien, Russische Föderation, Österreich, Slowakische Republik, Spanien, Schweden, Schweiz, Tschechien, Türkei, Ukraine, Ungarn, USA. Weitere Informationen finden Sie unter http://www.wassenaar.org/.

Kurz zusammengefasst soll das Wassenaar-Abkommen den Aufbau militärischer Fähigkeiten verhindern, die regionale und internationale Sicherheit und Stabilität bedrohen. Das Wassenaar-Abkommen kontrolliert den Export von Verschlüsselungssoftware als Gut mit sowohl militärischen als auch zivilen Anwendungsmöglichkeiten. Das Wassenaar-Abkommen schließt aber Software für den Massenbedarf sowie Free Software aus.

Die aktuelle Wassenaar List of Dual Use Goods und Technologies and Munitions sagt unter GENERAL SOFTWARE NOTE (GSN) The Lists do not control "software" which is either: 1. [...] 2. "in the public domain". und unter DEFINITIONS OF TERMS USED IN THESE LISTS findet sich die Definition: In the public domain": This means "technology" or "software" which has been made available without restrictions upon its further dissemination. N.B. Copyright restrictions do not remove "technology" or "software" from being "in the public domain".

Sowohl mod_ssl und als auch OpenSSL fallen also im Sinne des Wassenaar-Abkommens und der Liste der "dual use" Güter und Technologien in Bereich public domain.

mod_ssl und OpenSSL sind also nicht vom Wassenaar-Abkommen betroffen.

Ein Core Dump kann selbstverständlich unterschiedliche Ursachen haben, angefangen von fehlerhaften Modulen von Fremdherstellern über fehlerhafte Bibliotheken bis hin zu einer fehlerhaften mod_ssl-Version. Häufig wird die oben beschriebene Situation aber durch ältere oder beschädigte DBM-Bibliotheken anderer Hersteller ausgelöst. Um das Problem zu beheben, muss mod_ssl entweder mit der integrierten SDBM-Bibliothek aufgebaut werden (geben Sie --enable-rule=SSL_SDBM in der APACI-Befehlszeile ein) oder von SSLSessionCache dbm: zur neueren SSLSessionCache shm:-Variante gewechselt werden (nachdem Sie den Apache mit MM neu aufgebaut haben).

Wenn Sie Einträge wie mod_ssl: Child could not open SSLMutex lockfile /opt/apache/logs/ssl_mutex.18332 (System error follows) [...] System: Permission denied (errno: 13) erhalten, dann werden diese in der Regel durch zu stark eingeschränkte Berechtigungen für übergeordnete Verzeichnisse ausgelöst. Sorgen Sie dafür, dass für alle übergeordneten Verzeichnisse (in diesem Fall /opt, /opt/apache und /opt/apache/logs) das x-Bit mindestens für die UID gesetzt ist, unter welcher die Apache-Kindprozesse laufen (siehe User-Direktive).

Das zusätzliche MByte wird durch den globalen Shared Memory-Pool verursacht, den der Apache für alle Module allokiert und der aus verschiedenen Gründen nicht von mod_ssl benutzt wird. Der tatsächlich allokierte Shared Memory-Bereich ist immer um 1 MByte größer als mit der SSLSessionCache-Direktive angegeben wird. Die Angabe für 'top' ist etwas verwirrend, denn obwohl angezeigt wird, das jeder Prozess wächst, entspricht das nicht der Realität. Der zusätzliche Speicher wird von allen Prozessen genutzt, d.h. die 1,5 MByte werden nur einmal pro Apache-Instanz allokiert und nicht einmal pro Apache-Serverprozess.

Kryptografie-Software benötigt für die korrekte Funktion eine Quelle mit zufälligen Daten. Viele Open Source-Betriebssysteme stellen für diesen Zweck ein "Randomness Device" zur Verfügung (normalerweise unter der Bezeichnung /dev/random). Bei anderen Systemen müssen die Anwendungen den OpenSSL Pseudo Random Number-Generator (PRNG) manuell mit den entsprechenden Daten aktivieren, bevor Schlüssel erzeugt oder eine Verschlüsselung durchgeführt wird. Ab Version 0.9.5 melden die OpenSSL-Funktionen, die den PRNG benötigen, einen Fehler, wenn dieser nicht mit mindestens 128 Bits aktiviert wurde. mod_ssl muss also genügend Entropie für den PRNG bereitstellen, was mit den SSLRandomSeed-Direktiven geschieht.

Ja, HTTP und HTTPS benutzen unterschiedliche Server-Ports, so dass es keine Konflikte zwischen beiden gibt. Es können entweder zwei Serverinstanzen ausgeführt werden (eine wird an Port 80, die andere an Port 443 gebunden) oder Sie wählen die elegante virtuelle Variante, bei der zwei virtuelle Server vom Apache für Port 80 und HTTP und einer für Port 443 und HTTPS eingeteilt werden.

HTTPS kann über jeden Port laufen, der Standard gibt aber Port 443 an, den jeder HTTPS-kompatibele Browser berücksichtigt. Wenn Sie in der URL den Port mit angeben (https://secure.server.dom:666/), dann überwacht der Browser auch diesen Port (hier Port 666):

Während ein einfacher Test des HTTP-Protokolls wie folgt durchgeführt werden kann

ist das für HTTPS nicht so einfach, weil das SSL-Protokoll zwischen TCP und HTTP liegt. Aber mit Hilfe des OpenSSL-Befehls s_client kann auch HTTPS überprüft werden:

Vor der eigentlichen HTTP-Antwort erhalten Sie detaillierte Informationen über das SSL-Handshake. Für einen universelleren Befehlszeilen-Client, der sowohl HTTP als auch HTTPS versteht, die Methoden GET und POST ausführen und einen Proxy benutzen kann, Bytebereiche unterstützt usw. sollten Sie das Hilfsprogramm cURL benutzen. Hiermit können Sie direkt testen, ob Ihr Apache an den Ports 80 und 443 richtig funktioniert:

Weil Sie über HTTP eine Verbindung zum HTTPS-Port hergestellt haben, beispielsweise mit einer URL in der Form http:// an Stelle von https://. Das passiert auch anders herum, wenn Sie über HTTPS eine Verbindung zu einem HTTP-Port herstellen wollen und https:// für einen Server verwenden, der SSL (über diesen Port) nicht unterstützt. Stellen Sie sicher, dass Sie eine Verbindung zu einem virtuellen Server herstellen, der SSL unterstützt (wahrscheinlich die IP-Adresse des Hostnamens und nicht der lokale Host (127.0.0.1).

Das kann mehrere Gründe haben. Einer der weitverbreiteten Fehler ist, dass der Apache nur mit apachectl start (oder httpd) anstatt mit apachectl startssl (oder httpd -DSSL) gestartet wird. Vielleicht stimmt auch die Konfiguration nicht. Überprüfen Sie, ob die Listen-Direktiven mit den VirtualHost-Direktiven übereinstimmen. War auch das nicht die Ursache, dann beginnen Sie noch einmal mit der Standardkonfiguration für mod_ssl.

Sie müssen SSLOptions +StdEnvVars für den Kontext der CGI/SSI-Anfragen setzen.

Normalerweise müssen vollständig qualifizierte Hyperlinks benutzt werden, weil das URL-Schema gewechselt werden muss. Mit Hilfe einiger URL-Manipulationen über mod_rewrite können Sie aber den gleichen Effekt erreichen und die relativen URLs weiter verwenden:

Diese Manipulationsregeln erlauben die Verwendung von Hyperlinks in der Form <a href="document.html:SSL">

Die private RSA-Schlüsseldatei ist eine digitale Datei mit der Sie empfangene Nachrichten entschlüsseln können. Sie besitzt eine öffentliche Komponente, die Sie verteilen (über Ihre Zertifikatdatei). Das ermöglicht anderen, die an Sie gerichteten Nachrichten zu verschlüsseln. Ein Certifikate Signing Request (CSR) ist eine digitale Datei, die Ihren öffentlichen Schlüssel und Ihren Namen enthält. Die CSR wird an eine Certifying Authority (CA) gesendet, damit sie in ein richtiges Zertifikat umgewandelt wird. Ein Zertifikat enthält Ihren öffentlichen RSA-Schlüssel, Ihren Namen, den Namen der CA und ist vom CA digital signiert. Browser, die die CA kennen, können die Signatur dieses Zertifikats überprüfen und Ihren öffentlichen RSA-Schlüssel entgegennehmen. Sie können dann verschlüsselte Nachrichten versenden, die nur mit Ihrem Schlüssel entschlüsselt werden können. Im Kapitel Einführung finden Sie eine allgemeine Beschreibung des SSL-Protokolls.

Im Allgemeinen unterscheidet sich der Start des Apache-Servers mit integriertem mod_ssl-Modul nicht vom einfachen Apache-Start, allerdings mit dem Unterschied, dass beim Vorhandensein einer Passphrase für die private SSL-Schlüsseldatei diese Passphrase in einem Dialogfeld eingegeben werden muss.

Die manuelle Eingabe der Passphrase beim Serverstart kann problematisch sein, wenn der Server beispielsweise vom System-Bootskript gestartet wird. Als Alternative können Sie den im Abschnitt "Wie kann ich die Eingabe der Passphrase beim Apache-Start umgehen" beschriebenen Schritten folgen.

Führen Sie folgende Schritte durch:

1. Überprüfen Sie, ob OpenSSL installiert und im PATH angegeben ist. Einige Befehle funktionieren auch, wenn das Programm openssl einfach innerhalb des OpenSSL-Zweiges mit ./apps/openssl ausgeführt wird.
   
   
2. Erstellen Sie einen privaten RSA-Schlüssel für Ihren Apache-Server (er wird Triple-DES verschlüsselt und hat das PEM-Format):
   
   $ openssl genrsa -des3 -out server.key 1024
   
   Sichern Sie diese server.key-Datei und merken Sie sich die Passphrase, die Sie in einem geschützten Bereich eingegeben haben. Die Details zu diesem privaten RSA-Schlüssel können Sie sich mit folgendem Befehl anzeigen lassen:
   
   $ openssl rsa -noout -text -in server.key
   
   Sie können auch eine entschlüsselte PEM-Version erzeugen (wovon allerdings abzuraten ist):
   
   $ openssl rsa -in server.key -out server.key.unsecure
   
   
3. Erzeugen Sie eine Certifikate Signing Request (CSR) mit dem privaten RSA-Schlüssel des Servers (die Ausgabe hat das PEM-Format):
   
   $ openssl req -new -key server.key -out server.csr
   
   Achten Sie darauf, dass Sie den FQDN (Fully Qualified Domain Name = Vollqualifizierter Domänenname) des Servers eingeben, wenn OpenSSL nach dem "CommonName" fragt (wenn Sie eine CSR für eine Website erzeugen, auf die später über https://www.foo.dom/ zugegriffen wird, geben Sie www.foo.dom ein). Die Details dieser CSR können Sie sich mit folgendem Befehl anzeigen lassen:
   
   $ openssl req -noout -text -in server.csr
   
   
4. Diese Certifikate Signing Request (CSR) müssen Sie jetzt an eine Certifying Authority (CA) zum Signieren senden. Das Ergebnis ist ein echtes Zertifikat, das für den Apache benutzt werden kann. Sie haben zwei Möglichkeiten: Zum einen können Sie die CSR von einer kommerziellen CA wie Verisign oder Thawte signieren lassen. In diesem Fall müssen Sie die CSR normalerweise mit einem Webformular versenden, für das Signieren bezahlen und auf das signierte Zertifikat warten, das Sie dann in einer server.crt-Datei speichern können. Weitere Informationen zu kommerziellen CAs finden Sie unter folgenden Adressen:
   
   
   1. Verisign
      http://digitalid.verisign.com/server/apacheNotice.htm
   2. Thawte Consulting
      http://www.thawte.com/certs/server/request.html
   3. CertiSign Certificadora Digital Ltda.
      http://www.certisign.com.br
   4. IKS GmbH
      http://www.iks-jena.de/produkte/ca/
   5. Uptime Commerce Ltd.
      http://www.uptimecommerce.com
   6. BelSign NV/SA
      http://www.belsign.be
   Zum anderen können Sie Ihre eigene CA verwenden und müssen die CSR dann selbst von dieser CA signieren lassen. Die Antwort auf die nächste häufig gestellte Frage beschreibt, wie eine CSR von der eigenen CA signiert wird. Die Details zum Zertifikat fragen Sie mit folgendem Befehl ab:
   
   $ openssl x509 -noout -text -in server.crt
   
5. Sie besitzen jetzt zwei Dateien: server.key und server.crt. In der httpd.conf-Datei des Apache-Servers werden diese Dateien wie folgt benutzt:

          SSLCertificateFile    /path/to/this/server.crt
          SSLCertificateKeyFile /path/to/this/server.key
          

   Die server.csr-Datei wird nicht mehr benötigt.

Die kurze Antwort lautet: Benutzen Sie das OpenSSL-Skript CA.sh oder CA.pl. Oder ausführlich:

1. Erzeugen Sie einen privaten RSA-Schlüssel für Ihre CA (mit Triple-DES-Verschlüsselung und im PEM-Format):
   
   $ openssl genrsa -des3 -out ca.key 1024
   
   Sichern Sie diese ca.key-Datei und merken Sie sich die geschützt eingegebene Passphrase. Die Details zu diesem privaten RSA-Schlüssel werden mit folgendem Befehl angezeigt:
   
   $ openssl rsa -noout -text -in ca.key
   
   Mit der folgenden Anweisung können Sie auch eine entschlüsselte PEM-Version dieses Schlüssels erzeugen, wovon allerdings abzuraten ist:
   
   $ openssl rsa -in ca.key -out ca.key.unsecure
   
   
2. Erzeugen Sie mit dem RSA-Schlüssel der CA ein selbst signiertes CA-Zertifikat (X509-Struktur, Ausgabe im PEM-Format):
   
   $ openssl req -new -x509 -days 365 -key ca.key -out ca.crt
   
   Die Details zu diesem Zertifikat werden mit folgendem Befehl angezeigt:
   
   $ openssl x509 -noout -text -in ca.crt
   
   
3. Bereiten Sie ein Skript für die Signierung vor, das erforderlich ist, weil der Befehl openssl ca einige seltsame Anforderungen stellt und die standardmäßige OpenSSL-Konfiguration keine einfache, direkte Benutzung des Befehls openssl ca zulässt. Die mod_ssl-Distribution enthält im Unterverzeichnis pkg.contrib/ ein entsprechendes Skript mit der Bezeichnung sign.sh. Benutzen Sie dieses Skript für die Signierung.
4. Sie können jetzt mit dieser CA CSRs signieren, um richtige SSL-Zertifikate für die Verwendung durch Apache-Webserver ausstellen zu können (vorausgesetzt, Sie haben eine server.csr zur Hand):
   
   $ ./sign.sh server.csr
   
   Die Server-CSR wird signiert und eine server.crt-Datei erzeugt.
   

Sie müssen Sie mit der alten Passphrase lesen und mit Angabe einer neuen Passphrase neu schreiben. Dies kann mit folgenden Befehlen geschehen:

$ openssl rsa -des3 -in server.key -out server.key.new
$ mv server.key.new server.key

Sie werden zweimal nach einer PEM-Passphrase gefragt. Beim erstenmal geben Sie die alte Passphrase ein und beim zweiten Mal die neue.

Die Ursache, warum der Dialog bei jedem Start und Neustart geöffnet wird, ist die Tatsache, dass der private RSA-Schlüssel in der Datei server.key aus Sicherheitsgründen verschlüsselt gespeichert ist. Die Passphrase wird benötigt, um diese Datei lesen und analysieren zu können. Wenn Sie sicher sind, dass Ihr Server genug gesichert ist, führen Sie zwei Schritte durch:

1. Heben Sie die Verschlüsselung des privaten RSA-Schlüssels auf (und bewahren Sie die Originaldatei auf):
   
   $ cp server.key server.key.org
$ openssl rsa -in server.key.org -out server.key
   
   
2. Stellen Sie sicher, dass die server.key-Datei für root lesbar ist:
   
   $ chmod 400 server.key
   
   

Die Datei server.key enthält jetzt eine unverschlüsselte Kopie des Schlüssels. Stößt der Server jetzt auf die Datei, fragt er nicht mehr nach einer Passphrase. Fällt allerdings dieser Schlüssel einem anderen in die Hände, dann kann er sich als Ihre Person ausgeben. Sorgen Sie deshalb dafür, dass die Berechtigungen für diese Datei so zugewiesen werden, dass nur root oder der Webserver sie lesen können (vorzugsweise sollte der Webserver als root gestartet werden und der Schlüssel nur für diesen Benutzer lesbar sein).

Alternativ können Sie auch die Anweisung SSLPassPhraseDialog exec:/Pfad/zum/Programm verwenden. Allerdings ist diese Variante genauso sicher bzw. unsicher.

Der private Schlüssel enthält eine Reihe von Zahlen. Wählen Sie zwei Zahlen aus dem "öffentlichen Schlüssel", die anderen sind Bestandteil des "privaten Schlüssels". Die "öffentlichen Schlüsselbits sind ebenfalls in Ihr Zertifikat eingebettet (Sie erhalten Sie mit der CSR). Um zu überprüfen, ob der öffentliche Schlüssel im Zertifikat mit dem öffentlichen Teil des privaten Schlüssels übereinstimmt, müssen Sie die Zahlen des Zertifikats und des Schlüssels miteinander vergleichen. Mit den folgenden Befehlen können Sie sich Zertifikat und Schlüssel anzeigen lassen:

$ openssl x509 -noout -text -in server.crt
$ openssl rsa -noout -text -in server.key

Die Bestandteile für den Modulus und den öffentlichen Exponenten des Schlüssels und des Zertifikats müssen übereinstimmen. Da der öffentliche Exponent normalerweise den Wert 65537 hat und der Vergleich mit einem langen Modulus umständlich ist, können Sie auch folgendes tun:

$ openssl x509 -noout -modulus -in server.crt | openssl md5
$ openssl rsa -noout -modulus -in server.key | openssl md5

Vergleichen Sie diese wirklich kurzen Zahlen miteinander. Aller Wahrscheinlichkeit nach unterscheiden Sie sich, wenn die Schlüssel sich unterscheiden. Mit der folgenden Anweisung kann berechnet werden, zu welchem Schlüssel oder Zertifikat eine bestimmte CSR gehört:

$ openssl req -noout -modulus -in server.csr | openssl md5

Wenn Fehler wie OpenSSL: error:14094412: SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate in der SSL-Protokolldatei auftauchen, bedeutet das normalerweise, dass der Browser nicht mit dem Serverzertifikat oder dem privaten Schlüssel umgehen konnte, die vielleicht einen RSA-Schlüssel enthalten, der nicht 1.024 Bit groß ist. Einer dieser Browser ist zum Beispiel der Netscape Navigator 3.x.

Die privaten Schlüsselgrößen für SSL müssen für die Kompatibilität zu bestimmten Webbrowsern entweder 512 oder bei 1.024 Bit groß sein. Eine Schlüsselgröße von 1.024 Bit ist zu empfehlen, weil größere Schlüssel inkompatibel zu einigen Browser-Versionen des Netscape Navigators und des Microsoft Internet Explorers sowie zu anderen Browsern sind, die das BSAFE-Kryptografie-Toolkit von RSA verwenden.

Die im mit SSLCACertificatePath konfigurierten Pfad befindlichen CA-Zertifikate werden von SSLeay über Hashwerte gefunden. Diese Hashwerte werden mit den Befehl openssl x509 -noout -hash erzeugt. Der Algorithmus für die Hashwertberechnung bei Zertifikaten hat sich mit der SSLeay-Version 0.9 geändert. Die alten Hashwerte müssen daher entfernt und nach dem Upgrade neu erzeugt werden. Benutzen Sie hierfür das Makefile mod_ssl aus diesem Verzeichnis.

Das Standardformat für SSLeay-/OpenSSL-Zertifikate ist das PEM-Format, bei dem es sich um ein Base64-verschlüsseltes DER-Format mit Kopf- und Fußzeilen handelt. Für einige Anwendungen (z.B. für den Microsoft Internet Explorer) benötigen Sie das Zertifikat im einfachen DER-Format. Sie können die PEM-Datei certificate.pem in die entsprechende DER-Datei certificate.der mit folgendem Befehl umwandeln:

$ openssl x509 -in certificate.pem -out certificate.der -outform DER

Das liegt daran, dass Verisign keine speziellen Instruktionen für Apache und mod_ssl angibt, sondern sich auf Stronghold von C2Net bezieht (eine kommerzielle Apache-Variante mit SSL-Unterstützung). Sie müssen lediglich das Zertifikat in einer Datei sichern und den Namen dieser Datei der SSLCertificateFile-Direktive übergeben. Beachten Sie, dass auch die Schlüsseldatei angegeben werden muss (siehe SSLCertificateKeyFile-Direktive). Einen besseren Überblick zu CAs und SSL-Zertifikaten finden Sie in den mod_ssl-Anweisungen von Thawte.

Ja, mod_ssl unterstützt seit der Version2.1 das SGC-Programm. Spezielle Konfigurationen sind hierfür nicht erforderlich, Sie müssen lediglich eine globale ID als Serverzertifikat verwenden. Die heraufgesetzten Clients werden dann zur Laufzeit automatisch von mod_ssl behandelt. Einzelheiten hierzu finden Sie in der Datei README.GlobalID der mod_ssl-Distribution.

Verisign verwendet ein zwischen dem Root-CA-Zertifikat (in den Browsern installiert) und dem Serverzertifikat (im Server installiert) liegendes CA-Zertifikat. Dieses zusätzliche CA-Zertifikat sollten Sie von Verisign erhalten haben. Falls nicht, reklamieren Sie das. Richten Sie dieses Zertifikat mit der SSLCertificateChainFile-Direktive auf dem Server ein. Damit wird sichergestellt, dass dieses dazwischen liegende CA-Zertifikat an den Browser gesendet und das Loch in der Zertifikatkette gestopft wird.

Das kann mehrere Gründe haben, meist handelt es sich aber um Probleme mit dem SSL-Session-Cache, der mit der SSLSessionCache-Direktive definiert wird. Der DBM Session-Cache ist meist die Ursache des Problems, versuchen Sie es mit dem SHM Session-Cache oder ohne Cache.

Weil SSL eine starke kryptografische Verschlüsselung benutzt und dafür viele Berechnungen durchführen muss. Ferner werden bei einer Anfrage über HTTPS auch Bilder verschlüsselt übertragen. Liegt viel HTTPS-Verkehr an, steigt daher die Serverbelastung.

Normalerweise liegt das an der Verwendung eines /dev/random-Geräts für SSLRandomSeed-Direktive, die bei read(2)-Aufrufen blockiert wird, wenn nicht genügend Entropie zur Verfügung steht. Mehr hierzu finden Sie im Abschnitt über SSLRandomSeed.

Normalerweise werden alle SSL-Algorithmen unterstützt, die von der verwendeten OpenSSL-Version unterstützt werden (in Abhängigkeit davon, wie OpenSSL eingerichtet wurde). Üblicherweise gehören mindestens die folgenden Algorithmen dazu:

1. RC4 mit MD5
2. RC4 mit MD5 (auf 40-Bit-Schlüssel beschränkte Exportversion)
3. RC2 mit MD5
4. RC2 mit MD5 (auf 40-Bit-Schlüssel beschränkte Exportversion)
5. IDEA mit MD5
6. DES mit MD5
7. Triple-DES mit MD5

Mit folgendem Befehl können Sie die aktuell unterstützten Algorithmen ermitteln:

Um anonyme Diffie-Hellman-Algorithmen (ADH) verwenden zu können, reicht es nicht aus, einfach nur ADH in die SSLCipherSuite-Anweisung einzufügen. OpenSSL muss außerdem mit -DSSL_ALLOW_ADH eingerichtet werden. Da OpenSSL aus Sicherheitsgründen standardmäßig keine ADH-Algorithmen zulässt, sollten Sie sich über die Nebenwirkungen informieren, bevor Sie diese Algorithmen aktivieren.

Entweder enthält die SSLCipherSuite-Direktive einen Fehler (vergleichen Sie sie mit dem vorkonfigurierten Beispiel aus der Datei httpd.conf-dist) oder Sie haben die DSA/DH-Algorithmen anstatt RSA gewählt, als Sie Ihren privaten Schlüssel erzeugt haben und die entsprechenden Warnungen ignoriert oder übersehen. Wenn Sie DSA/DH gewählt haben, versteht der Server keine RSA-basierten SSL-Algorithmen mehr (zumindest solange nicht, bis Sie auch ein zusätzliches RSA-basiertes Zertifikat-/Schlüsselpaar definiert haben). Derzeitige Browser wie NS oder IE verstehen nur RSA-Algorithmen. Das Ergebnis ist die Fehlermeldung no shared algorithmn. Beseitigen Sie das Problem, indem Sie Ihr Serverzertifikat/Schlüsselpaar erneut erstellen und diesmal den RSA-Algorithmus wählen.

Das hat technische Ursachen und ist mit der Frage vergleichbar, ob das Ei oder die Henne zuerst da war. Die SSL-Protokollschicht steht über der HTTP-Protokollschicht und kapselt HTTP ein. Wird eine SSL-Verbindung (HTTPS) eingerichtet, muss das Apache-Modul mod_ssl die SSL-Protokollparameter mit dem Client aushandeln. Hierfür muss mod_ssl die Konfiguration des virtuellen Servers zu Rate ziehen (beispielsweise muss nach den Algorithmen, dem Serverzertifikat usw. gesehen ). Um den richtigen virtuellen Server auswählen zu können, muss der Apache das HTTP-Header-Feld Host kennen. Dafür muss der HTTP-Anfrage-Header gelesen werden. Das kann nicht geschehen, bevor der SSL-Handshake abgeschlossen ist. Diese Information wird aber bereits in der Phase des SSL-Handshake benötigt. Bingo!

Das auf Namen basierende virtuelle Hosting ist eine sehr beliebte Methode zur Identifizierung unterschiedlicher virtueller Hosts. Sie erlaubt die Verwendung der gleichen IP-Adresse und der gleichen Portnummer für viele unterschiedliche Sites. Beim Wechsel zu SSL scheint es nur natürlich, anzunehmen, dass die gleiche Methode für viele unterschiedliche virtuelle SSL-Hosts auf dem gleichen Server verwendet werden kann.

Wenn erkannt wird, dass das nicht möglich ist, kommt es dann meist zu einem bösen Erwachen.

Die Ursache liegt darin, dass das SSL-Protokoll eine eigene Schicht ist, die das HTTP-Protokoll einkapselt. Daher ist die SSL-Session eine separate Transaktion, die noch vor der HTTP-Session stattfindet. Der Server erhält nur eine SSL-Anfrage unter der IP-Adresse X und am Port Y (normalerweise 443). Da die SSL-Anfrage kein Host:-Feld enthält, kann der Server nicht entscheiden, welchen virtuellen SSL-Host er verwenden soll. Normalerweise benutzt er den ersten, der mit dem Port und der IP-Adresse übereinstimmt.

Selbstverständlich kann das auf Namen basierende virtuelle Hosting zur Identifikation vieler virtueller Hosts ohne SSL verwendet werden (zum Beispiel alle über Port 80) und dann sind mehr als ein virtueller SSL-Host möglich (über Port 443). In diesem Fall müssen Sie aber sicherstellen, dass die Portnummer, die nicht für SSL benutzt wird, mit der Direktive NameVirtualHost angegeben wird:

Weitere Möglichkeiten sind:

Die Verwendung separater IP-Adressen für unterschiedliche SSL-Hosts. Die Verwendung unterschiedlicher Port-Nummern für unterschiedliche SSL-Hosts.

Nein, Benutzername und Passwort werden bereits verschlüsselt übertragen. Das Icon der Netscape-Browser ist nicht richtig mit der SSL/TLS-Schicht synchronisiert (es wechselt in den gesperrten Zustand, wenn der erste Teil der Webseitendaten übertragen wurde, was nicht ganz korrekt ist) und verwirrt auf diese Weise die Anwender. Die Basic-Authentifizierung ist Bestandteil der HTTP-Schicht und diese Schicht liegt über der SSL/TLS-Schicht von HTTPS. Bevor eine HTTP-Datenkommunikation in HTTPS stattfindet, hat die SSL/TLS-Schicht bereits die Handshake-Phase abgeschlossen und zur verschlüsselten Kommunikation gewechselt. Lassen Sie sich deshalb nicht von dem Icon irritieren.

Zum einen weist die SSL-Implementierung einiger MSIE-Versionen subtile Fehler hinsichtlich der HTTP-Keep-Alives und der SSL-Benachrichtigungen beim Schließen von Socket-Verbindungen auf. Ferner erweist sich die Interaktion zwischen SSL- und HTTP/1.1-Eigenschaften bei einigen MSIE-Versionen ebenfalls als problematisch. Diese Probleme müssen dadurch umgangen werden, dass der Apache OpenSSL-Server veranlasst wird, kein HTTP/1.1 und keine Keep-Alive-Verbindungen zu verwenden oder die SSL-Nachrichten beim Schließen der Socket-Verbindung an MSIE-Clients zu senden. Dies kann mit der folgenden Direktive im virtual host-Abschnitt geschehen:

Darüber hinaus ist bekannt, dass einige MSIE-Versionen Probleme mit bestimmten Algorithmen haben. Da die Algorithmen bereits in der SSL-Handshake-Phase benutzt werden, lassen sich diese Fehler nicht nur für diese bestimmten MSIE-Clients beheben( z.B. mit einer MSIE-spezifischen SetEnvIf-Anweisung). Stattdessen müssen etwas einschneidendere Korrekturen an den globalen Parametern vorgenommen werden. Bevor Sie dies tun, sollten Sie aber wirklich sicher sein, dass die Clients tatsächlich Probleme haben. Ist dies nicht der Fall, nehmen Sie Abstand davon, denn die Maßnahmen betreffen alle(!) und nicht nur Ihre MSIE-Clients.

Das nächste Problem ist eine fehlerhafte SSLv3-Implementierung der 56-Bit-Exportversionen bei den MSIE 5.x-Browsern, die schlecht mit OpenSSL-Versionen nach der Version 0.9.4 zusammenarbeitet. Sie können dies entweder akzeptieren und die Clients veranlassen, ihre Browser auszutauschen, oder Sie gehen zähneknirschend zurück zur OpenSSL-Version 0.9.4. Sie können auch die folgende Lösung wählen, wenn Sie die schrecklichen Auswirkungen für alle anderen Browser in Kauf nehmen möchten:

Damit wird das SSLv3-Protokoll vollständig deaktiviert und die fehlerhaften Browser bereiten keine Probleme mehr. Aber normalerweise ist das kein akzeptabler Ausweg. Vernünftiger wäre eine etwas gezieltere Behandlung des Problems, bei der nur die Algorithmen deaktiviert werden, die die Probleme verursachen:

Bei dieser Lösung funktionieren auch die fehlerhaften MSIE-Versionen, denn nur die neueren 56-Bit TLS-Algorithmen werden deaktiviert.

Ein weiteres Problem mit MSIE 5.x-Clients ist ihre Weigerung, eine Verbindung zu URLs der Form https://12.34.56.78/ (anstelle des Hostnamens werden IP-Adressen verwendet) herzustellen, wenn Server Gated Cryptography (SGC) verwendet wird. Das kann nur durch Verwendung des vollständig qualifizierten Domänennamens (FQDN) der Website in Hyperlinks verhindert werden, weil MSIE 5.x die SGC-Negotiation fehlerhaft ausführt.

Schließlich gibt es noch MSIE-Versionen, die scheinbar verlangen, dass eine SSL-Session wiederverwendet werden kann (ein Verhalten, das allen Standards widerspricht). Verbindungen mit solchen MSIE-Versionen funktionieren nur, wenn ein SSL-Session-Cache verwendet wird. Als Workaround kann der Session-Cache aktiviert werden (siehe SSLSessionCache-Direktive).

Normalerweise ist ein mit dem gleichen DN erzeugtes Serverzertifikat die Ursache, wobei der Browser angewiesen wurde, weiterhin das alte Serverzertifikat zu akzeptieren. Wird der Eintrag für das alte Zertifikat aus dem Browser entfernt, funktioniert normalerweise wieder alles wie erwartet. Die SSL-Implementierung von Netscape ist korrekt, so dass I/O-Fehler beim Netscape Navigator meist durch die Konfiguration der Zertifikate verursacht werden.

Folgende Informationsquellen sollten Sie bei Problemen zuerst zu Rate ziehen:

Antworten in der FAQ-Liste des Benutzerhandbuchs (diese Liste).

http://httpd.apache.org/docs-2.1/ssl/ssl_faq.html
Schauen Sie zuerst unter den häufig gestellten Fragen nach (dieser Text), wie leicht ist Ihr Problem so verbreitet, dass bereits Lösungen vorliegen.

Nachrichten der modssl-Users Support Mailing List http://www.modssl.org/support/

Suchen Sie als nächstes in einem der Archive der modssl-Users Mailing List nach einer Antwort auf Ihre Fragen. Vielleicht standen andere Benutzer schon einmal vor dem gleichen Problem.

Die folgende Liste führt alle Möglichkeiten für Unterstützung bei Problemen mit mod_ssl in der Reihenfolge auf, in der Sie genutzt werden sollten.

1. Schreiben Sie einen Bericht für die Fehlerdatenbank.
   http://www.modssl.org/support/bugdb/
   Über diesen Weg sollte ein Fehlerbericht geleitet werden, damit er in die Fehlerdatenbank aufgenommen wird und nicht verloren geht. Schicken Sie den Bericht außerdem an die modssl-Users Mailing List (andere erfahren dann von dem aktuellen Problem und können aus den Antworten lernen).
2. Schicken Sie einen Problembericht an die modssl-Users Support Mailing List
   modssl-users@modssl.org
   Dies ist der zweite Weg, über den ein Problembericht weitergeleitet werden kann. Hierfür müssen Sie sich zuerst anmelden, anschließend können Sie Ihr Problem mit dem Autor und der ganzen mod_ssl-Benutzergemeinde diskutieren.

Folgende Informationen sollten mindestens in dem Bericht enthalten sein:

Apache- und OpenSSL-Versionsinformationen

Die Apache-Version kann mit der Anweisung httpd -v ermittelt werden'. Die OpenSSL-Version wird mit openssl version abgefragt. Wenn Lynx installiert ist, können alternativ mit dem Befehl lynx -mime_header http://localhost/ | grep Server alle Informationen in einem Schritt abgefragt werden.

Details zum Aufbau und zur Installation des Apache mit mod_ssl und OpenSSL

Hierfür können Sie eine Protokolldatei der Terminal-Session beilegen, aus dem die Konfigurations- und Installationsschritte ersichtlich sind. Alternativ sollten Sie mindestens die verwendete configure-Befehlszeile angeben.

Im Fall eines Core Dumps fügen Sie bitte einen Backtrace hinzu.

Sollte der Apache tatsächlich einen Core Dump produzieren, fügen Sie bitte einen Backtrace hinzu (wie Sie diesen erhalten, wird mit der nächsten Frage beantwortet). Ohne diese Information ist die Ursache für den Core Dump nicht nachvollziehbar. Der Backtrace ist also unverzichtbar.

Eine detaillierte Problembeschreibung

Dieser Hinweis ist durchaus ernst gemeint. Aus vielen Problemberichten geht häufig das eigentliche Problem nicht hervor. Aus eigenem Interesse sollten Sie soviel Detailangaben wie möglich machen, dabei aber selbstverständlich mit den wesentlichsten beginnen.

Im Allgemeinen nicht, wenn nicht wenigstens weitere Informationen dazu geliefert werden, an welcher Codeposition der Apache mit dem Speicherauszug begonnen hat. Normalerweise wird immer ein Backtrace (siehe nächste Frage) benötigt, um helfen zu können. Ohne diese Informationen ist es meist unmöglich, das Problem zu erkennen und bei dessen Beseitigung zu helfen.

Führen Sie folgende Schritte durch:

1. Sorgen Sie dafür, dass mindestens im Apache Debug-Symbols zur Verfügung stehen. Bei Betriebssystemen, die GCC/GDB verwenden, müssen Sie hierfür den Apache mit mod_ssl mit dem Befehl OPTIM="-g -ggdb3" einrichten. Bei anderen Betriebssystemen ist mindestens OPTIM="-g" erforderlich.
2. Starten Sie den Server und versuchen Sie, den Core Dump zu produzieren. Hierfür müssen Sie möglicherweise eine Direktive wie CoreDumpDirectory /tmp verwenden, damit die Core Dump-Datei geschrieben werden kann. Sie sollten dann eine Datei /tmp/core oder /tmp/httpd.core erhalten. Ist das nicht der Fall, versuchen Sie den Server unter der UID != 0 (root) auszuführen, weil die meisten Serverkerne aus Sicherheitsgründen (es können sich noch geschützte Informationen im Speicher befinden) keinem Prozess einen Core Dump gestatten, nachdem setuid() abgeschlossen ist (es sei denn, er führt exec() aus). Zusätzlich kann /path/to/httpd -X ausgeführt werden, um den Apache manuell am Aufspalten des Prozesses zu hindern.
3. Analysieren Sie den Core Dump. Führen Sie hierfür gdb /path/to/httpd/tmp/httpd.core oder einen ähnlichen Befehl aus. Beim GDB muss nur der bt-Befehl eingegeben werden und schon erhalten Sie den Backtrace. Bei anderen Debuggern müssen Sie im Handbuch nachschlagen. Schicken Sie den Backtrace an den Author.