German Translatiom mod_ssl

Jobst Giesecke 30 Dec 2003 12:10:50 -0000

Title: Umgebungsvariablen

mod_ssl Stellt die Verschlüsselung der Protokolle Secure Sockets Layer (SSL) und Transport Layer Security (TLS) zur Verfügung. Erweiterung mod_ssl.c ssl_module

Dieses Modul unterstützt SSL v2/v3 und TLS v1 für den Apache HTTP-Server. Es ist ein Beitrag von Ralf S. Engeschall, der auf dessen mod_ssl-Projekt basiert und ursprünglich von Ben Laurie entwickelt wurde.

Die Verschlüsselung durch dieses Modul basiert auf OpenSSL.

Weitere Einzelheiten, Diskussionen und Beispielse finden Sie in der SSL-Dokumentation.

Dieses Modul stellt eine Reihe von SSL-Informationen in Form zusätzlicher Umgebungsvariablen für den SSI- und CGI-Namespace zur Verfügung. Die folgende Tabelle führt die erzeugten Variablen auf. Aus Gründen der Abwärtskompatibilität können die Informationen auch unter verschiedenen Namen bereitgestellt werden. Im Kapitel Kompatibilität finden Sie weitere Einzelheiten zu diesen Variablen.

Variablenname:	Wertetyp:	Beschreibung:
`HTTPS`	Flag	HTTPS wird verwendet.
`SSL_PROTOCOL`	Zeichenfolge	Die SSL-Protokollversion (SSLv2, SSLv3, TLSv1)
`SSL_SESSION_ID`	Zeichenfolge	Die hexadezimal kodierte SSL-Session-ID
`SSL_CIPHER`	Zeichenfolge	Verschlüsselungsalgorithmus
`SSL_CIPHER_EXPORT`	Zeichenfolge	`true` wenn es sich um einen Export-Algorithmus handelt
`SSL_CIPHER_USEKEYSIZE`	Zahl	Anzahl der Bits des Verschlüsselungsalgorithmus (tatsächliche benutzte Bits)
`SSL_CIPHER_ALGKEYSIZE`	Zahl	Anzahl der Bits des Verschlüsselungsalgorithmus (mögliche Anzahl)
`SSL_VERSION_INTERFACE`	Zeichenfolge	Die `mod_ssl`-Programmversion
`SSL_VERSION_LIBRARY`	Zeichenfolge	Die OpenSSL.Programmversion
`SSL_CLIENT_M_VERSION`	Zeichenfolge	Die Version des Client-Zertifikats
`SSL_CLIENT_M_SERIAL`	Zeichenfolge	Die Seriennummer des Client-Zertifikats
`SSL_CLIENT_S_DN`	Zeichenfolge	Subjekt-DN im Client-Zertifikat
`SSL_CLIENT_S_DN_`x509	Zeichenfolge	Komponente der Subjekt-DN des Client
`SSL_CLIENT_I_DN`	Zeichenfolge	Aussteller-DN des Client-Zertifikats
`SSL_CLIENT_I_DN_`x509	Zeichenfolge	Komponente der Aussteller-DN des Client
`SSL_CLIENT_V_START`	Zeichenfolge	Gültigkeit des Client-Zertifikats (Beginn)
`SSL_CLIENT_V_END`	Zeichenfolge	Gültigkeit des Client-Zertifikats (Ablauf)
`SSL_CLIENT_A_SIG`	Zeichenfolge	Algorithmus für die Signatur des Client-Zertifikats
`SSL_CLIENT_A_KEY`	Zeichenfolge	Algorithmus für den öffentlichen Schlüssel des Client-Zertifikats
`SSL_CLIENT_CERT`	Zeichenfolge	PEM-kodiertes Client-Zertifikat
`SSL_CLIENT_CERT_CHAIN`n	Zeichenfolge	PEM-kodierte Zertifikate in der Client-Zertifikatkette
`SSL_CLIENT_VERIFY`	Zeichenfolge	`NONE`, `SUCCESS`, `GENEROUS` oder `FAILED:`reason
`SSL_SERVER_M_VERSION`	Zeichenfolge	Die Version des Serverzertifikats
`SSL_SERVER_M_SERIAL`	Zeichenfolge	Die Seriennummer des Serverzertifikats
`SSL_SERVER_S_DN`	Zeichenfolge	Subjekt-DN im Serverzertifikat
`SSL_SERVER_S_DN_`x509	Zeichenfolge	Komponente der Subjekt-DN des Servers
`SSL_SERVER_I_DN`	Zeichenfolge	Aussteller-DN des Serverzertifikats
`SSL_SERVER_I_DN_`x509	Zeichenfolge	Komponente der Aussteller-DN des Servers
`SSL_SERVER_V_START`	Zeichenfolge	Gültigkeit des Serverzertifikats (Beginn)
`SSL_SERVER_V_END`	Zeichenfolge	Gültigkeit des Serverzertifikats (Ablauf)
`SSL_SERVER_A_SIG`	Zeichenfolge	Algorithmus für die Signatur des Serverzertifikats
`SSL_SERVER_A_KEY`	Zeichenfolge	Algorithmus für den öffentlichen Schlüssel des Serverzertifikats
`SSL_SERVER_CERT`	Zeichenfolge	PEM-kodiertes Serverzertifikat
[ x509 ist eine Komponente eines X.509-DN: `C,ST,L,O,OU,CN,T,I,G,S,D,UID,Email` ]

Angepasste Protokollformate

Wenn mod_ssl in den Apache eingebunden oder unter DSO geladen wurde, stehen zusätzliche Funktionen für die angepassten Protokollformate von mod_log_config zur Verfügung. Als erstes sei das Erweiterungsformat %{VarName}x erwähnt, mit dem jede von einem Modul bereitgestellte Variable (insbesondere die von mod_ssl aus der oben aufgeführten Tabelle) expandiert werden kann.

Für die Abwärtskompatibilität steht außerdem die spezielle Kryptografiefunktion %{name}c zur Verfügung. Informationen zu dieser Funktion finden Sie im Kapitel Kompatibilität.

Beispiel:

CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

SSLPassPhraseDialog Typ des Passphrasendialogs für verschlüsselte private Schlüssel SSLPassPhraseDialog Typ SSLPassPhraseDialog builtin server config

Beim Apache-Start werden die verschiedenen Zertifikat- und Schlüsseldateien des virtuellen SSL-Servers gelesen (siehe SSLCertificateFile und SSLCertificateKeyFile). Da die Dateien mit den privaten Schlüsseln aus Sicherheitsgründen meist verschlüsselt werden , muss mod_ssl vom Administrator eine Passphrase abfragen, um diese Dateien entschlüsseln zu können. Diese Abfrage auf zwei Arten geschehen, die nach dem Typ konfiguriert werden können:

builtin
Dies entspricht der Standardeinstellung, bei der beim Serverstart ein interaktives Dialogfenster geöffnet wird, bevor der Terminal getrennt wird. Der Administrator muss dann die Passphrase für jede verschlüsselte Schlüsseldatei eingeben. Da sehr viele virtuelle SSL-Hosts konfiguriert sein können, kann der Dialog mit folgendem Wiederverwendungsschema minimiert werden: Ist eine Datei mit privaten Schlüsseln verschlüsselt, werden alle bekannten Passphrasen ausprobiert (zu Beginn sind selbstverständlich keine vorhanden). Wird eine der bekannten Passphrasen anerkannt, wird für diese Schlüsseldatei kein Abfragedialog geöffnet. Wird keine anerkannt, wird eine Passphrase abgefragt und für die spätere Wiederverwendung gespeichert.

Dieses Schema bietet mod_ssl ein hohes Maß an Flexibilität (weil für n verschlüsselte private Schlüsseldateien n unterschiedliche Passphrasen verwendet werden können, die dann allerdings auch alle eingegeben werden müssen) bei gleichzeitiger Reduzierung der erforderlichen Eingaben (wird nur eine einzige Passphrase für alle n Schlüsseldateien benutzt, dann wird diese Passphrase nur einmal abgefragt).
exec:/Pfad/zum/Programm
Beim Serverstart wird für jede verschlüsselte private Schlüsseldatei ein externes Programm aufgerufen. Es wird mit zwei Argumenten aufgerufen, die angeben, für welchen Server und Algorithmus die entsprechende Passphrase an stdout gegeben werden soll. Das erste Argument hat die Form Servername:Portnummer, das zweite lautet entweder RSA oder DSA. Der Hintergrund ist, dass dieses externe Programm zuerst Sicherheitsüberprüfungen durchführt, um Attacken auf den Server abzuwehren. Erst nach der erfolgreichen Durchführung der Überprüfung wird die Passphrase zur Verfügung gestellt.

Sowohl die Überprüfung als auch die Art, wie die Passphrase ermittelt wird, können so komplex wie gewünscht sein. mod_ssl definiert lediglich die Schnittstelle: ein ausführbares Programm, das die Passphrase über stdout bereitstellt. Nicht mehr und nicht weniger. Für die Realisierung sind der Phantasie keine Grenzen gesetzt und es bleibt dem Administrator überlassen, welchen Weg er für die lokalen Sicherheitsanforderungen einschlägt.

Auch hier wird der oben erwähnte Algorithmus für die Wiederverwendung benutzt, das externe Programm wird also nur einmal für eine bestimmte Passphrase aufgerufen.

Beispiel:

SSLPassPhraseDialog exec:/usr/local/apache/sbin/pp-Filter SSLMutex Semaphore für den internen gegenseitigen Ausschluss von Operationen SSLMutex Typ SSLMutex none server config

Konfiguriert die Semaphore der SSL-Engine (auch Sperre genannt) die für den gegenseitigen Ausschluss von Operationen, die synchronisiert zwischen den Pre-Fork-Serverprozessen erfolgen müssen. Diese Direktive kann nur im Kontext des globalen Servers benutzt werden, weil nur ein globaler Mutex sinnvoll ist. Ihr Design orientiert sich an der AcceptMutex-Direktive.

Die folgenden Mutextypen stehen zur Verfügung:

none | no
Dies entspricht der Voreinstellung, nach der kein Mutex verwendet wird. Sie birgt ein gewisses Risiko in sich. Da aber zur Zeit der Mutex hauptsächlich für die Synchronisierung des Schreibzugriffs auf den SSL-Session-Cache benutzt wird, kommt man auch ohne ihn aus, wenn gelegentliche Session-Cache-Probleme in Kauf genommen werden. Daher ist es nicht ratsam, diese Voreinstellung beizubehalten. Es sollte vielmehr ein realer Mutex eingerichtet werden.
posixsem
Dies ist eine elegante Mutexvariante, bei der falls möglich eine Posix-Semaphore verwendet wird. Sie kann nur gewählt werden, wenn sie vom Betriebssystem und APR unterstützt wird.
sysvsem
Bei dieser nicht ganz so eleganten Mutexvariante wird möglichst eine SystemV IPC-Semaphore verwendet. SysV-Semaphoren können "geleert" werden, wenn ein Prozess abstürzt, bevor die Semaphore entfernt wird. Sie kann nur gewählt werden, wenn sie vom Betriebssystem und APR unterstützt wird.
sem
Diese Direktive weist das SSL-Modul an, die "geeignetste" Semaphorenimplementierung auszuwählen (in der Reihenfolge Posix oder SystemV IPC). Sie kann nur gewählt werden, wenn das Betriebssystem und APR mindestens eine von ihnen unterstützen.
pthread
Diese Direktive weist das SSL-Modul an, Posix-Thread-Mutexe zu verwenden. Sie kann nur benutzt werden, wenn das Betriebssystem und APR sie unterstützen.
fcntl:/Pfad/zum/Mutex
Dies ist eine protierbare Mutexvariante, bei der eine Sperrdatei und die fcntl()-Funktion als Mutex dienen. Für /Pfad/zum/Mutex muss immer ein lokales Dateisystem und niemals eine Datei auf einem einbindbaren NFS- oder AFS-Dateisystem benutzt werden. Sier steht nur zur Verfügung, wenn sie vom Betriebssystem und APR unterstützt wird. Hinweis: Intern wird die Prozess-ID (PID) des übergeordneten Apache-Prozesses automatisch an /Pfad/zum/Mutex angehängt, um Eindeutigkeit zu erreichen, so dass keine Konflikte entstehen können. Diese Art von Mutex steht unter Win32 nicht zur Verfügung. Für Windows muss der Semaphorenmutex benutzt werden.
flock:/Pfad/zum/Mutex
Diese Variante ist mit der fcntl:/Pfad/zum/Mutex-Methode vergleichbar, verwendet aber die flock()-Funktion für Dateisperren. Sie kann nur benutzt werden, wenn das Betriebssystem und APR sie unterstützen.
file:/Pfad/zum/Mutex
Diese Direktive weist das SSL-Modul an, die "geeignetste" Semaphorenimplementierung auszuwählen (in der Reihenfolge fcntl oder flock).Sie kann nur gewählt werden, wenn das Betriebssystem und APR mindestens eine von ihnen unterstützen.
default | yes
Diese Direktive weist das SSL-Modul an, die Standardimplementierung für Dateisperren zu wählen, die vom Betriebssystem und APR festgelegt wird.

Beispiel SSLMutex file:/usr/local/apache/logs/ssl_mutex SSLRandomSeed Auswahl des Pseudo Random Number-Generators (PRNG) für die Zufallszahlen SSLRandomSeed Kontext Quelle [Byte] server config

Konfiguriert eine oder mehrere Quellen für die von OpenSSL benötigten Zufallszahlen beim Start (der Kontext = startup) und/oder unmittelbar bevor eine neue SSL-Verbindung eingerichtet wird (Kontext = connect). Diese Direktive kann nur im globalen Serverkontext verwendet werden, da der PRNG ein globales Programm ist.

Folgende Varianten stehen zur Verfügung:

builtin
Diese Quelle steht immer zur Verfügung. Sie benötigt für die Ausführung nur ein Minimum an CPU-Zeit und ist daher problemlos einzusetzen. Die erzeugte Pseudo-Zufallszahl basiert auf der aktuellen Zeit, der Prozess-ID und einem zufällig ausgewählten 1 kByte großen Auszug aus der Apache-Scoreboard-Struktur (falls verfügbar). Da es sich nicht um starke Zufallszahlen handelt und beim Start die Entropie niedrig ist (die Scoreboard-Struktur steht noch nicht zur Verfügung), sollte zumindest für den Start eine andere Quelle gewählt werden.
file:/Pfad/zur/Quelle
Bei dieser Variante wird eine Datei (/Pfad/zur/Quelle) als Quelle für den PRNG gewählt. Wird das Argument Byte angegeben, bilden die ersten Bytes der Datei in der angegebenen Anzahl die Entropie (Byte wird als erstes Argument an die Quelle übergeben). Wird das Argument Byte nicht angegeben, bildet die gesamte Datei die Grundlage für die Entropie (in diesem Fall wird 0 als erstes Argument an die Quelle übergeben). Diese Variante sollte mit einem vorhandenen Random-Device aus dem System (zum Beispiel mit /dev/random und/oder /dev/urandom) für den Start gewählt werden.

Allerdings ist Vorsicht geboten, denn normalerweise liefert /dev/random nur soviel Entropiedaten, wie tatsächlich vorhanden sind. Werden 512 Byte angefordert und es stehen nur 100 Byte zur Verfügung, dann kann sich das unterschiedlich auswirken. Bei einigen Betriebssystemen werden nur die 100 verfügbaren Bytes geliefert, während bei anderen das Lesen solange blockiert wird, bis genügend Bytes zur Verfügung stehen (was sehr lange dauern kann). Hier empfiehlt sich der Umstieg auf /dev/urandom, weil es nie blockiert wird und die angeforderten Daten im entsprechenden Umfang liefert (deren Qualität allerdings nicht immer zufriedenstellend ist).

Bei einigen Betriebssystem wie zum Biespiel FreeBSD kann sogar gesteuert werden, wie die Entropie erzeugt wird, d.h. welche System-Interrupts benutzt werden. Mehr hierzu finden Sie in der Dokumentation des entsprechenden Betriebssystems unter rndcontrol(8). Besitzt das Betriebssystem ein solches Random-Device nicht, kann alternativ der EGD (Entropy Gathering Daemon) und dessen Client-Programm mit der exec:/Pfad/zum/Programm/-Variante oder egd:/Pfad/zu/egd-socket (siehe unten) benutzt werden.
exec:/Pfad/zum/Programm
Bei dieser Variante wird ein ausführbares externes Programm (/Pfad/zum/Programm) als Quelle für den PRNG benutzt. Wird das Argument Byte angegeben, wird nur die Anzahl der angegebenen Bytes aus stdout für die Entropie verwendet. Wird das Argument nicht angegeben, bilden alle für stdout produzierten Daten die Entropie. Diese Variante sollte nur für den Start gewählt werden, wenn mit Hilfe externer Programme eine sehr starke Zufallszahl benötigt wird (wie beispielsweise oben mit dem truerand-Programm aus der mod_ssl -Distribution, die auf der truerand-Bibliothek von AT&T basiert). In Verbindung mit dem connection-Kontext wird der Server dadurch allerdings deutlich langsamer, daher sollten externe Programme in diesem Zusammenhang möglichst nicht eingesetzt werden.
egd:/Pfad/zu/egd-socket (nur für Unix)
Bei dieser Variante wird das Domain Socket des externen Entropy Gathering Daemon (EGD) (siehe http://www.lothar.com/tech /crypto/) für den PRNG verwendet. Sie bietet sich an, wenn das Betriebssystem kein Random Device zur Verfügung stellt.

Beispiel SSLRandomSeed startup builtin
SSLRandomSeed startup file:/dev/random
SSLRandomSeed startup file:/dev/urandom 1024
SSLRandomSeed startup exec:/usr/local/bin/truerand 16
SSLRandomSeed connect builtin
SSLRandomSeed connect file:/dev/random
SSLRandomSeed connect file:/dev/urandom 1024
SSLSessionCache Typ des globalen und prozessübergreifenden SSL Session-Cache SSLSessionCache Typ SSLSessionCache none server config

Legt den Typ des globalen und prozessübergreifenden SSL Session-Cache fest. Dieser Cache ist optional. Er beschleunigt die parallele Prozessverarbeitung. Bei Anfragen nach dem gleichen Serverprozess (über HTTP-Keep-Alive) speichert OpenSSL die SSL-Session-Informationen lokal. Da die neueren Clients eingebettete Bilder und andere Daten über parallele Anfragen anfordern (normalerweise bis zu vier parallele Anfragen), werden diese Anfragen von unterschiedlichen Pre-Fork-Serverprozessen bedient. Ein prozessübergreifender Cache kann in dieser Situation den unnötigen Austausch kompletter Session-Handshakes vermeiden.

Zur Zeit werden zwei Speichertypen unterstützt:

none
Dies entspricht der Standardeinstellung, die den globalen und prozessübergreifenden Session-Cache deaktiviert. Dadurch wird zwar nicht die Funktionalität wohl aber die Gewindigkeit beeinträchtigt.
dbm:/Pfad/zu/datafile
Bei dieser Einstellung wird der OpenSSL-Cache der Serverprozesse mit einer DBM-Hash-Datei synchronisiert. Durch die etwas reduzierte Anzahl der I/O-Operationen wird die Bearbeitung der Client-Anfragen spürbar beschleunigt, so dass dieser Speichertyp zu empfehlen ist.
shm:/Pfad/zu/Datendatei[(Größe)]
Bei dieser Einstellung werden die lokalen OpenSSL-Cache-Operationen der Serverprozesse mit einer hochleistungsfähigen Hash-Tabelle (die Größe entspricht ungefähr dem mit Größe angegebenen Wert) in einem Shared Memory-Segment im RAM synchronisiert (eingerichtet über /Pfad/zu/Datendatei). Dieser Speichertyp steht nicht für alle Betriebssysteme zur Verfügung.

Beispiele SSLSessionCache dbm:/usr/local/apache/logs/ssl_gcache_data
SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000) SSLSessionCacheTimeout Wie lange (in Sekunden) eine Session maximal im Session-Cache gespeichert wird. SSLSessionCacheTimeout Sekunden SSLSessionCacheTimeout 300 server config virtual host

Diese Direktive legt den maximalen Zeitraum in Sekunden fest, über den Informationen im globalen und prozessübergreifenden SSL Session-Cache und im internen OpenSSL-Cache aufbewahrt werden. Für Testzwecke kann ein Wert von 15 Sekunden gesetzt werden, für den alltäglichen Einsatz sollte er deutlich höher liegen.

Beispiel SSLSessionCacheTimeout 600 SSLEngine Aktiviert das SSL/TLS-Protokoll. SSLEngine on|off SSLEngine off server config virtual host

Diese Direktive aktiviert das SSL/TLS-Protokoll. Sie wird normalerweise im VirtualHost-Abschnitt gesetzt, um das SSL/TLS-Protokoll für einen bestimmten virtuellen Host zu aktivieren. Standardmäßig ist das SSL/TLS-Protokoll sowohl für den Hauptserver als auch für alle virtuellen Hosts deaktiviert.

Beispiel <VirtualHost _default_:443>
SSLEngine on
...
</VirtualHost> SSLProtocol Aktiviert ein bestimmtes SSL-Protokoll. SSLProtocol [+|-]Protokoll ... SSLProtocol all server config virtual host Options

Mit dieser Direktive kann eines der von OpenSSL unterstützten Protokolle für die Serverumgebung von mod_ssl ausgewählt werden. Die Clients können dann nur über dieses Protokoll eine Verbindung herstellen.

Die verfügbaren Protokolle sind (Groß- und Kleinschreibung sind zu unterscheiden):

SSLv2
Das Secure Sockets Layer-Protokoll (SSL) in der Version 2.0. Dies ist ursprünglich von der Netscape Corporation entwickelte SSL-Protokoll.
SSLv3
Das Secure Sockets Layer-Protokoll (SSL) in der Version 3.0. Dieses Protokoll ist der Nachfolger von SSLv2 und der augenblickliche De-facto-Standard (Stand Februar 1999), der von der Netscape Corporation eingeführt wurde. Dieses SSL-Protokoll wird von fast allen Browsern unterstützt.
TLSv1
Das Transport Layer Security-Protokoll (TLS) in der Version 1.0. Dieses Protokoll ist der Nachfolger von SSLv3 und wird zur Zeit (Stand Februar 1999) noch von der Internet Engineering Task Force (IETF) weiterentwickelt. Keiner der gängigen Browser unterstützt bisher dieses Protokoll.
All
Dies ist die Abkürzung für +SSLv2 +SSLv3 +TLSv1, mit der auf bequeme Weise alle Protokolle bis auf das Protokoll, das mit einem Minuszeichen versehen ist, aktiviert werden können.

Beispiel # Aktiviert SSLv3 und TLSv1, nicht jedoch SSLv2
SSLProtocol all -SSLv2 SSLCipherSuite Auswahl der kryptografischen Algorithmen SSLCipherSuite Spezifikation SSLCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP server config virtual host directory .htaccess AuthConfig

Diese komplexe Direktive gibt die Algorithmusspezifikationen mit einer durch Doppelpunkte getrennten Liste an. Sie nennt OpenSSL Algorithmen, über die der Client in der SSL-Handshake-Phase verhandeln kann. Diese Direktive kann sowohl im Server- als auch im Verzeichniskontext verwendet werden. Im Serverkontext bezieht sie sich auf das standardmäßige SSL-Handshake beim Verbindungsaufbau. Im Verzeichniskontext verlangt sie ein erneutes Aushandeln mit der umkonfiguierten Spezifikation, nachdem die HTTP-Anfrage gelesen aber noch bevor die HTTP-Antwort gesendet wird.

Eine SSL Algorithmusspezifikation enthält in erster Linie Attribute zu den vier folgenden Algorithmusvarianten:

Schlüsselaustausch-Algorithmus:
RSA oder Diffie-Hellman-Varianten.
Authentifizierungsalgorithmus:
RSA, Diffie-Hellman, DSS oder none.
Verschlüsselungsalgorithmus:
DES, Triple-DES, RC4, RC2, IDEA oder none.
Message-Digest-Algorithmus (MAC):
MD5, SHA oder SHA1.

Eine SSL-Spezifikation kann auch eine Exportspezifikation sein und ist entweder eine SSLv2- oder SSLv3-/TLSv1-Spezifikation (hier entspricht TLSv1 der Spezifikation SSLv3). Um anzugeben, welche Spezifikation zu verwenden ist, können alle oder jeweils eine angegeben werden. Mit Alias-Bezeichnungen können bevorzugte Spezifikationen und deren Reihenfolge angegeben werden (siehe Tabelle 1).

Alias	Beschreibung
Schlüsselaustausch-Algorithmus:
`kRSA`	RSA-Schlüsselaustausch-Algorithmus
`kDHr`	Diffie-Hellman-Schlüsselaustausch mit RSA-Schlüssel
`kDHd`	Diffie-Hellman-Schlüsselaustausch mit DSA-Schlüssel
`kEDH`	Kurzfristiger (Ephemeral) Diffie-Hellman-Schlüsselaustausch (kein Zertifikat)
Authentifizierungsalgorithmus:
`aNULL`	Keine Authentifizierung
`aRSA`	RSA-Authentifizierung
`aDSS`	DSS-Authentifizierung
`aDH`	Diffie-Hellman-Authentifizierung
Verschlüsselungsalgorithmus:
`eNULL`	Keine Verschlüsselung
`DES`	DES-Verschlüsselung
`3DES`	Triple-DES-Verschlüsselung
`RC4`	RC4-Verschlüsselung
`RC2`	RC2-Verschlüsselung
`IDEA`	IDEA-Verschlüsselung
Message-Digest-Algorithmus:
`MD5`	MD5-Hash-Funktion
`SHA1`	SHA1-Hash-Funktion
`SHA`	SHA-Hash-Funktion
Aliases:
`SSLv2`	Alle SSL-Version-2.0-Algorithmen
`SSLv3`	Alle SSL-Version-3.0-Algorithmen
`TLSv1`	Alle TLS-Version-1.0-Algorithmen
`EXP`	Alle schwachen Eport-Algorithmen
`EXPORT40`	Alle schwachen 40-Bit-Export-Algorithmen
`EXPORT56`	Alle schwachen 56-Bit-Export-Algorithmen
`LOW`	Alle schwachen Algorithmen (kein Export, Singl-DES)
`MEDIUM`	Alle Algorithmen mit 128-Bit-Verschlüsselung
`HIGH`	Alle Algorithmen, die Triple-DES verwenden
`RSA`	Alle Algorithmen mit RSA-Schlüsselaustausch
`DH`	Alle Algorithmen mit Diffie-Hellman-Schlüsselaustausch
`EDH`	Alle Algorithmen mit kurzfristigem (Ephemeral) Diffie-Hellman-Schlüsselaustausch
`ADH`	Alle Algorithmen mit anonymem Diffie-Hellman-Schlüsselaustausch
`DSS`	Alle Algorithmen, die DSS-Authentifizierung verwenden
`NULL`	Alle Algorithmen ohne Verschlüsselung

Die Reihenfolge der Angaben ergibt hierbei auch die Priorität der jeweiligen Algorithmen wieder, so wie sie später beim SSL-Verbindungsaufbau verwendet werden. Um das Ganze zu beschleunigen gibt es auch Alias-Namen für bestimmte Algorithmengruppen (SSLv2, SSLv3, TLSv1, EXP, LOW, MEDIUM, HIGH). Diese Alias-Namen können mit Präfixen zu einer Spezifikation verbunden werden. Folgende Präfixe stehen zur Verfügung:

none: Algorithmus der Liste hinzufügen
+: Den Algorithmus der Liste hinzufügen und an die aktuelle Position in der Liste setzen.
-: Den Algorithmus aus der Liste entfernen (kann später wieder hinzugefügt werden).
!: Den Algorithmus vollständig aus der Liste entfernen (kann späet nicht wieder hinzugefügt werden).

Mit dem Befehl openssl ciphers -v können die vorgegebenen Spezifikationen angezeigt werden, was das Zusammenstellen einer Spezifikationsliste erleichtert. Die Standardvorgabe lautet ALL:! ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP. Sie bedeutet im Einzelnen: Zuerst werden alle Algorithmen ausgeschlossen, die keine Authentifizierung verwenden (für SSL bedeutet das nur den Ausschluss des anonymen Diffie-Hellman-Algorithmus. Dann werden RC4- und RSA-Algorithmen ausgewählt. Als nächstes werden die starken, mittleren und schwachen Algorithmen angegeben. Abschließend werden alle SSLv2 und Exportalgorithmen an das Ende der Liste gesetzt.

$ openssl ciphers -v 'ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP'
NULL-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=SHA1
NULL-MD5                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=MD5
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
...                     ...               ...     ...           ...
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

Tabelle 2 enthält eine volständige Liste der einzelnen RSA- und DH-Algorithmen für SSL.

Beispiel SSLCipherSuite RSA:!EXP:!NULL:+HIGH:+MEDIUM:-LOW

Algorithmus-Alias	Protokoll	Schlüsselaustausch	Auth.	Verschl.	MAC	Typ
RSA-Algorithmen:
`DES-CBC3-SHA`	SSLv3	RSA	RSA	3DES(168)	SHA1
`DES-CBC3-MD5`	SSLv2	RSA	RSA	3DES(168)	MD5
`IDEA-CBC-SHA`	SSLv3	RSA	RSA	IDEA(128)	SHA1
`RC4-SHA`	SSLv3	RSA	RSA	RC4(128)	SHA1
`RC4-MD5`	SSLv3	RSA	RSA	RC4(128)	MD5
`IDEA-CBC-MD5`	SSLv2	RSA	RSA	IDEA(128)	MD5
`RC2-CBC-MD5`	SSLv2	RSA	RSA	RC2(128)	MD5
`RC4-MD5`	SSLv2	RSA	RSA	RC4(128)	MD5
`DES-CBC-SHA`	SSLv3	RSA	RSA	DES(56)	SHA1
`RC4-64-MD5`	SSLv2	RSA	RSA	RC4(64)	MD5
`DES-CBC-MD5`	SSLv2	RSA	RSA	DES(56)	MD5
`EXP-DES-CBC-SHA`	SSLv3	RSA(512)	RSA	DES(40)	SHA1	Export
`EXP-RC2-CBC-MD5`	SSLv3	RSA(512)	RSA	RC2(40)	MD5	Export
`EXP-RC4-MD5`	SSLv3	RSA(512)	RSA	RC4(40)	MD5	Export
`EXP-RC2-CBC-MD5`	SSLv2	RSA(512)	RSA	RC2(40)	MD5	Export
`EXP-RC4-MD5`	SSLv2	RSA(512)	RSA	RC4(40)	MD5	Export
`NULL-SHA`	SSLv3	RSA	RSA	None	SHA1
`NULL-MD5`	SSLv3	RSA	RSA	None	MD5
Diffie-Hellman-Algorithmen+695 5:
`ADH-DES-CBC3-SHA`	SSLv3	DH	None	3DES(168)	SHA1
`ADH-DES-CBC-SHA`	SSLv3	DH	None	DES(56)	SHA1
`ADH-RC4-MD5`	SSLv3	DH	None	RC4(128)	MD5
`EDH-RSA-DES-CBC3-SHA`	SSLv3	DH	RSA	3DES(168)	SHA1
`EDH-DSS-DES-CBC3-SHA`	SSLv3	DH	DSS	3DES(168)	SHA1
`EDH-RSA-DES-CBC-SHA`	SSLv3	DH	RSA	DES(56)	SHA1
`EDH-DSS-DES-CBC-SHA`	SSLv3	DH	DSS	DES(56)	SHA1
`EXP-EDH-RSA-DES-CBC-SHA`	SSLv3	DH(512)	RSA	DES(40)	SHA1	Export
`EXP-EDH-DSS-DES-CBC-SHA`	SSLv3	DH(512)	DSS	DES(40)	SHA1	Export
`EXP-ADH-DES-CBC-SHA`	SSLv3	DH(512)	None	DES(40)	SHA1	Export
`EXP-ADH-RC4-MD5`	SSLv3	DH(512)	None	RC4(40)	MD5	Export

SSLCertificateFile
X.509-Serverzertifikat im PEM-Format
SSLCertificateFile Dateipfad
server config
virtual host

Mit dieser Direktive wird auf das Serverzertifikat (PEM-Format) und optional
auch auf den privaten RSA- oder DSA-Schlüssel aus der gleichen Datei
verwiesen. Ist der enthaltene private Schlüssel verschlüsselt, wird beim
Start der Passphrasen-Dialog geöffnet. Diese Direktive kann zweimal
verwendet werden (mit unterschiedlichen Verweisen), wenn ein RSA- und
ein DSA-Serverzertifikat parallel benutzt werden.
Beispiel
SSLCertificateFile /usr/local/apache2/conf/ssl.crt/server.crt

SSLCertificateKeyFile
Gibt die PEM-Datei mit dem privaten Schlüssel an.
SSLCertificateKeyFile Dateipfad
server config
virtual host

Diese Direktive verweist auf die PEM-Datei mit dem privaten Schlüssel für den Server. Befindet sich der private Schlüssel nicht zusammen mit dem Zertifikat
in der Zertifikatdatei, wird mit dieser Direktive auf die Datei mit dem privaten
Schlüssel verwiesen. Wird die Direktive SSLCertificateFile
verwendet und enthält die Datei sowohl Zertifikat als auch den privaten Schlüssel,
dann ist diese Direktive überflüssig. Allerdings ist von dieser Praxis unbedingt
abzuraten. Zertifikat und privater Schlüssel sollten voneinander getrennt werden.
Ist der enthaltene private Key verschlüsselt, wird beim Start der
Passphrasen-Dialog geöffnet. Diese Direktive kann zweimal
verwendet werden (mit unterschiedlichen Verweisen), wenn ein RSA- und
ein DSA-Serverzertifikat parallel benutzt werden.
Beispiel
SSLCertificateKeyFile /usr/local/apache2/conf/ssl.key/server.key

SSLCertificateChainFile
PEM-Datei mit CA-Serverzertifikaten
SSLCertificateChainFile Dateipfad
server config
virtual host

In der mit dieser Direktive definierten Datei können alle Zertifikate von
Zertifizierungsinstanzen (CA = Certifcate Authority) in Form einer
Serverzertifikat-Kette abgelegt werden. Sie beginnt mit dem
CA-Zertifikat für den Server und kann bis zum Root-Zertifikat einer CA
führen. Diese Datei ist eine Verkettung der unterschiedlichen
CA-Zertifikatdateien (PEM-Format), wobei die Reihenfolge der Verkettung meist
der bevorzugten Reihenfolge entspricht.

Diese Möglichkeit kann alternativ und/oder zusätzlich zur SSLCACertificatePath-Direktive für
die explizite Konstruktion einer Serverzertifikat-Kette benutzt werden,
die neben dem Serverzertifikat an den Browser gesendet wird.
Dadurch können bei der Client-Authentifizierung Konflikte mit CA-Zertifikaten
vermieden werden. Obwohl die Platzierung eines CA-Zertifikats aus der Serverzertifikat-Kette in das mit SSLCACertificatePath angegebene Verzeichns für die
Konstruktion der Zertifikatkette den gleichen Effekt hat, hat dies den
Nebeneffekt, dass Client-Zertifikate des gleichen CA-Zertifikats bei der
Client-Authentifizierung unerwarteter Weise ebenfalls akzeptiert werden.

Dabei ist aber zu beachten, die Zertifikatverkettung nur funktioniert, wenn
ein einziges RSA- oder DSA-Serverzertifikat
benutzt wird. Werden verkoppelte RSA- und DSA-Zertifikatpaare benutzt,
dann funktioniert das nur, wenn tatsächlich beide Zertifikate die gleiche Zertifikatkette verwenden. Andernfalls kommt der Browser mit dieser Situation
nicht zurecht.
Beispiel
SSLCertificateChainFile /usr/local/apache2/conf/ssl.crt/ca.crt

SSLCACertificatePath
Gibt das Verzeichnis mit den PEM-Dateien der Zertifikate der CAs
für die Client-Authentifizierung an.
SSLCACertificatePath Verzeichnispfad
server config
virtual host

Diese Direktive gibt das Verzeichnis an, in dem sich die Zertifikate der
Zertifizierungsinstanzen (CAs) für die Clients befinden. Mit ihnen wird das
Client-Zertifikat bei Client-Authentifizierung überprüft.

Bei den Dateien in diesem Verzeichnis muss es sich PEM-Dateien handeln.
Der Zugriff erfolgt über einen Hashwert.
Daher können normalerweise keine Zertifikatdateien in diesem Verzeichnis abgelegt
werden. Vielmehr müssen symbolische Links mit der Bezeichnung
Hashwert.N erzeugt werden. Ferner sollte
immer dafür gesorgt werden, dass das Verzeichnis die entsprechenden
symbolischen Links enthält. Diese Aufgabe kann mit dem zu
mod_ssl gehörenden Programm Makefile
erledigt werden.
Beispiel
SSLCACertificatePath /usr/local/apache2/conf/ssl.crt/

SSLCACertificateFile
Verkettete PEM-Datei mit Zertifikaten der CAs für
die Client-Authentifizierung
SSLCACertificateFile Dateipfad
server config
virtual host

Diese Direktive definiert die verkettete Datei mit allen Zertifikaten von Zertifizierungsinstanzen (CA) für die Clients. Mit ihnen wird das
Client-Zertifikat bei Client-Authentifizierung überprüft. Diese Datei ist
eine Verkettung der unterschiedlichen PEM-Zertifikatdateien in der Reihenfolge
ihrer Priorität. Die Direktive kann alternativ und/oder zusätzlich zur
SSLCACertificatePath-Direktive
benutzt werden.
Beispiel
SSLCACertificateFile /usr/local/apache2/conf/ssl.crt/ca-bundle-Client.crt

SSLCARevocationPath
Gibt das Verzeichnis der PEM-Dateien mit CA-Certificate
Revocation-Listen (CRLs) für die Client-Authentifizierung an.
SSLCARevocationPath Verzeichnis
server config
virtual host

Diese Direktive gibt das Verzeichnis mit den Certificate
Revocation-Listen (CRLs) der Zertifizierungsinstanzen der Clients an.
Mit ihnen werden Client-Zertifikate für die Client-Authentifizierung
widerrufen.

Bei den Dateien in diesem Verzeichnis muss es sich PEM-Dateien handeln.
Der Zugriff erfolgt über einen Hashwert.
Daher können normalerweise keine CLR-Dateien in diesem Verzeichnis abgelegt
werden. Vielmehr müssen symbolische Links mit der Bezeichnung
Hashwert.rN erzeugt werden. Ferner sollte
immer dafür gesorgt werden, dass das Verzeichnis die entsprechenden
symbolischen Links enthält. Diese Aufgabe kann mit dem zu
mod_ssl gehörenden Programm Makefile
erledigt werden.
Beispiel
SSLCARevocationPath /usr/local/apache2/conf/ssl.crl/

SSLCARevocationFile
Verkettung der PEM-Dateien mit CA-Certificate
Revocation-Listen (CRLs) für die Client Authentifizierung
SSLCARevocationFile Dateipfad
server config
virtual host

Diese Direktive definiert die verkettete Datei mit allen Certificate Revocation-Listen
(CRLs) von Zertifizierungsinstanzen (CAs) für die zu bedienenden Clients.
Sie werden für die Client-Authentifizierung benutzt. Diese Datei ist
eine Verkettung der unterschiedlichen CLR-Dateien (PEM-Format) in der
Reihenfolge ihrer Priorität. Die Direktive kann alternativ und/oder zusätzlich zur
SSLCAPath-Direktive
benutzt werden.
Beispiel
SSLCARevocationFile /usr/local/apache2/conf/ssl.crl/ca-bundle-Client.crl

SSLVerifyClient
Legt die Stufe der Client-Zertifikatverifikation fest.
SSLVerifyClient Stufe
SSLVerifyClient none
server config
virtual host
directory
.htaccess
AuthConfig

Diese Direktive legt die Stufe für die Zertifikatverifikation bei der
Client-Authentifizierung fest. Sie kann global oder im Verzeichniskontext benutzt
werden. Global bezieht sie sich auf die Client-Authentifizierung beim
standardmäßigen SSL-Handshake für den Verbindungsaufbau. Im
Verzeichniskontext erzwingt sie nach dem Lesen der HTTP-Anfrage aber vorm Senden der HTTP-Antwort ein neues Aushandeln mit der neu konfigurierten
Verifikationsstufe.

Folgende Stufen stehen zur Verfügung:

none:
Kein Client-Zertifikat erforderlich
optional:
Der Client kann ein gültiges Zertifikat vorlegen
require:
Der Client muss ein gültiges Zertifikat vorlegen
optional_no_ca:
Der Client kann ein gültiges Zertifikat vorlegen,

das jedoch nicht erfolgreich verifiziert werden muss.

Für die Praxis sind nur die Stufen none und
require von Interesse, weil die Stufe
optional nicht mit allen Browsern funktioniert und die Stufe
optional_no_ca dem Sinn der Autentifizierung
widerspricht (sie kann aber für Testzwecke benutzt werden).
Beispiel
SSLVerifyClient require

SSLVerifyDepth
Maximale Anzahl der Zertifikate von CAs bei der
Client-Zertifikatverifikation
SSLVerifyDepth Anzahl
SSLVerifyDepth 1
server config
virtual host
directory
.htaccess
AuthConfig

Diese Direktive legt fest, bis zu welcher Tiefe das Modul mod_ssl
die Zertifikatüberprüfung durchführen soll, bevor entschieden wird, dass
der Client kein gültiges Zertifikat besitzt. Diese Direktive kann
sowohl im Serverkontext als auch im Verzeichniskontext benutzt werden.
Im Serverkontext wird sie für die Client-Authentifizierung beim
standardmäßigen SSL-Handshake für den Verbindungsaufbau benutzt.
Im Verzeichniskontext erzwingt sie nach dem Lesen der Anfrage und vorm
Versenden der Antwort ein erneutes Aushandeln mit der neu
konfigurierten Tiefe für die Client-Verifikation.

Die Tiefe entspricht der maximalen Anzahl der dazwischen liegenden
Zertifikate, d.h. der Anzahl der erlaubten CA-Zertifikate zwischen dem Client-Zertifikat und dem Zertifikat, das dem Server bekannt ist. Die Anzahl
0 bedeutet, dass nur selbst signierte Client-Zertifikate
akzeptiert werden. Die Voreinstellung 1 bedeutet, dass das
Client-Zertifikat selbst signiert sein kann oder von einer CA signiert sein
muss, die dem Server unmittelbar bekannt ist (d.h. das CA-Zertifikat befindet
im mit der Direktive
SSLCACertificatePath
angegebenen Verzeichnis).
Beispiel
SSLVerifyDepth 10

SSLOptions
Konfiguriert verschiedene Optionen für SSL.
SSLOptions [+|-]Option ...
server config
virtual host
directory
.htaccess
Options

Mit dieser Direktive können verschiedene Laufzeitoptionen auf
Verzeichnisebene gesteuert werden. Sind mehrere SSL-Optionen auf ein
Verzeichnis anwendbar, werden normalerweise die spezifischsten vollständig
übernommen, eine Vermischung findet nicht statt. Wird aber
allen Optionen der SSLOptions-Direktive ein
Plus- (+) oder Minuszeichen (-) vorangestellt,
dann werden die Optionen vermischt. Jede Option, der ein Pluszeichen
vorangestellt wird, wird der Option hinzugefügt, die gerade in Kraft ist.
Jede Option, der ein Minuszeichen vorangestellt wird, wird aus der Menge
der gearde aktiven Optionen entfernt.

Folgende Optionen stehen zur Verfügung:

StdEnvVars

Wird diese Option aktiviert, werden die für SSL standardmäßigen
CGI/SSI-Umgebungsvariablen erzeugt. Da das Extrahieren der erforderlichen
Informationen sehr aufwändig ist, ist diese Option laut Vorgabe deaktiviert.
Sie sollte nur für CGI- und SSI-Anfragen aktiviert werden.

CompatEnvVars

Wird diese Option aktiviert, wreden zusätzliche CGI/SSI-Umgebungsvariablen
für die Abwärtskompatibilität zu anderen Apache SSL-Lösungen erzeugt. Im
Kapitel Kompatibilität finden Sie weitere
Informationen zu den einzelnen Variablen.

ExportCertData

Wird diese Option aktiviert, werden die CGI/SSI-Umgebungsvariablen
SSL_SERVER_CERT, SSL_CLIENT_CERT
und
SSL_CLIENT_CERT_CHAINn (mit n
= 0,1,2,..) erzeugt. Sie enthalten die X.509-Zertifikate von Server und Client
für die aktuelle HTTPS-Verbindung im PEM-Format und können in
CGI-Skripten für eine weiterreichende Zertifikatprüfung benutzt werden.
Darüber hinaus werden alle anderen Zertifikate der Client-Zertifikatkette
zur Verfügung gestellt. Weil dadurch der für die Umgebungsvariablen
benötigte Raum umfangreicher wird, muss diese Option bei Bedarf
aktiviert werden.

FakeBasicAuth

Wird diese Option aktiviert, wird der Subject Distinguished Name (DN) des
X509-Zertifikats des Clients in einen Benutzernamen für die HTTP Basic-
Authentifizierung umgewandelt, damit die standardmäßigen
Apache-Authentifizierungsmethoden
für die Zugriffskontrolle benutzt werden können.
Der Benutzername aus dem X509-Zertifikat des Clients kann mit dem
OpenSSL-Befehl openssl x509 ermittelt werden:
openssl x509 -noout -subject -in
Zertifikat.crt. Ein Passwort
wird vom Benutzer nicht entgegen genommen. Jeder Eintrag in der
Benutzerdatei benötigt das Passwort xxj31ZMTZzkVA,
was die DES-verschlüsselte Version des Wortes
password ist. Bei Betriebssystemen wie FreeBSD oder
BSD/OS, die MD5 für die Passwortverschlüsselung verwenden, muss der
MD5-Hash für das gleiche Wort benutzt
werden : $1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/.

StrictRequire

Diese Anweisung verweigert den Zugriff, wenn mit den Direktiven
SSLRequireSSL oder SSLRequire eine
SSL-Verbindung vorgeschrieben wird. Normalerweise legt die Voreinstellung
fest, dass bei Verwendung der Satisfy any-Direktive und
bei Übergabe weiterer Zugriffsbeschränkungen die Zugriffsverweigerung
infolge der SSLRequireSSL- oder
SSLRequire-Anweisungen überschrieben wird (was der
Funktionsweise des Satisfy-Mechanismus entspricht.) Für
strikte Zugriffsbeschränkungen können die Direktiven
SSLRequireSSL und/oder SSLRequire in
Kombination mit SSLOptions +StrictRequire benutzt werden.
Satisfy Any bleibt dann wirkungslos, wenn
mod_ssl den Zugriff verweigert.

OptRenegotiate

Bewirkt ein erneutes Aushandeln optimierter SSL-Verbindungsparameter, wenn
SSL-Direktiven im Verzeichniskontext angewendet werden.
Standardmäßig ist ein strenges Schema aktiviert, bei dem
jeder neu konfigurierte SSL-Parameter für den
Verzeichniskontext immer ein vollständiges sogenanntes
SSL-Renegotiation-Handshake auslöst. Wird diese Option
gesetzt, versucht mod_ssl unnötige Handshakes über eine
genauere (aber immer noch sichere) Prüfung der Parameter zu vermeiden.
Allerdings muss das Ergebnis nicht immer den Erwartungen entsprechen und
daher sollte die Direktive nur im Verzeichniskontext benutzt werden.

Beispiel
SSLOptions +FakeBasicAuth -StrictRequire

SSLOptions +StdEnvVars +CompatEnvVars -ExportCertData

<Files>

SSLRequireSSL
Deny access when SSL is not used for the
HTTP-Anfrage
SSLRequireSSL
directory
.htaccess
AuthConfig

Diese Direktive lässt einen Zugriff nur dann zu, wenn HTTP über SSL
(HTTPS) für die aktuelle Verbindung aktiviert wurde. Das ist ganz praktisch
für die Vermeidung von Konfigurationsfehlern bei virtuellen SSL-Hosts oder
Verzeichnissen, die eigentlich geschützte Inhalte unverschlüsselt freigeben. Wurde
diese Option gesetzt, werden alle Anfragen, die nicht SSL verwenden,
abgewiesen.
Beispiel
SSLRequireSSL

SSLRequire
Zugriff wird nur gewährt, wenn ein Boole'scher Ausdruck
erfüllt ist.
SSLRequire Ausdruck
directory
.htaccess
AuthConfig

Mit dieser Direktive wird eine allgemeine Bedingung für den Zugriff
angegeben, die erfüllt sein muss. Sie ist sehr wirkungsvoll, weil die Spezifikation
der Bedingung ein beliebiger komplexer Boole'scher Ausdruck mit einer
beliebigen Anzahl von Überprüfungen der Zugriffsrechte sein kann.

Der Ausdruck muss folgender Syntax entsprechen
(BNF-Notation):

expr ::= "true" | "false"
| "!" expr
| expr "&&" expr
| expr "||" expr
| "(" expr ")"
| comp

comp ::= word "==" word | word "eq" word
| word "!=" word | word "ne" word
| word "<" word | word "lt" word
| word "<=" word | word "le" word
| word ">" word | word "gt" word
| word ">=" word | word "ge" word
| word "in" "{" wordlist "}"
| word "=~" regex
| word "!~" regex

wordlist ::= word
| wordlist "," word

word ::= digit
| cstring
| variable
| function

digit ::= [0-9]+
cstring ::= "..."
variable ::= "%{" VarName "}"
function ::= funcname "(" funcargs ")"

Für VarName kann jede Variable aus Tabelle 3 benutzt werden. Für funcname
steht folgende Funktion zur Verfügung:

file(Dateiname)

Diese Funktion übernimmt eine Zeichenfolge als Argument, um den Inhalt
der Datei mit der Variablen zu vergleichen, was sich besonders für einen
Vergleich mit regulären Ausdrücken eignet.

Beispiel
SSLRequire ( %{SSL_CIPHER} !~ m/^(EXP|NULL)-/ \

und %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \

und %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \

und %{TIME_WDAY} >= 1 und %{TIME_WDAY} <= 5 \

und %{TIME_HOUR} >= 8 und %{TIME_HOUR} <= 20 ) \

oder %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/

Standard CGI/1.0- und Apache-Variablen:
HTTP_USER_AGENT PATH_INFO AUTH_TYPE
HTTP_REFERER QUERY_STRING SERVER_SOFTWARE
HTTP_COOKIE REMOTE_HOST API_VERSION
HTTP_FORWARDED REMOTE_IDENT TIME_YEAR
HTTP_HOST IS_SUBREQ TIME_MON
HTTP_PROXY_CONNECTION DOCUMENT_ROOT TIME_DAY
HTTP_ACCEPT SERVER_ADMIN TIME_HOUR
HTTP:headername SERVER_NAME TIME_MIN
THE_REQUEST SERVER_PORT TIME_SEC
REQUEST_METHOD SERVER_PROTOCOL TIME_WDAY
REQUEST_SCHEME REMOTE_ADDR TIME
REQUEST_URI REMOTE_USER ENV:Variablenname
REQUEST_FILENAME

SSL-Variablen:
HTTPS SSL_CLIENT_M_VERSION SSL_SERVER_M_VERSION
SSL_CLIENT_M_SERIAL SSL_SERVER_M_SERIAL
SSL_PROTOCOL SSL_CLIENT_V_START SSL_SERVER_V_START
SSL_SESSION_ID SSL_CLIENT_V_END SSL_SERVER_V_END
SSL_CIPHER SSL_CLIENT_S_DN SSL_SERVER_S_DN
SSL_CIPHER_EXPORT SSL_CLIENT_S_DN_C SSL_SERVER_S_DN_C
SSL_CIPHER_ALGKEYSIZE SSL_CLIENT_S_DN_ST SSL_SERVER_S_DN_ST
SSL_CIPHER_USEKEYSIZE SSL_CLIENT_S_DN_L SSL_SERVER_S_DN_L
SSL_VERSION_LIBRARY SSL_CLIENT_S_DN_O SSL_SERVER_S_DN_O
SSL_VERSION_INTERFACE SSL_CLIENT_S_DN_OU SSL_SERVER_S_DN_OU
SSL_CLIENT_S_DN_CN SSL_SERVER_S_DN_CN
SSL_CLIENT_S_DN_T SSL_SERVER_S_DN_T
SSL_CLIENT_S_DN_I SSL_SERVER_S_DN_I
SSL_CLIENT_S_DN_G SSL_SERVER_S_DN_G
SSL_CLIENT_S_DN_S SSL_SERVER_S_DN_S
SSL_CLIENT_S_DN_D SSL_SERVER_S_DN_D
SSL_CLIENT_S_DN_UID SSL_SERVER_S_DN_UID
SSL_CLIENT_S_DN_Email SSL_SERVER_S_DN_Email
SSL_CLIENT_I_DN SSL_SERVER_I_DN
SSL_CLIENT_I_DN_C SSL_SERVER_I_DN_C
SSL_CLIENT_I_DN_ST SSL_SERVER_I_DN_ST
SSL_CLIENT_I_DN_L SSL_SERVER_I_DN_L
SSL_CLIENT_I_DN_O SSL_SERVER_I_DN_O
SSL_CLIENT_I_DN_OU SSL_SERVER_I_DN_OU
SSL_CLIENT_I_DN_CN SSL_SERVER_I_DN_CN
SSL_CLIENT_I_DN_T SSL_SERVER_I_DN_T
SSL_CLIENT_I_DN_I SSL_SERVER_I_DN_I
SSL_CLIENT_I_DN_G SSL_SERVER_I_DN_G
SSL_CLIENT_I_DN_S SSL_SERVER_I_DN_S
SSL_CLIENT_I_DN_D SSL_SERVER_I_DN_D
SSL_CLIENT_I_DN_UID SSL_SERVER_I_DN_UID
SSL_CLIENT_I_DN_Email SSL_SERVER_I_DN_Email
SSL_CLIENT_A_SIG SSL_SERVER_A_SIG
SSL_CLIENT_A_KEY SSL_SERVER_A_KEY
SSL_CLIENT_CERT SSL_SERVER_CERT
SSL_CLIENT_CERT_CHAINn
SSL_CLIENT_VERIFY

SSLProxyMachineCertificatePath
Gibt das Verzeichnis mit den PEM-Dateien der Zertifikate der CAs
für die Client-Authentifizierung durch den Proxy an.
SSLProxyMachineCertificatePath directory
server config
Not applicable

Diese Direktive gibt das Verzeichnis an, in dem sich die Zertifikate der
Zertifizierungsinstanzen (CAs) für die Proxy-Clients befinden, mit denen sich der Proxy ausweist.

Beispiel:

SSLProxyMachineCertificatePath /usr/local/apache2/conf/ssl.crt/

SSLProxyMachineCertificateFile
Verkettete PEM-Datei mit Zertifikaten der CAs
für Proxy-Server-Clients
SSLProxyMachineCertificateFile Dateiname
server config
Not applicable

Diese Direktive definiert die verkettete Datei mit allen Zertifikaten von Zertifizierungsinstanzen (CA) für die Authentifizierung der Clients
durch den Proxy-Server. Die Direktive kann alternativ und/oder zusätzlich zur
SSLProxyMachineCertificatePath-Direktive benutzt werden.

Beispiel:

SSLProxyMachineCertificateFile /usr/local/apache2/conf/ssl.crt/

SSLProxyVerify
Stufe der Zertifikatverifikation durch den Remote-Server
SSLProxyVerify Stufe
SSLProxyVerify none
server config
virtual host
directory
.htaccess
AuthConfig

Diese Direktive legt die Stufe für die Zertifikatverifikation bei der
Client-Authentifizierung durch den entfernten Server fest. Sie kann global
oder im Verzeichniskontext benutzt
werden. Global bezieht sie sich auf die Client-Authentifizierung beim
standardmäßigen SSL-Handshake für den Verbindungsaufbau. Im
Verzeichniskontext erzwingt sie nach dem Lesen der HTTP-Anfrage
aber vorm Senden der HTTP-Antwort ein neues Aushandeln mit der neu
konfigurierten Verifikationsstufe.

Folgende Stufen stehen zur Verfügung:

none:
Kein Zertifikat des entfernten Servers erforderlich
optional:
Der entfernte Server kann ein gültiges Zertifikat vorlegen
require:
Der entfernte Server muss ein gültiges Zertifikat vorlegen
optional_no_ca:
Der entfernte Server kann ein gültiges Zertifikat vorlegen,

das jedoch nicht erfolgreich verifiziert werden muss.

SSLProxyVerifyDepth
Maximale Anzahl der Zertifikate von CAs bei der
Proxy-Server-Zertifikatverifikation
SSLProxyVerifyDepth Anzahl
SSLProxyVerifyDepth 1
server config
virtual host
directory
.htaccess
AuthConfig

Diese Direktive legt fest, bis zu welcher Tiefe das Modul mod_ssl
die Zertifikatüberprüfung durchführen soll, bevor entschieden wird, dass
der entfernte Server kein gültiges Zertifikat besitzt. Diese Direktive kann
sowohl im Serverkontext als auch im Verzeichniskontext benutzt werden.
Im Serverkontext wird sie für die Client-Authentifizierung beim
standardmäßigen SSL-Handshake für den Verbindungsaufbau benutzt.
Im Verzeichniskontext erzwingt sie nach dem Lesen der Anfrage und vorm
Versenden der Antwort ein erneutes Aushandeln mit der neu
konfigurierten Tiefe für die Client-Verifikation.

Die Tiefe entspricht der maximalen Anzahl der dazwischen liegenden
Zertifikate, d.h. der Anzahl der erlaubten CA-Zertifikate zwischen dem Proxy-Zertifikat und dem Zertifikat, das dem Server bekannt ist. Die Anzahl
0 bedeutet, dass nur selbst signierte Server-Zertifikate
akzeptiert werden. Die Voreinstellung 1 bedeutet, dass das
Server-Zertifikat selbst signiert sein kann oder von einer CA signiert sein
muss, die dem Server unmittelbar bekannt ist (d.h. das CA-Zertifikat befindet
sich im mit der Direktive
SSLCACertificatePath
angegebenen Verzeichnis).

Beispiel
SSLProxyVerifyDepth 10

SSLProxyEngine
Aktiviert das SSL/TLS-Protokoll.
SSLProxyEngine on|off
SSLProxyEngine off
server config
virtual host

Diese Direktive aktiviert das SSL/TLS-Protokoll für den Proxy-Server. Sie wird
normalerweise im VirtualHost-Abschnitt gesetzt, um das
SSL/TLS-Protokoll für einen bestimmten virtuellen Proxy-Host zu aktivieren.
Standardmäßig ist das SSL/TLS-Protokoll sowohl für die Proxy-Funktion des
Hauptservers als auch für die virtuellen Hosts deaktiviert.

Beispiel
<VirtualHost _default_:443>

SSLProxyEngine on

...

</VirtualHost>

SSLProxyProtocol
Aktiviert ein bestimmtes SSL-Protokoll.
SSLProxyProtocol [+|-]Protokoll ...
SSLProxyProtocol all
server config
virtual host
Options

Mit dieser Direktive kann eines der von OpenSSL unterstützten Protokolle
für die Proxy-Serverumgebung von mod_ssl ausgewählt werden.
Verbindungen können dann nur über dieses Protokoll hergestellt werden.

Weitere Informationen finden Sie unter
SSLProtocol.

SSLProxyCipherSuite
Auswahl der kryptografischen Algorithmen bei der Aushandlung
des SSL-Proxy-Handshake
SSLProxyCipherSuite Spezifikation
SSLProxyCipherSuite ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP
server config
virtual host
directory
.htaccess
AuthConfig

Dieses Modul ist das Äquivalent von SSLCipherSuite
für Proxy-Verbindungen. Weitere Informationen finden Sie unter
SSLCipherSuite.

SSLProxyCACertificatePath
Verzeichnis mit den Zertifikaten der CAs für die Authentifizierung
der Remote-Server
SSLProxyCACertificatePath Verzeichnis
server config
virtual host

Diese Direktive gitbt das Verzeichnis mit den Zertifikaten der
Zertifizierungsinstanzen für Remote-Server an. Sie werden für die Verifizierung
der Remote-Serverzertifikate bei der Authentifizierung benutzt.

Bei den Dateien in diesem Verzeichnis muss es sich PEM-Dateien handeln.
Der Zugriff erfolgt über einen Hashwert.
Daher können normalerweise keine CLR-Dateien in diesem Verzeichnis abgelegt
werden. Vielmehr müssen symbolische Links mit der Bezeichnung
Hashwert.N erzeugt werden. Ferner sollte
immer dafür gesorgt werden, dass das Verzeichnis die entsprechenden
symbolischen Links enthält. Diese Aufgabe kann mit dem zu
mod_ssl gehörenden Programm Makefile
erledigt werden.
Beispiel
SSLProxyCACertificatePath /usr/local/apache2/conf/ssl.crt/

SSLProxyCACertificateFile
Gibt das Verzeichnis mit den verketteten PEM-Dateien
der Zertifikate der CAs für die Proxy-Server-Authentifizierung an.
SSLProxyCACertificateFile Dateipfad
server config
virtual host

Diese Direktive definiert die verkettete Datei mit allen Zertifikaten von Zertifizierungsinstanzen (CA) für die Remote-Server. Mit ihnen wird
die Remote-Server-Authentifizierung durchgeführt. Diese Datei ist
eine Verkettung der unterschiedlichen PEM-Zertifikatdateien in der Reihenfolge
ihrer Priorität. Die Direktive kann alternativ und/oder zusätzlich zur
SSLProxyCACertificatePath-Direktive
benutzt werden.

Beispiel
SSLProxyCACertificateFile /usr/local/apache2/conf/ssl.crt/ca-bundle-remote-server.crt

SSLProxyCARevocationPath
Gibt das Verzeichnis der PEM-Dateien mit CA-Certificate
Revocation-Listen (CRLs) an.
SSLProxyCARevocationPath Verzeichnis
server config
virtual host

Diese Direktive gibt das Verzeichnis mit den Certificate Revocation
Listen (CRLs) der Zertifizierungsinstanzen für die Remote-Server an.
Mit ihnen werden Serverzertifikate für die Authentifizierung
widerrufen.
Bei den Dateien in diesem Verzeichnis muss es sich PEM-Dateien handeln.
Der Zugriff erfolgt über einen Hashwert.
Daher können normalerweise keine CLR-Dateien in diesem Verzeichnis abgelegt
werden. Vielmehr müssen symbolische Links mit der Bezeichnung
Hashwert.rN erzeugt werden. Ferner sollte
immer dafür gesorgt werden, dass das Verzeichnis die entsprechenden
symbolischen Links enthält. Diese Aufgabe kann mit dem zu
mod_ssl gehörenden Programm Makefile
erledigt werden.

Beispiel
SSLProxyCARevocationPath /usr/local/apache2/conf/ssl.crl/

SSLProxyCARevocationFile
Verkettung der PEM-Dateien mit CA-Certificate Revocation
Listen (CRLs) für die Remote-Server-Authentifizierung
SSLProxyCARevocationFile Dateipfad
server config
virtual host

Diese Direktive definiert die verkettete Datei mit allen Certificate Revocation-Listen
(CRLs) von Zertifizierungsinstanzen (CAs) für die Remote-Server.
Sie werden für die Authentifizierung benutzt. Diese Datei ist
eine Verkettung der unterschiedlichen CLR-Dateien (PEM-Format) in der
Reihenfolge ihrer Priorität. Die Direktive kann alternativ und/oder zusätzlich zur
SSLCAPath-Direktive
benutzt werden.
.
Beispiel
SSLProxyCARevocationFile /usr/local/apache2/conf/ssl.crl/ca-bundle-remote-server.crl

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

German Translatiom mod_ssl

Reply via email to