SSL-Webserver

Apache Server für das verschlüsselte HTTPS-Protokoll

Mit dem Apache Webserver kann man u.a. auch einen SSL-Webserver konfigurieren, der mit dem verschlüsselten (sicheren) HTTPS-Protokoll arbeitet.

Meistens werden beide Protokolle (HTTP und HTTPS) gleichzeitig von je einem eigenen virtuellen Webserver unterstützt.

Apache	Der weltweit erfolgreichste Standard Webserver (Linux, Windows)
SSL, TLS, HTTPS	Minimal-Information zu den verwendeten Technologien und Begriffen.
Voraussetzungen	Administrations-Rechte, Software, Daten, Vorarbeiten
Linux CA	Herstellung einer 'virtuellen' Certificate Authority
Linux Server	Herstellung und Selbst-Beglaubigung eines Schlüssels für den eigenen Server
Windows-Umgebung	Vorarbeiten auf Windows
Windows Server	SSL-Schlüssel für einen Apache Webserver auf Windows
Prüfung	Gültigkeit und die in den Schlüsseln enthaltenen Daten
Apache-SSL	Anpassung der Konfiguration des Apache Webservers
Verwandte Themen	Zugriffs-Schutz (Anmeldung mit Name und Passwort)
Links	Ausgewählte Links zum Thema Apache SSL-Webserver

Secure Sockets Layer (SSL, TLS, HTTPS)
SSL Das Protokoll Secure Sockets Layer (SSL) ist eine Vorschrift (Sammlung von Regeln) zur sicheren Übertragung von verschlüsselten Daten im Netzwerk. Seit Version 3.0 wird das Protokoll unter dem kaum bekannten Namen Transport Layer Security (TLS) weiter entwickelt.	♦ Details zum SSL Protokoll finden sie in Artikeln zur Netzwerk-Technik und zur Verschlüsselung (Kryptografie). SSL wird auf dieser Seite nicht erklärt, sondern 'so wie verfügbar' für einen eigenen Webserver verwendet.
HTTPS Das Protokoll HyperText Transfer Protocol Secure (HTTPS) verknüpft die beiden Protokolle HTTP und SSL zur sicheren Übertragung von Daten im Netzwerk (sowohl im eigenen lokalen Netzwerk LAN als auch im globalen Internet). Zur Kommunikation wird das bewährte → HTTP-Protokoll verwendet, welches Anweisungen aus einfachem (lesbaren) Text verwendet. Diese Anweisungen werden jedoch vor dem Absenden mit SSL verschlüsselt und nach Ankunft decodiert. Jeder gängige Browser beherrscht HTTPS. Eine sichere HTTPS-Verbindung wird immer angezeigt, z.B. mit einem Vorhängschloss-Icon. Einen Webserver muss man dafür jedoch konfigurieren, d.h. der Server muss seine Identität mit Hilfe eines beglaubigten Schlüssels eindeutig und überprüfbar nachweisen.	Die hohe Sicherheit wird durch ein System von verteilten Schlüsseln (Keys) erreicht. Jeder Webserver, welcher HTTPS anbietet, verfügt über einen eigenen (privaten, eindeutigen) Schlüssel, mit dessen Hilfe ein Client (Browser) das Vertrauen zum Server herstellen und die von ihm erhaltenen Daten decodieren kenn. Um Missbrauch zu vermeiden, muss der Server-Schlüssel von einer Certificate Authority (CA) beglaubigt (zertifiziert) werden. Die Funktion der CA ist ähnlich der eines Notars. CA's sind gegen Angriffe sehr aufwändig abgesichert. Damit ist die Methode nur wenig von der oft zweifelhaften Sicherheit der einzelnen Server abhängig. ● Jeder Browser kann die Echtheit eines Server-Schlüssels sehr rasch feststellen und verweigert die Verbindung bei Verdacht auf Probleme. Wenn man auf der zweifelhaften Verbindung besteht, dann muss man ausdrücklich eine Ausnahme genehmigen - Das ist für die selbst-beglaubigten Schlüssel dieser Seite notwendig.
Selbst-Beglaubigung Auch im nicht-professionellen Bereich hat sich ein zunehmender Bedarf nach sicherer Übertragung von Daten ergeben, und zwar nach Möglichkeit auch ohne die kostenpflichtige Beglaubigung durch eine CA.	Dazu wurden Möglichkeiten zur Selbst-Beglaubigung (self-sign) geschaffen und hier vorgestellt. Man umgeht damit allerdings wesentliche Elemente dieser sicheren Technik. Es ist sinnvoll, selbst beglaubigte Schlüssel im eigenen lokalen Netzwerk zu verwenden, aber man sollte die Grenzen kennen.
Aktuelle Zeit Jeder SSL-Schlüssel hat eine begrente Gültigkeit, die normalerweise als ganze Zahl in Tagen angegeben wird. Typische Werte sind 365 (1 Jahr), 999, 3650 (10 Jahre) oder 9999	Ein SSL-Programm versucht, bei Herstellung eines SchlÜssels einen vertrauenswürdigen → NTP-ZeitServer zu erreichen. Das ist nur möglich, wenn der verwendete PC während dieser Arbeit mit dem Internet verbunden ist. ♣ Versuchen sie besser nicht, auf ihrem PC ein anderes Datum vorzutäuschen.
Eigener Webserver Die Hinweise dieser Seite gelten ausnahmslos für eigene Webserver im lokalen Netzwerk (LAN) bzw. für experimentelle Webserver. ♣ Zur Ausbildung und zum Ausprobieren sind → Virtuelle Computer am besten geeignet. Probieren sie die HTTPS-Technik zuerst an einem virtuellen PC, den sie mit dem gleichen Betriebssystem und mit der gleichen Webserver-Version einrichten, die sie in ihrem realen LAN verwenden ! Insbesondere wird auf die kostenpflichtige Dienstleistung einer Certificate Authority (CA) verzichtet, und die Schlüssel werden selbst signiert (self-signed). Mit kleinen Einschränkungen kann man so die HTTPS-Technik im eigenen Netzwerk ausprobieren. Die Sicherheit wird damit allerdings nur wenig erhöht, allenfalls nur das unbefugte Abhören anderer LAN-TeilnehmerInnen erschwert.	Die Praxis zeigt, dass die Konfiguration des Webservers für SSL als relativ komplex empfunden wird. Sie sollten daher einige Erfahrung mit Webservern (insbesondere mit → virtuellen Webservern) haben, bevor sie einen virtuellen SSL-Server einrichten. Insbesondere sollten sie mit einem totalen Ausfall ihres bestehenden Webservers rechnen und in Kauf nehmen, diesen im schlimmsten Fall komplett neu einzurichten. Wenn man zum Experimentieren einen virtuellen PC verwendet, dann fällt dieses Problem weg: Der virtuelle PC wird bei Problemen einfach gelöscht und man arbeitet mit einer neuen Kopie weiter. Die Schwiergkeit liegt u.a. darin, dass die Konfiguration auf verschiedenen Betriebssystemen und mit verschiedenen Server-Versionen unterschiedlich erfolgt, und dass die meisten bereits laufenden Webserver individuell an den Bedarf eines bestimmten LAN angepasst sind. Es gibt daher kaum allgemein gültige Rezepte, und man muss die Aufgabe verstehen, um die Anweisungen sinnvoll auf das eigene System anzuwenden.
Professionelle Anwendung Wenn sie im Internet sichere Kommunikation mit HTTPS anbieten wollen, dann gelten wesentlich höhere Anforderungen bzw. strengere Regeln als hier vorgestellt.	Die Konfiguration erfordert professionelles Wissen und so viel Erfahrung wie möglich. Insbesondere sollten sie nicht versuchen, illegale (selbst signierte) Schlüssel im globalen Internet zu verwenden.

Voraussetzungen
Administrator (root) Für alle hier vorgestellten Arbeiten brauchen sie Administrator-Rechte. Melden sie sich als Administrator an. Auf Linux können sie alle Arbeiten an einer Shell-Konsole ausführen, und zwar mit einem SSH-Client-Programm auch mittels Fernsteuerung (z.B. PuTTY). In diesem Fall können sie sich als beliebiger User (der sudoer-Gruppe) anmelden und mit Anweisung su temporär als Administrator root arbeiten.	OpenSSL An ihrem PC muss ein SSL Programm-Paket installiert sein. Auf dieser Seite wird das ausgezeichnete kostenfreie Programm OpenSSL verwendet. • Auf Linux laden sie das Programm-Paket OpenSSL. Verwenden sie die Software-Verwaltung des Systems, z.B. Synaptic, YAST, apt, aptitude, zypper ... • Auf Windows verwenden sie die SSL-Version des Apache Webservers, in welche eine Mini-Version von OpenSSL integriert ist, z.B. httpd--win32-x86-openssl-.msi
Webserver Auf ihrem Server-PC sollte bereits ein Webserver installiert sein und problemlos (!) laufen. Auf dieser Seite werden nur Beispiele mit dem meist-verwendeten → Apache Webserver vorgestellt. Wenn sie noch keine Erfahrung mit der Installation und Konfiguration eines Webservers haben, dann wird dringend empfohlen, diese Aufgabe vorher zu erledigen. Versuchen sie frühestens nach einigen Tagen oder Wochen des problemlosen Betriebs mit dem normalen HTTP-Protokoll, den Webserver zusätzlich für SSL einzurichten. Insbesondere sind auch Erfahrungen mit einem oder mehreren → virtuellen Webservern nützlich. Sicherung auf Linux Erzeugen sie am besten eine Sicherungs-Kopie der gesamten Webserver Konfiguration. Diese kann sich je nach System an unterschiedlichen Pfaden befinden, z.B. # cp /etc/apache2 /etc/apache2_backup	Apache-Upgrade auf Windows Wenn bereits ein Apache Webserver ohne SSL installiert ist, dann können sie ihn unter Beibehaltung der Konfiguration austauschen: Stoppen sie den Webserver, z.B. mit dem Apache-Tray-Programm oder mit services.msc Starten sie den Installer httpd--win32-x86-openssl-.msi und verwenden sie die Option, den Server zu de-installieren. Starten sie danach nochmals den gleichen Installer und installieren sie die SSL-Version. Sicherung auf Windows Man kopiert am einfachsten das gesamte Apache-Verzeichnis, z.B. C:\> copy "C:\Programme\Apache Software Foundation\Apache2.2" "C:\Programme\Apache Software Foundation\Apache-Backup" oder (sparsamer) lediglich das UnterVerzeichnis config Auf Windows sind noch einige weitere Arbeiten zur ↓ Vorbereitung der Arbeits-Umgebung sinnvoll.
Vorbereiteter Text Während der Installation der SSL-Schlüssel werden vom Programm (OpenSSL) einige Fragen gestellt. Bereiten sie die Antworten vor: Man kann sich dann wesentlich besser auf die Arbeit konzentrieren. Speichern sie die Antworten in einer Datei oder drucken sie den Text aus. Sie müssen anschließend 2 verschiedene Organisationen beschreiben und daher 2 verschiedene Versionen des rechts vorgestellten Antwort-Musters vorbereiten: • Die Certificate Authority (CA) ist jenes Dienstleistungs-Unternehmen, welches ihren Schlüssel beglaubigen soll. Die CA hat einen Sitz, einen Namen und einen Domain-Namen. Verwenden sie zwar frei erfundene, jedoch halbwegs sinnvolle Daten, die nach ihrem bestem Wissen nicht real vorkommen. überlegen sie auch ein beliebiges Passwort (Passphrase) mit mindestens 4 Zeichen. Keiner der Antwort-Texte sollte Sonderzeichen (ÄÖÜäöüß€...) enthalten ! • Ihre eigene Organisation hat ebenfalls Sitz, Namen und - vor allem - einen eindeutigen Domain-Namen. Auch dafür brauchen sie eine Passphrase. Die Antwort-Daten und die Passphrases der beiden Muster müssen sich unterscheiden, d.h. man darf nicht die gleichen Antwort-Daten für CA und die eigene Organisation (den eigenen Server) verwenden.	Typischer Dialog: Country Name (2 letter code) [US]:AT State or Province Name (full name) [Some-State]:Wien Locality Name (eg, city) [Newbury]:Wien Organization Name (eg, company) [My Company]:MeinLAN Organizational Unit Name (eg, section) []: Common Name (eg, your server's hostname) []:mein.lan.at Email Address []:boss@mein.lan.at A challenge password []: An optional company name []: Die (hier als Muster blau eingetragenen) Antwort-Daten sollten keine Sonderzeichen enthalten und der realen Situation nahekommen. Wenn eine Antwort nicht sinnvoll ist, darf das Feld leer bleiben. Tragen sie keine schlechten Scherze ein: Diese Daten könnten unabsichtlich ins Internet gelangen ! Die Angabe des Common Name ist kritisch: Es muss sich um einen (theoretisch) möglichen 'voll qualifizierten' Domain-Namen handeln. Verwenden sie keinesfall den Namen einer existierenden Domain: Es kann zu Problemen kommen, wenn sie später diese Domain besuchen wollen. Bereiten sie zusätzlich je eine Passphrase mit mindestens 4 Zeichen ohne Sonderzeichen vor, z.B. Passphrase: geheim Die Passphrase für die CA und für den eigenen Server müssen sich unterscheiden !
Schlüssel-Pfade Informieren sie sich vor Beginn der SSL-Installation, in welchen Pfaden ihr System / Webserver die hergestellten Schlüssel-Dateien erwartet. Die Tipps dieser Seite sind nur ein unverbindlicher Hinweis ! In der Dokumentation ihrer installierten Software und / oder im Internet finden sie dazu Informationen. Sehen sie nach, ob die angegebenen Pfade auf ihrem Server-PC existieren, und ob sich darin evtl. bereits (gleichnamige) Dateien befinden.	Arbeits-Verzeichnis Überlegen sie, in welchem Verzeichnis (Ordner) sie die folgenden Arbeiten ausführen werden. ● Auf Linux kann man den Pfad meist frei wählen oder erzeugen, z.B. /home/ich/ssl ♣ Erzeugen sie dafür am besten ein neues Verzeichnis, das keine anderen Dateien enthält. ● Auf Windows muss man sich notgedrungen an jenen Pfad halten, in dem sich openssl.exe befindet, z.B. C:\Programme\Apache...\bin\openssl.exe

CA-Schlüssel auf Linux
Man richtet sich zunächst selbst als Certificate Authority (CA) ein, damit man die Schlüssel anderer Organisationen (= des eigenen Servers) beglaubigen kann. Man findet auch Beschreibungen, die ohne diesen Schritt auskommen. Hier wird nicht diskutiert, ob das sinnvoll ist. Je nach System werden auch Werkzeuge angeboten, die bei der SSL-Installation helfen sollen (z.B. YAST2 CA-Management). Die Erfahrungen sind nicht besonders gut (u.a. gibt es deshalb diese Webseite).	Öffnen sie eine Shell-Konsole und melden sie sich als Linux-Administrator root an. Navigieren sie zum vorbereiteten Arbeits-Verzeichnis, z.B. # cd /home/ich/ssl Bereiten sie die Antworten und die Passphrase für die CA vor.
Erzeugung des CA-Schlüssels (Create a key for the Certificate Authority) # openssl genrsa -des3 -out ca.key 4096 An Stelle von der Zahl 4096 kann man auch 2048 oder 1024 zur Erzeugung schwächerer Schlüssel angeben.	Die Anweisung verlangt die 2malige Eingabe der CA-Passphrase und erzeugt im Arbeits-Verzeichnis eine Text-Datei ca.key von ca. 3.2kB mit diesem Inhalt: -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY-----
Erzeugung des CA-Zertifikats (Make the CA certificate) # openssl req -new -x509 -days 9999 -key ca.key -out ca.crt Ändern sie die Geltungs-Dauer in Tagen (hier 9999). Verwenden sie die vorbereiteten CA-Antworten zur Eingabe.	Die Anweisung erzeugt eine Text-Datei ca.crt von ca. 2kB mit diesem Text: -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE-----
Mit Hilfe der CA-Dateien kann man nun die Schlüssel beliebig vieler 'KundInnen' beglaubigen. Da die CA jedoch nur erfunden ist, bemerkt jeder Browser sofort den Schwindel. ● Im eigenen LAN ist das kein Problem, und man kann mit jedem Browser eine Ausnahme eintragen. ● Sie sollten damit jedoch keinesfalls öffentlich (im globalen Internet) zugängliche Schlüssel erzeugen: Die Reaktion ist nicht vorhersagbar, wird jedoch als Versuch einer Täuschung interpretiert. Besonders unangenehm und teuer kann es werden, wenn sie versucht haben, mit den eingetragenen Antworten eine real existierende CA nachzuahmen.	Die typische Anwendung ist die einmalige Bestätigung des eigenen Servers, wie im nächsten Kapitel vorgestellt. Prinzipiell kann man die beiden Schlüssel-Dateien auf jeden anderen PC transportieren und (mit Kenntnis der CA-Passphrase) zur Zertifizierung von Schlüsseln verwenden. Sie sollten die CA-Dateien jedoch entweder sicher verwahren oder nach Gebrauch vernichten, damit keine Unbefugten in ihre eingetragenen Antwort-Daten für unsaubere Zwecke verwenden können.

Eigener Server-Schlüssel auf Linux
Wenn man die CA-Schlüssel erzeugt und beglaubigt hat, kann man damit beliebige andere Schlüssel zertifizieren, z.B. einen Schlüssel für den eigenen Server, so wie in diesem Kapitel beschrieben.	Auf Linux setzen sie einfach die im vorigen Kapitel beschriebene Arbeit mit der Shell-Konsole im gleichen Verzeichnis fort. Bereiten sie die Antworten für den eigenen Server sowie die Passphrases für die CA und für den eigenen Server vor.
Erzeugung des eigenen Server-Schlüssels (Create a private key) # openssl genrsa -des3 -out server.key 4096 An Stelle von der Zahl 4096 kann man auch 2048 oder 1024 zur Erzeugung schwächerer Schlüssel angeben. Der erzeugte Schlüssel (Datei server.key) ist mit sehr großer Wahrscheinlichkeit weltweit eindeutig, jedoch nirgends registriert.	Die Anweisung verlangt die 2malige Eingabe der Server-Passphrase und erzeugt im Arbeits-Verzeichnis eine Text-Datei server.key von ca. 3.2kB mit diesem Inhalt: -----BEGIN RSA PRIVATE KEY----- ... -----END RSA PRIVATE KEY-----
Erzeugung eines Zertifizierungs-Ansuchens (Certificate Signing Request, CSR) # openssl req -new -key server.key -out server.csr Das Ansuchen (die erzeugte Text-Datei server.csr) enthält den eigenen Schlüssel (server.key) und die Angaben zur eigenen Organisation (wie vorbereitet). Zur kommerziellen Anwendung sendet man dieses Ansuchen zur Beglaubigung (Zertifizierung) an eine offizielle CA-Organisation. Zum eigenen Gebrauch kann man den Schlüssel selbst zertifizieren (nächster Absatz).	Die Anweisung verlangt die Eingabe der vorbereiteten Server-Antwort-Daten und erzeugt eine Text-Datei server.csr von ca. 2kB mit diesem Text: -----BEGIN CERTIFICATE REQUEST----- ... -----END CERTIFICATE REQUEST-----
Beglaubigung, Herstellung des Server-Zertifikats (Sign the Certificate) Die Beglaubigung (Autorisierung, Zertifizierung) des eigenen privaten Schlüssels erfolgt durch die (selbst erfundene) CA. # openssl x509 -req -days 9999 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt Eine reale Certificate Aurthority (CA) prüft die im Ansuchen enthaltenen Daten des Antragstellers und beglaubigt dessen Schlüssel, wenn die Angaben korrekt sind. Danach ist der Schlüssel nicht nur eindeutig, sondern weltweit registriert: Jeder Browser kann einen Webserver mit Hilfe des Schlüssels sehr rasch identifizieren. Erst dann, wenn dieser Test absolviert wurde, werden vertrauliche Daten verschlüsselt und übertragen.	Die Anweisung verlangt die Eingabe der CA-(!)-Passphrase und erzeugt als Zertifikat eine Text-Datei server.crt von ca. 2kB mit diesem Text: -----BEGIN ----- ... -----END ----- Im Falle der eigenen (selbst erfundenen) CA entfällt die Prüfung und man beglaubigt das eigene Ansuchen unmittelbar.
Der Server-Schlüssel server.key, das Ansuchen server.csr und das Zertifikat server.sct sind in dieser Form bereits für einen SSL-Webserver verwendbar. Der Server fragt allerdings bei jedem Start nach der Passphrase.	Das ist unbrauchbar, weil viele Server unbeaufsichtigt und unzugänglich arbeiten. Deshalb wird in einem weiteren Schritt aus dem Server-Schlüssel server.key eine Variante ohne Passphrase erzeugt.
Herstellung einer Schlüssel-Variante ohne Passphrase (Remove Passphrase from Key) # openssl rsa -in server.key -out server.key.insecure # mv server.key server.key.secure # mv server.key.insecure server.key Damit wird eine aus dem Server-Schlüssel server.key eine Variante mit den gleichen Daten, jedoch ohne Passphrase erzeugt Danach werden die Namen der beiden Versionen geändert. Dazu wird nicht rename sondern mv (move) verwendet, weil die von Windows abweichende Syntax zu Verwechslungen führen kann.	Die Anweisungen erzeugen eine 'unsichere' Schlüssel Variante und ändern die Namen der beiden Versionen. Nach Abschluss erhält man diese beiden Schlüssel-Dateien: server.key - Ohne Passphrase, wird (nur) für den SSL-Server verwendet. server.key.secure - Mit Passphrase, wird aufbewahrt.
Zugangs-Rechte Auf Linux werden die Zugangs-Rechte streng verwaltet. Weisen sie den server.* Dateien den User root und die Gruppe root zu und vergeben sie restriktive Zugangsrechte: # chusr root server.* # chgrp root server.* # chmod 0600 server.* Kontrolle mit # ls -l Man kann die server.* Dateien umbenennen, wenn z.B. schon andere Schlüssel dieses Namens in Gebrauch sind. Alle 3 Dateien sollten jedoch (abgesehen von der Erweiterung) gleich benannt sein, z.B. firma.*	Verwendung Zur Konfiguration des SSL-Webservers verwendet man Kopien (!) dieser Dateien: server.key, server.csr, server.crt Je nach System und Server werden sie in jenes Verzeichnis kopiert, wo sie vom Server erwartet werden. Sie werden vom Server zunächst ignoriert und erst dann verwendet, wenn das in der ↓ Server-Konfiguration festgelegt wurde. Archiv Die erzeugten Dateien ca., server. und die Text-Datei mit den verwendeten Passphrases und Antwort-Daten werden am besten temporär archiviert. Wenn der SSL-Server funktioniert, kann man das Archiv löschen (sicherer) oder für eine Wiederholung der Arbeiten aufbewahren (bequemer).

Windows Vorbereitung
Die oben angegebenen Tipps zu ↑ allgemeinen Vorbereitungen gelten für alle Betriebssysteme - auch für Windows.	Zusätzlich sollte man auf Windows einige empfehlenswerte Arbeiten ausführen. Sie wirken sich auf SSL aber auch auf viele andere Programme positiv aus.
Anzeige versteckter Daten Windows Systeme neigen dazu, viele wichtige Informationen zu verstecken. So machen sie zumindest die meisten Dateien sichtbar: Menü Extras \| Ordneroptionen \| Ansicht Die Verwirrung ist besonders groß, weil die Optionen in umgekehrter Logik miteinander vermischt werden: ► Kreuzen sie alle Optionen an, mit denen Daten angezeigt werden, z.B. Inhalte von Systemordnern anzeigen ► Entfernen sie das Kreuz von allen Optionen, die irgend etwas verstecken, z.B. Erweiterungen bei bekannten Dateitypen ausblenden ► Klicken sie zuletzt den Button Für alle übernehmen. Damit sehen sie immerhin die meisten Dateien und ihre (für die System-Verwaltung unentbehrlichen) Endungen.	Die (u.a.) für SSL wichtige Datei openssl.cnf wird trotzdem ohne Endung angezeigt. Aus einem unbekannten Grund müssen normale Windows-AnwenderInnen vor dem Anblick dieser 3 Buchstaben besonders geschützt werden. Um auch diesen Unsinn abzustellen, verwenden sie Menü Extras \| Ordneroptionen \| Dateitypen Suchen und markieren sie CNF (Zielwahl) Klicken sie den Button Erweitert und markieren sie das Kästchen Erweiterung immer anzeigen
Dateien und Pfade Diese Dateien sollten sich an ihrem Server-PC befinden, wenn eine Version des Apache Webservers mit SSL-Option installiert wurde: C:\Programme\Apache...\bin\openssl.exe C:\Programme\Apache...\modules\mod_ssl.so C:\Programme\Apache...\conf\openssl.cnf C:\Programme\Apache...\conf\extra\httpd-ssl.conf	Die Pfade sind teilweise von System und Apache-Version abhängig. Es ist lediglich wichtig, dass man diese Dateien findet und die Pfade kennt.
Umgebungs-(System)-Variable Jedes Betriebssystem verwaltet einige wichtige Daten, die allen Programmen zur Verfügung gestellt werden. Jedes Programm kann diese Daten lesen und sich damit im System und im Netzwerk zurechtfinden. Viele wichtigen Daten werden auf Windows jedoch in der Registry-Datenbank verwaltet und sind nur mit speziellen Methoden zugänglich. Es ist daher sinnvoll (und manchmal notwendig), mindestens jene Umgebungs-Variablen auch auf Windows einzurichten, die von Standard-Programmen erwartet werden: ► Menü (Arbeitsplatz) Systemsteuerung \| System \| Erweitert \| Umgebungsvariablen \| Systemvariablen. (Nur im unteren Teil des Fensters !). Hier finden sie die Liste der Variablen und deren aktuelle Werte. Das Programm-Fenster ist winzig und die Arbeit damit nicht einfach. Das dient vermutlich zur Abschreckung. ► Tragen sie hier die empfohlenen Variablen ein. (Nur) auf Windows ist es gleichgültig, ob man für ihre Namen Groß- oder Kleinbuchstaben verwendet. ► Nach allen Änderungen sollten sie das System neu starten und kontrollieren. Öffnen sie eine Konsole cmd.exe und geben sie ein: C:\> set Sie erhalten eine Liste der Umgebungs-Variablen und ihrer Werte. Damit C:\> set > c:\set.txt erhalten sie eine Text-Datei, die man bequemer ansehen kann. ♦ Details zu Windows Umgebungs-Variablen.	Router / Proxy-Server Diese Umgebungs-Variablen geben den Weg ins Internet an. Die Daten enthalten Protokoll, IP-Adresse und Port des → Routers / Proxy-Servers, z.B. HTTP_PROXY=http://192.168.0.1:8080 HTTPS_PROXY=http://192.168.0.1:8080 FTP_PROXY=http://192.168.0.1:8080 NO_PROXY=http://192.168.0.0/24,127.0.0.1/8,localhost Wenn ihr Router / Proxy-Server eine Anmeldung verlangt, dann definieren sie zusätzlich die Variablen PROXY_USER=UserName PROXY_PASSWD=PassWort oder eine kombinierte Variante wie z.B. HTTP_PROXY=http://UserName:PassWort@192.168.0.1:8080 Hinweis: Das Betriebsystem erhält zwar diese Daten (meist von einem → DHCP-Server). Das nützt jedoch nichts, wenn es diese Daten nicht an gestartete Programme weitergibt... Zeitzone Die Interpretation der → Windows Systemzeit wird vom Betriebssystem eher behindert, als dass z.B. die Umrechnung auf die Weltzeit UTC unterstützt wird. Viele Programme können sich helfen, wenn wenigstens diese Variable definiert ist: TZ=Europe/Berlin Sie finden die Angabe ihrer Zone im Internet (oder auf jedem Linux-PC), z.B. Europe/Berlin, Europe/Vienna, Europe/Zurich, ... OpenSSL Benötigt den Pfad zur Datei openssl.cnf, z.B. OPENSSL_CONF=C:\Programme\Apache...\conf\openssl.cnf System-Pfade Die Variable PATH enthält eine Liste aller Pfade, in denen ausführbare Programme (z.B. openssl.exe) gesucht werden. • Sie können an die Liste einen Strichpunkt als Trennzeichen und danach den Pfad zum OpenSSL-Programm anfügen. Wenn sie sich diese Mühe machen, dann lässt sich das Programm ebenso wie auf Linux aus jedem beliebigen Pfad starten, z.B. C:\> openssl /? • Wenn sie darauf verzichten, dann müssen sie vor der Verwendung von openssl.exe mit der Konsole in das Verzeichnis dieses Programms navigieren.

Eigener Server-Schlüssel auf Windows
Auch auf Windows kann man den Schlüssel für einen SSL-Server selbst herstellen und beglaubigen.	Das hier vorgestellte Minimal-Verfahren hat sich für einfache experimentelle Server bewährt. Als echten Netzwerk- und Webserver sollten sie aber besser einen Linux-PC einsetzen.
Konsole Starten sie eine Windows → Konsole (Eingabe-Aufforderung) cmd.exe Wenn sie die Umgebungs-Variable PATH so ergänzt haben wie in den ↑ Windows-Vorbereitungen beschrieben, dann können sie die folgenden Arbeiten in jedem beliebigen Pfad ausführen. Ideal ist ein leeres Verzeichnis (Ordner), das eigens für diesen Zweck erstellt wurde, z.B. C:\ssl	Wenn die Umgebungs-Variable PATH nicht verändert wurde, dann müssen sie mit der Konsole in das Verzeichnis des Programms openssl.exe navigieren, z.B. mit C:\> cd Programme C:\> cd "Apache..." bis zuletzt C:\> cd bin
Programm openssl.exe Geben sie die rechts gezeigten Anweisungen ein. Dieses und alle folgenden Beispiele wird nur mit dem Konsolen-Pfad C:\> angezeigt. Dieser ist wesentlich länger, wenn sie vorher ins Programm-Verzeichnis von openssl.exe navigiert haben.	Kontrolle der Programm-Version und -Funktion: C:\> openssl version C:\> openssl /?
Erzeugung eines Ansuchens C:\> openssl req -new -out server.csr Geben sie in den Dialogen die vorbereiteten Antwort-Daten ihres Servers ein.	Die Anweisung erzeugt die Text-Dateien privkey.pem (Private Key, ca. 1000 Byte) und server.csr (Certificate Request, ca. 700 Byte)
Erzeugung des privaten Server-Schlüssels C:\> openssl rsa -in privkey.pem -out server.key	Die Anweisung erzeugt die Text-Datei server.key (RSA Private Key, ca. 900 Byte)
Beglaubigung des Server-Schlüssels C:\> openssl x509 -in server.csr -out server.cert -req -signkey server.key -days 999	Die Anweisung erzeugt die Text-Datei server.cert (Certificate, ca. 900 Byte)
Abschluss Die beiden fertig gestellten Dateien werden hierher kopiert: C:\Programme\Apache...\conf\server.cert C:\Programme\Apache...\conf\server.key	Die Dateien werden vom Server zunächst ignoriert und erst dann verwendet, wenn das in der ↓ Server-Konfiguration festgelegt wurde.

Prüfung der SSL-Schlüssel
OpenSSL bietet u.a. auch Möglichkeiten, um die Gültigkeit von Schlüsseln zu prüfen und die angegebenen Daten auszugeben.	Sie können damit u.a. jene Daten kontrollieren, die jeder Client erhält, der von ihrem Server mit HTTPS Daten anfordert.
Privater Schlüssel So wird ein Schlüssel kontrolliert und seine Daten angezeigt: # openssl rsa -check -in server.key Das Ergebnis unterscheidet sich von einer Text-Ausgabe (mit Linux cat oder Windows type) durch den Text 'RSA key ok' wenn der Schlüssel in Ordnung ist. Der gleiche Test mit dem 'sicheren Schlüssel' stellt vor der Ausgabe noch die Frage nach der Passphrase: # openssl rsa -check -in server.key.secure	Zertifikat So wird ein Zertifikat angezeigt: # openssl x509 -text -noout -in server.crt Die Ausgabe enthält u.a. alle bei der Erzeugung angegebenen Daten: • Issuer = Daten der Certificate Authority (CA) • Subject = Ihre eigene Organisation (Ihr Server) • Zeitraum der Gültigkeit • Öffentlicher Schlüssel ihres Servers.
Ansuchen So wird ein Ansuchen (Certificate Request) geprüft: # openssl req -text -noout -verify -in server.csr Auch in diesem Fall werden alle eingegebenen Daten angezeigt. Das ist zur Kontrolle durch die CA notwendig, aber bei Selbst-Beglaubigung nicht sinnvoll.	OpenSSL bietet darüber hinaus viele Optionen für die professionelle Anwendung. Konsultieren sie das Internet, insbesondere die Dokumentation von OpenSSL.

Apache Konfiguration
Die erforderlichen Arbeiten an der Konfiguration des Apache Webservers werden hier nur in Stichworten angegeben.	Es wird vorausgesetzt, dass sie die einzelnen Anweisungen verstehen und sinngemäß an den eigenen Server anpassen können.
SSL-Modul Der Apache Webserver muss dieses Modul beim Start laden Je nach System sind dazu unterschiedliche Maßnahmen erforderlich, z.B.: • Auf SuSE-Linux: Suchen sie diese Text-Datei, erzeugen sie eine Sicherungs-Kopie und öffnen sie die Datei mit einem Text-Editor: /etc/sysconfig/apache2 Die Variable APACHE_MODULES enthält eine mit Leerzeichen getrennte Liste der zu ladenden Module. Fügen sie ssl ein, z.B. APACHE_MODULES="actions ... ssl status ... " Die Variable APACHE_SERVER_FLAGS muss SSL enthalten, z.B. APACHE_SERVER_FLAGS="SSL STATUS" Durch diese Maßnahme werden die entsprechenden LoadModule-Anweisungen automatisch erzeugt.	Auf Windows suchen sie die Konfiguration der Module, z.B. in der Datei /conf Aktivieren sie diese Zeile LoadModule ssl_module modules/mod_ssl.so z.B. durch Entfernen des führenden Kommentar-Zeichens. In jedem anderen Fall müssen sie durch geeignete Maßnahmen für das SSL-Modul sorgen. ♣ Tipp: Lassen sie (mindestens temporär) auch das Info-Modul laden. Dann erhalten sie mit dieser Anforderung u.a. eine Liste aller wirklich geladenen Module: http://localhost/server-info
Standard SSL-Konfiguration Fast jede Apache+SSL Konfiguration enthält u.a. eine Datei zur Standard-Konfiguration des SSL-Moduls, meist mit einem Namen wie ssl-global.conf Sie müssen diese Konfigurations-Datei einbinden, z.B. durch Aktivierung oder Einfügen einer Zeile Include /etc/apache2/ssl-global.conf	Noch besser ist es, nicht die Original-Datei ssl-global.conf zu verwenden, sondern eine Kopie, die man ungestraft verändern und notfalls wieder löschen kann.
Listen Sie müssen den Server anweisen, nicht nur am HTTP Standard-Port 80 sondern auch am SSL-Port 443 zu 'horchen', d.h. Aufträge entgegen zu nehmen. Das kann u.a. in einer Datei httpd.conf, default-server.conf, listen.conf, ... erfolgen.	Anweisung: Listen 443 Diese Anweisung ist evtl. in einen oder mehrere <IfModule mod_ssl.*> ... </IfModule> bedingte Anweisungs-Blöcke eingeschlossen oder auf eine von mehreren IP-Adressen beschränkt, z.B. Listen 192.168.0.1:443
NameVirtualHost Die beiden Webserver für HTTP (Port 80) und HTTPS (Port 443) werden parallel betrieben. Dazu wird je 1 eigener → virtueller Webserver deklariert und konfiguriert. Virtuelle Server bieten eine sehr große Vielfalt an möglichen Optionen.	So werden (mindestens) die beiden angegebenen virtuellen Server deklariert: NameVirtualHost :80 NameVirtualHost :443 Aktivieren sie diese Anweisungen, wenn vorhanden (oft in der Datei listen.conf), oder fügen sie die beiden Zeilen ein.
<VirtualHost :80>... </VirtualHost> Wenn ein virtueller Server :80 (am Standard HTTP-Port 80) deklariert wurde, dann muss die weitere Konfiguration einen derartigen Block enthalten. Innerhalb des Blocks sind alle Anweisuntgen enthalten, um diesen virtuellen HTTP-Server zu konfigurieren. Die allgemeinen Anweisungen (z.B. aus den Dateien httpd.conf, global-server.conf, etc.) werden dadurch überschrieben.	Die Apache Server enthält meist ein Verzeichnis vhosts.d, in dem sich Muster-Dateien zur Konfiguration virtueller Server befinden, z.B. vhost.template Am einfachsten kopieren sie ein Muster und ändern den datei-Namen, z.B. auf /etc/apache2/vhosts.d/vhost_80.conf Meist genügt es, die allgemeinen Anweisungen des bisherigen HTTP-Servers in diesen Block einzutragen: Der virtuelle Server verhält sich dann (ununterscheidbar) genauso wie vorher der einfache HTTP-Server.
<VirtualHost :443>... </VirtualHost> Wenn ein virtueller Server :443 (am Standard HTTPS-Port 443) deklariert wurde, dann muss die weitere Konfiguration einen derartigen Block enthalten. Innerhalb des Blocks sind alle Anweisuntgen enthalten, um diesen virtuellen HTTPS-Server zu konfigurieren. Am einfachsten kopieren sie ein SSL-Muster vhost-ssl.template und ändern den Datei-Namen, z.B. auf /etc/apache2/vhosts.d/vhost_443.conf	Sie können in diesen Block die gleichen Konfigurations-Anweisungen eintragen wie im Block *:80 - Der SSL-Server zeigt dann die gleichen Dateien an, allerdings nach verschlüsseltem Transport. Wenn sie bei sonst identischer Konfiguration lediglich dei Variable DocumentRoot ändern, dann zeigt der SSL-Server andere Dateien (Webseiten), und zwar jene, die sich im angegebenen DocumentRoot Verzeichnis befinden.
Neustart Änderungen der Apache Konfiguration treten erst (nur) nach einem Neustart auf, z.B. auf Linux # /etc/init.d/apache2 restart	Wenn der Server nicht so arbeitet wie erwartet, dann kehren sie zur letzten gut funktionierenden Version zurück und starten sie erneut. Ändern sie danach so wenig wie möglich, z.B. nur eine einzige Anweisung und testen sie jeweils nach Neustart.
Log Der Apache Webserver führt - wie die meisten anderen Server-Programme - ein Log. Bei Problemen ist das Fehler-Log besonders aufschlussreich. Dieses Log wird sogar dann geführt, wenn der Server nicht einmal starten kann. Die Log-Dateien befinden sich meistens hier (Linux, Windows): /var/log/apache2 C:\Programme\Apache...\ ♣ Tipp: Erstellen sie durch beide virtuelle Server getrennte Log-Dateien. Das macht es einfacher, Fehler des SSL-Servers zu analysieren, wenn der Standard-Server korrekt funktioniert, was oft der Fall ist. (Beispiel rechts).	Beispiel: Jeder virtuelle Server führt ein eigenes Log <VirtualHost :80> ErrorLog /var/log/apache2/error_80.log ... </VirtualHost> <VirtualHost :443> ErrorLog /var/log/apache2/error_443.log ... </VirtualHost>

Ausgewählte Links zum Thema Apache SSL Server
Apache-Dokumentation zum SSL-Modul Univ. Minnesota / Paul Bramscher: Creating Certificate Authorities and self-signed SSL certificates Akadia: How to create a self-signed SSL Certificate Debian Administration: Creating and Using a self signed SSL Certificates in Debian OpenSuSe / Scott Morris: Creating Self-Signed SSL Certificates Ubuntu Documentation: Certificates	Wikipedia: SSL, TLS, HTTPS, Digitales Zertifikat, Self-signed certificate, Zertifizierungs-Stelle (Certificate Authority, CA), CAcert, CAcert - Stellt kostenfreie Zertifikate aus, allerdings mit reduzierter Prüfung der Identität.

Zum Inhaltsverzeichnis

> System > Server > Apache > SSL