- Caipigallery auf [1]<\/a><\/li>
- Caipiwiki auf [2]<\/a><\/li>
- GroupOffice auf [3]<\/a><\/li>
- Caipithek<\/a> auf [4]<\/a><\/li>
- MRTG<\/a> f\u00fcr die verschiedenen Grafiken auf [5]<\/a>, [6]<\/a>, [7]<\/a>, [8]<\/a><\/li>
- USV<\/a>-Status auf [9]<\/a><\/li><\/ul>\n\n\n\n
Pakete<\/h2>\n\n\n\n
Zum Betrieb des Apache-Webservers m\u00fcssen die folgenden Pakete auf dem Caipirinha<\/a>-Server installiert werden. Au\u00dferdem muss PHP<\/a> installiert und konfiguriert worden sein. Als Einstieg in die Konfiguration des Apache<\/strong>-Webservers ist ferner das Buch [10]<\/a> sehr empfehlenswert.\n<\/p>\n\n\n\n
- apache2<\/li>
- apache2-doc<\/li>
- apache2-mod_perl<\/li>
- apache2-mod_php5<\/li>
- apache2-prefork<\/li>
- apache2-utils<\/li>
- susehelp<\/li>
- susehelp_de<\/li>
- susehelp_en<\/li><\/ul>\n\n\n\n
Basis-Setup<\/h2>\n\n\n\n
Um Apache auf die eigenen Anforderungen anzupassen, erstellen wir zun\u00e4chst eine Konfigurationsdatei, die dann zus\u00e4tzlich zu den bereits existierenden Konfigurationsdateien beim Start des Apache-Servers abgearbeitet wird:\n<\/p>\n\n\n\n
\/etc\/apache2\/httpd.conf.local<\/strong>:\n<\/p>\n\n\n\n
#\n# Additional Configuration for the Apache Web server on CAIPIRINHA\n#\n# Gabriel R\u00fceck, 24.10.2010\n\nAddDefaultCharset UTF-8\nDirectoryIndex index.shtml\n\n# Additional Handler Declarations\nAddHandler imap-file map\n\nSSLCipherSuite HIGH\n\n# Verzeichnisse freigeben au\u00dferhalb des DocumentRoot\nAlias \/kde-icons \/opt\/kde3\/share\/icons\/crystalsvg\/48x48\/mimetypes\nAlias \/gnome-icons \/usr\/share\/icons\/gnome\/32x32\nAlias \/dav \/home\/public\/Dropbox\n\n# Umleitungen auf die neu angemietete Domain rueeck.name\nRedirect permanent \/coppermine http:\/\/rueeck.name\/coppermine\n#Redirect \/mediawiki http:\/\/rueeck.name\/mediawiki\nRedirect permanent \/lx-erp https:\/\/rueeck.name\/lx-erp\nRedirect permanent \/phpPgAdmin https:\/\/rueeck.name\/phpPgAdmin\nRedirect permanent \/groupoffice https:\/\/rueeck.name\/groupoffice\n\n# KDE ICONS (needed for update_rss.sh)\n<Location \/kde-icons>\n Allow from all\n<\/Location>\n\n# GNOME ICONS (needed for caipithek.php)\n<Location \/gnome-icons>\n Allow from all\n<\/Location>\n\n# MULTIMEDIA-VERZEICHNIS\n<Directory \/srv\/www\/htdocs\/MM>\n SSLRequireSSL\n AuthName \"Secure Access on CAIPIRINHA\"\n AuthType Digest\n AuthUserFile \/srv\/www\/htdocs\/MM\/.htpasswd\n Require valid-user\n Options Indexes FollowSymLinks\n IndexOptions +IgnoreCase +FoldersFirst +VersionSort +Charset=UTF-8\n<\/Directory>\n\n# DIGITAL DROPBOX\n<Directory \/srv\/www\/htdocs\/Dropbox>\n AuthName \"Digital Dropbox on caipirinha\"\n AuthType Digest\n AuthUserFile \/home\/public\/Dropbox\/.htpasswd\n Require valid-user\n<\/Directory>\n\n# WEBALIZER\n<Directory \/srv\/www\/htdocs\/webalizer>\n AuthName \"Secure Access on CAIPIRINHA\"\n AuthType Digest\n AuthUserFile \/srv\/www\/htdocs\/MM\/.htpasswd\n Require valid-user\n<\/Directory>\n\n# LX-OFFICE\n<Directory \/srv\/www\/htdocs\/lx-office-erp>\n SSLRequireSSL\n<\/Directory>\n\n<Directory \/srv\/www\/htdocs\/lx-erp>\n SSLRequireSSL\n Options ExecCGI Includes FollowSymlinks\n<\/Directory>\n\n<Directory \/srv\/www\/htdocs\/lx-erp\/users>\n Deny from all\n<\/Directory>\n\n<Directory \/srv\/www\/htdocs\/phpPgAdmin>\n SSLRequireSSL\n<\/Directory>\n\n# WEBDAV WEBFOLDERS\n# Speicherort f\u00fcr Lock-Datenbank\nDAVLockDB \/var\/lock\/dav\/lock\nDavDepthInfinity off\n\n<Location \/dav>\n Allow from all\n Dav on\n ForceType text\/plain\n AuthType Digest\n AuthName \"Secure Access on CAIPIRINHA\"\n AuthUserFile \/srv\/www\/htdocs\/MM\/.htpasswd\n <LimitExcept OPTIONS>\n Require valid-user\n <\/LimitExcept>\n Options Indexes\n IndexOptions +IgnoreCase +FoldersFirst +VersionSort +Charset=UTF-8\n SSLRequireSSL\n<\/Location><\/pre>\n\n\n\n
Gehen wir diese Konfiguration einmal Schritt f\u00fcr Schritt durch:\n<\/p>\n\n\n\n
- Mit AddDefaultCharset<\/strong> wird UTF-8<\/strong> als \nStandard-Zeichensatz des Webservers eingestellt. Dadurch k\u00f6nnen auch \nTexte in nicht-lateinischen Buchstaben problemlos dargestellt werden. \nHeutzutage macht wegen der zunehmenden Internationalisierung eigentlich \nauch keine andere Einstellung mehr Sinn.<\/li>
- Mit DirectoryIndex<\/strong> legt man fest, dass Webseiten mit Namen index.shtml<\/strong>\n ebenfalls als Index-Seiten (also so wie index.html) betrachtet werden. \nManche Entwicklungswerkzeuge f\u00fcr Webseiten nehmen die Endung shtml<\/strong> f\u00fcr Webseiten, welche Server Side Includes (SSI)<\/a> enthalten.<\/li>
- In der Zeile mit der Direktive AddHandler<\/strong> wird nun ein Handler f\u00fcr Image Maps<\/a> benannt.<\/li>
- Die folgende Direktive SSLCipherSuite<\/strong> fordert den Einsatz von Triple-DES-Verschl\u00fcsselung<\/a> beim Aufruf verschl\u00fcsselter Webseiten (https<\/strong>) und verbietet den Einsatz schw\u00e4cherer Verschl\u00fcsselungsalgorithmen.<\/li>
- Nun werden Alias-Pfade f\u00fcr einige Verzeichnisse au\u00dferhalb des DocumentRoot<\/strong> festgelegt. Damit erreicht man quasi eine “Umleitung” des Zugriffs. So wird beispielsweise beim Aufruf der Seite http:\/\/caipirinha.homelinux.org\/dav<\/a><\/strong> nicht etwa in das Verzeichnis \/srv\/www\/htdocs\/dav<\/strong> verzweigt, wie dies normalerweise der Fall w\u00e4re, sondern der Webserver sieht stattdessen in \/home\/public\/Dropbox<\/strong> nach. Mit dieser Methode kann man beliebige Verzeichnisse einbinden, ohne dass sich alles unterhalb des DocumentRoot<\/strong> (\/srv\/www\/htdocs<\/strong>) befinden muss.<\/li>
- Nun folgen einige Umleitungen f\u00fcr Webseiten, die vormals auf dem Caipirinha<\/a>-Server gehostet wurden und die jetzt auf die Maschine rueeck.name<\/a> verschoben worden sind. Damit Zugriffe auf diese vormals auf dem Caipirinha<\/a>-Server existierenden Seiten nicht ins Leere gehen, werden sie automatisch umgeleitet.<\/li>
- Die folgenden beiden Location<\/strong>-Direktiven haben als einzigen Zweck das Zulassen des Zugriffs f\u00fcr alle Clients auf die Web-Verzeichnisse:\n
- http:\/\/caipirinha.homelinux.org\/kde-icons<\/a><\/li>
- http:\/\/caipirinha.homelinux.org\/gnome-icons<\/a><\/li><\/ul><\/li>
- Die folgende Directory<\/strong>-Direktive bezieht sich auf das Verzeichnis \/srv\/www\/htdocs\/MM<\/strong> (erreichbar \u00fcber https:\/\/10.130.25.50\/MM<\/a>). Dieses Verzeichnis ist erfordert zwingend eine verschl\u00fcsselte Verbindung (https<\/strong>) und eine erfolgreiche Authentifizierung (Direktiven SSLRequireSSL<\/strong>, AuthName<\/strong>, AuthType<\/strong>, AuthUserFile<\/strong>, Require<\/strong>) mit einem g\u00fcltigen Paar aus Benutzernamen und Passwort aus der Datei \/srv\/www\/htdocs\/MM\/.htpasswd<\/strong>. Au\u00dferdem ist bei diesem Verzeichnis das Auflisten des Verzeichnis-Inhalts (Indexes<\/strong>) zul\u00e4ssig. Bei der Auflistung werden bestimmte Sortierkriterien eingehalten, die zus\u00e4tzlich (deswegen das “+”-Zeichen) zu den Default-Optionen aktiviert werden (+IgnoreCase +FoldersFirst +VersionSort<\/strong>). Au\u00dferdem wird das Listing mit dem Zeichensatz UTF-8<\/strong> durchgef\u00fchrt (+Charset=UTF-8<\/strong>).<\/li>
- Dann folgt eine Directory<\/strong>-Direktive f\u00fcr die Dropbox<\/strong>, bei der ebenfalls eine Authentifizierung, aber keine Verschl\u00fcsselung notwendig ist.<\/li>
- Eine vergleichbare Konfiguration hat die n\u00e4chste Directory<\/strong>-Direktive, welche den Zugriff auf die Webserver-Statistiken in \/srv\/www\/htdocs\/webablizer<\/strong> regelt (siehe Webalizer<\/a>).<\/li>
- Dann folgen drei Abschnitte, welche den Zugriff auf die Dateien f\u00fcr das Paket lx-office<\/strong> regeln. Dabei ist zu beachten, dass f\u00fcr das Verzeichnis \/srv\/www\/htdocs\/lx-erp<\/strong> spezifische Optionen festgelegt werden, und zwar nicht zus\u00e4tzlich zu den Default-Optionen, sondern anstatt\n der Default-Optionen. Deshalb fehlt hier das “+”-Zeichen, welches bei \nder Festlegung der Optionen in einem der vorherigen Bl\u00f6cke benutzt \nworden war. F\u00fcr den Zugriff auf lx-office<\/strong> sowie auf phpPgAdmin<\/strong> ist zwingend Verschl\u00fcsselung notwendig, weil bei der Benutzung dieser Pakete Passworte \u00fcbertragen werden m\u00fcssen.<\/li>
- Zuletzt kommen die Einstellungen f\u00fcr das WebDAV<\/strong>-Verzeichnis in \/home\/public\/Dropbox<\/strong> (erreichbar \u00fcber https:\/\/caipirinha.homelinux.org\/dav<\/a>). Eine Einf\u00fchrung in WebDAV findet sich auf [11]<\/a>, [12]<\/a>, [13]<\/a> und [14]<\/a>; die detaillierte Spec gibt es auf [15]<\/a>. Bei der Konfiguration von WebDAV sind mehrere Punkte zu beachten:\n
- Zun\u00e4chst muss eine lock<\/strong>-Datenbank eingerichtet werden, welche im Betrieb dann mehrere Dateien (in diesem Fall lock.dir<\/strong> und lock.pag<\/strong>) erzeugt. Dazu muss das Verzeichnis \/var\/lock\/dav erzeugt werden und dem Apache-Benutzer wwwrun:www<\/em> geh\u00f6ren; das macht man mit den beiden Befehlen unten.<\/li>
- Mit der Direktive DavDepthInfinity<\/strong> werden PROPFIND<\/strong>-Abfragen\n mit unendlicher Tiefe ausgeschaltet. Dies w\u00e4re bei meinem kleinen \nAnwenderkreis allerdings nicht unbedingt notwendig gewesen.<\/li>
- F\u00fcr den Zugriff auf https:\/\/caipirinha.homelinux.org\/dav<\/a> ist eine verschl\u00fcsselte Verbindung und eine Authentifizierung des Typs Digest<\/strong> notwendig. Digest<\/strong> muss deswegen gew\u00e4hlt werden, weil Windows Vista und Windows 7-Clients eine Authentifizierung mit Basic<\/strong> nicht mehr durchf\u00fchren. Beim Authentifizierungstyp Basic<\/strong> wird das Passwort nicht verschl\u00fcsselt, sondern im Base64<\/a>-Verfahren\n \u00fcbertragen und l\u00e4sst sich daher beim Mitschneiden der Verbindung \nproblemlos absch\u00f6pfen. Zwar ist dies bei einer gesicherten (https<\/strong>)-Verbindung kein gro\u00dfes Problem, aber moderne Windows-Clients fordern das eben, und die Grundidee ist ja auch richtig.<\/li>
- Die Authentifizierung wird allerdings nicht f\u00fcr die Methode OPTIONS<\/strong>\n gefordert, mit welcher ein Client eine Liste der unterst\u00fctzten \nHTTP-Methoden anfordern kann. Der Grund f\u00fcr diese Einstellung ist, dass \nich in den Log-Dateien des Servers viele Fehler gefunden habe, welche \ndaraus resultieren, dass Windows Vista- und Windows 7-Clients immer \nzun\u00e4chst ohne Authentifizierung auf den WebDAV-Server zugreifen wollen. \nEine gro\u00dfe Anzahl der Anfragen geht dabei von den Methoden OPTIONS<\/strong> und PROPFIND<\/strong> aus. PROPFIND<\/strong> hatte ich testweise ebenfalls von der Authentifizierung ausgenommen (mit der LimitExcept<\/strong>-Direktive), aber dann konnte jeder Client auch ohne Authentifizierung den Verzeichnisinhalt von \/home\/public\/Dropbox<\/strong>\n auflisten lassen. Ein Zugriff auf die Dateien war zwar nicht m\u00f6glich, \naber dennoch schien mir dies aus Gr\u00fcnden der Sicherheit problematisch zu\n sein.<\/li><\/ul><\/li><\/ul>\n\n\n\n
mkdir \/var\/lock\/dav\nchown wwwrun:www \/var\/lock\/dav<\/pre>\n\n\n\n
Die Einstellungen f\u00fcr den WebDAV-Betrieb k\u00f6nnen sicherlich verbessert\n werden, und f\u00fcr entsprechende Vorschl\u00e4ge bin ich daher dankbar.\n<\/p>\n\n\n\n
In dieser Konfigurationsdatei sind die Dateien \/srv\/www\/htdocs\/MM\/.htpasswd<\/strong> und \/home\/public\/Dropbox\/.htpasswd<\/strong>\n referenziert, welche g\u00fcltige Paare aus einem Benutzernamen und dem \ndazugeh\u00f6rigen verschl\u00fcsselten Passwort enthalten. Eine solche Datei wird\n mit dem Befehl
htdigest2<\/code> erzeugt, dessen Benutzung inman htdigest2<\/code> beschrieben ist. M\u00f6chte man beispielsweise noch einen Benutzer alfred<\/em> hinzuf\u00fcgen, so w\u00fcrde man eingeben:\n<\/p>\n\n\n\nhtdigest2 \/srv\/www\/htdocs\/MM\/.htpasswd \"Secure Access on CAIPIRINHA\" alfred<\/pre>\n\n\n\n
und bei der darauf folgenden Abfrage ein Passwort eingeben. Der Wert f\u00fcr realm<\/strong> (siehe
man htdigest2<\/code>)\n sollte gleich dem Ausdruck (hier: “Secure Access on CAIPIRINHA”) sein, \nwelcher im entsprechenden Abschnitt der Konfigurationsdatei \/etc\/apache2\/httpd.conf.local<\/strong> bei der Direktive AuthName<\/strong> eingetragen ist.\n<\/p>\n\n\n\nNun muss noch eine weitere Konfigurationsdatei angepasst werden. In der Datei \/etc\/apache2\/mod_mime-defaults.conf<\/strong> werden folgende \u00c4nderungen (Entfernen des davor stehenden “#”) vorgenommen:\n<\/p>\n\n\n\n
- Der MIME-Typ f\u00fcr *.tgz<\/strong>-Dateien wird gesetzt.<\/li>
- Der Filter f\u00fcr Server Side Includes (SSI)<\/a> wird aktiviert.<\/li><\/ul>\n\n\n\n
\/etc\/apache2\/mod_mime-defaults.conf<\/strong>: <\/p>\n\n\n\n
...\n#\n# AddType allows you to add to or override the MIME configuration\n# file mime.types for specific file types.\n#\nAddType application\/x-tar .tgz\n...\n#\n# Filters allow you to process content before it is sent to the client.\n#\n# To parse .shtml files for server-side includes (SSI):\n# (You will also need to add \"Includes\" to the \"Options\" directive.)\n#\nAddType text\/html .shtml\nAddOutputFilter INCLUDES .shtml\n...<\/pre>\n\n\n\n
Mit YaST2<\/strong> m\u00fcssen jetzt mit dem Editor f\u00fcr \/etc\/sysconfig<\/strong> noch einige Variablen richtig gesetzt werden:\n<\/p>\n\n\n\n
- Applications\u2192SuSEhelp\u2192DOC_HOST<\/strong> wird auf caipirinha.homelinux.org<\/strong> gesetzt.<\/li>
- Applications\u2192SuSEhelp\u2192DOC_ALLOW<\/strong> bleibt leer.<\/li>
- Applications\u2192SuSEhelp\u2192DOC_AUTOINDEX<\/strong> wird auf yes<\/strong> gesetzt.<\/li>
- Network\u2192WWW\u2192Apache\u2192SuSEhelp\u2192DOC_SERVER<\/strong> wird auf yes<\/strong> gesetzt.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_CONF_INCLUDE_FILES<\/strong> wird auf \/etc\/apache2\/httpd.conf.local<\/strong> gesetzt, damit unsere Konfigurationsdatei von oben \u00fcberhaupt verarbeitet wird.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_CONF_INCLUDE_DIRS<\/strong> bleibt leer.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_MODULES<\/strong> muss mindestens die Module actions\n alias auth_basic auth_digest authn_file authz_host authz_default \nauthz_user autoindex cgi charset_lite dav dav_fs dav_lock deflate dir \nenv expires imagemap include log_config mime mime_magic negotiation \nsetenvif suexec ssl userdir php5<\/strong> beinhalten.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_SERVER_FLAGS<\/strong> wird auf -D SSL<\/strong> gesetzt, um SSL zu aktivieren.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_HTTPD_CONF<\/strong> bleibt leer.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_MPM<\/strong> bleibt leer.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_SERVERADMIN<\/strong> wird auf root@caipirinha.homelinux.org<\/strong> eingestellt.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_SERVERNAME<\/strong> wird auf caipirinha.homelinux.org<\/strong> eingestellt.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_START_TIMEOUT<\/strong> wird auf 20<\/strong> gestellt.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_SERVERSIGNATURE<\/strong> wird auf on<\/strong> gesetzt.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_LOGLEVEL<\/strong> wird auf warn<\/strong> gesetzt.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_ACCESS_LOG<\/strong> wird auf \/var\/log\/apache2\/access_log combined<\/strong> gesetzt.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_USE_CANONICAL_NAMES<\/strong> wird auf off<\/strong> gesetzt.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_SERVERTOKENS<\/strong> wird auf OS<\/strong> gesetzt.<\/li>
- Network\u2192WWW\u2192Apache2\u2192APACHE_EXTENDED_STATUS<\/strong> wird auf off<\/strong> gesetzt.<\/li><\/ul>\n\n\n\n
Die hier genannten Einstellungen finden sich dann auch in den System-Dateien: <\/p>\n\n\n\n
- \/etc\/sysconfig\/susehelp<\/li>
- \/etc\/sysconfig\/apache2<\/li><\/ul>\n\n\n\n
SSL-Setup<\/h2>\n\n\n\n
![\"Problem](\"https:\/\/caipirinha.spdns.org\/wp\/wp-content\/uploads\/Zertifikat_1-1.png\")
<\/a>Problem mit dem Sicherheitszertifikat<\/figcaption><\/figure>\n\n\n\n F\u00fcr den erfolgreichen SSL-Betrieb sind noch weitere Konfigurationen erforderlich. Zun\u00e4chst muss die Datei \/etc\/apache2\/vhosts.d\/vhost-ssl.template<\/strong> in \/etc\/apache2\/vhosts.d\/vhost.conf<\/strong>\n umbenannt werden. Alternativ kann man nat\u00fcrlich eine Kopie mit diesem \nNamen erstellen. An dieser Datei braucht nichts weiter ge\u00e4ndert zu \nwerden. Diese Datei erstellt zusammen mit der oben beschriebenen Option “-D SSL<\/strong>” einen virtuellen Server, der auf Port 443<\/strong> “h\u00f6rt” und dar\u00fcber die verschl\u00fcsselte Kommunikation abwickelt.\n<\/p>\n\n\n\n
Nun muss noch ein Zertifikat f\u00fcr den SSL-Betrieb des Servers \nerstellt werden. Es ist ratsam, zun\u00e4chst eine Einf\u00fchrung zu diesem Thema\n zu lesen, beispielsweise [16]<\/a> oder [17]<\/a>. Dazu existieren im Wesentlichen drei Herangehensweisen:\n<\/p>\n\n\n\n
Einfaches Server-Zertifikat<\/h3>\n\n\n\n
![\"Zertifikatsfehler\"](\"https:\/\/caipirinha.spdns.org\/wp\/wp-content\/uploads\/Zertifikat_2.png\")
<\/a>Zertifikatsfehler<\/figcaption><\/figure>\n\n\n\n Die Vorgehensweise ist in [18]<\/a> hinreichend beschrieben. Es gen\u00fcgt eine
openssl<\/code>-Sequenz\n mit einigen Angaben zum Server, und das Schl\u00fcsselpaar wird erstellt. \nDann muss man nur noch die Rechte des \u00f6ffentlichen Zertifikats anpassen \nund die Schl\u00fcssel in die entsprechenden Verzeichnisse verschieben, \nn\u00e4mlich:\n<\/p>\n\n\n\n- server.crt<\/strong> nach \/etc\/apache2\/ssl.crt\/<\/li>
- server.key nach \/etc\/apache2\/ssl.key\/<\/li><\/ul>\n\n\n\n
caipirinha:~\/tmp # openssl req -new -x509 -nodes -out server.crt -keyout server.key\nGenerating a 1024 bit RSA private key\n........++++++\n.......................++++++\nwriting new private key to 'server.key'\n-----\nYou are about to be asked to enter information that will be incorporated\ninto your certificate request.\nWhat you are about to enter is what is called a Distinguished Name or a DN.\nThere are quite a few fields but you can leave some blank\nFor some fields there will be a default value,\nIf you enter '.', the field will be left blank.\n-----\nCountry Name (2 letter code) [AU]:DE\nState or Province Name (full name) [Some-State]:Berlin\nLocality Name (eg, city) []:Berlin\nOrganization Name (eg, company) [Internet Widgits Pty Ltd]:Gabriel R\u00fceck\nOrganizational Unit Name (eg, section) []:\nCommon Name (eg, YOUR name) []:caipirinha.homelinux.org\nEmail Address []:administrator@caipirinha.homelinux.org\ncaipirinha:~\/tmp # chmod a+r server.crt\ncaipirinha:~\/tmp # mv server.crt \/etc\/apache2\/ssl.crt\/\ncaipirinha:~\/tmp # mv server.key \/etc\/apache2\/ssl.key\/<\/pre>\n\n\n\n
Selbstsigniertes Server-Zertifikat<\/h3>\n\n\n\n
![\"Zertifikatsimport-Assistent\"](\"https:\/\/caipirinha.spdns.org\/wp\/wp-content\/uploads\/Zertifikat_5.png\")
<\/a>Zertifikatsimport-Assistent<\/figcaption><\/figure>\n\n\n\n Die Vorgehensweise ist in [https\/\/caipirinha.homelinux.org\/manual\/ssl\/ssl_faq.html#ownca] hinreichend beschrieben. Mit diesem Verfahren sagt man den Benutzern seines Servers eigentlich: “Ich habe dieses Zertifikat erzeugt, und ich beglaubige auch, dass ich es selbst erzeugt habe und dass alles so stimmt.” Dies ist nat\u00fcrlich eine gewagte Behauptung, und weil das im Prinzip jeder so machen kann, gibt es \u00fcblicherweise beim Aufruf der SSL-verschl\u00fcsselten Seite eine Fehlermeldung, so wie im Bild Problem mit dem Sicherheitszertifikat<\/strong>. Mit dieser Fehlermeldung weist der Browser darauf hin, dass keine der bekannten und vertrauensw\u00fcrdigen Beglaubigungsstellen dieses Zertifikat \u00fcberpr\u00fcft hat und dass hier etwas “faul” ist. Man kann dann zwar auf den Link “Laden dieser Webseite fortsetzen (nicht empfohlen)” klicken, und man kommt dann schlie\u00dflich zur Webseite wie im Bild Zertifikatsfehler<\/strong>. Allerdings bleibt das URL-Fenster im Browser rot hinterlegt, und wenn man auf Zertifikatsfehler<\/strong> klickt, bekommt man auch den Grund daf\u00fcr angezeigt. <\/p>\n\n\n\n
Nichtsdestotrotz ist ein selbstsigniertes Zertifikat f\u00fcr private \nServer eine n\u00fctzliche Sache, denn ein solches Zertifikat kann man \nkostenlos erstellen. Gibt es nur wenige Benutzer des eigenen Servers, \ndann kann man diesen Benutzern vielleicht sogar beibringen, das \nselbstsignierte Zertifikat dauerhaft im Browser zu installieren. Dazu \nf\u00fchrt man ausgehend vom Bild Zertifikatsfehler<\/strong> nacheinander folgende Schritte aus:\n<\/p>\n\n\n\n
- Auf “Zertifikate anzeigen” klicken.<\/li>
- Auf “Zertifikat installieren” klicken.<\/li>
- “Alle Zertifikate in folgendem Speicher speichern” ausw\u00e4hlen und als\n Speicherort “Vertrauensw\u00fcrdige Stammzertifizierungsstellen” ausw\u00e4hlen, \nso wie im Bild Zertifikatsimport-Assistent<\/strong> gezeigt.<\/li>
- Den Fingerabdruck des Zertifikats \u00fcberpr\u00fcfen (Bild Fingerabdruck des Zertifikats<\/strong>).<\/li>
- Das Einf\u00fcgen des Zertifikats durch mehrmaliges Best\u00e4tigen von “Ja” oder “OK” abschlie\u00dfen.<\/li><\/ul>\n\n\n\n
![\"Fingerabdruck](\"https:\/\/caipirinha.spdns.org\/wp\/wp-content\/uploads\/Zertifikat_6.png\")
<\/a>Fingerabdruck des Zertifikats<\/figcaption><\/figure>\n\n\n\n Woher wei\u00df man, ob der angezeigte Fingerabdruck wirklich der richtige ist? Es k\u00f6nnte sich ja um einen Man-in-the-middle-Angriff<\/a>\n handeln? Um hier sicher zu gehen, muss der Administrator des Servers \nden wahren Fingerabdruck auf sonstigen gesch\u00fctzten Wegen an seine \nBenutzer \u00fcbermitteln oder eben das Risiko eingehen, dass seine Benutzer \ndas Zertifikat installieren, ohne dass sie gr\u00fcndlich pr\u00fcfen. Man sieht \nalso schon, dass ein selbstsigniertes Zertifikat keine L\u00f6sung f\u00fcr einen \nServer mit kommerziellen Anwendungen ist.\n<\/p>\n\n\n\n
In meinem Fall betreibe ich selbst drei Server, welche auch \nSSL-Verbindungen unterst\u00fctzen. Ich habe allerdings nur ein \nRoot-Zertifikat im Rahmen der OpenVPN<\/a>-Konfiguration\n erzeugt, mit dem ich dann die jeweiligen Server-Zertifikate signiert \nhabe. Dazu habe ich aber komplett die Skripte aus dem OpenVPN<\/a>-Paket benutzt.\n<\/p>\n\n\n\n
Fremdsigniertes Server-Zertifikat<\/h3>\n\n\n\n
Ein fremdsigniertes Zertifikat ist erforderlich, wenn man seinen \nServer im SSL-Betrieb einer gr\u00f6\u00dferen Allgemeinheit zug\u00e4nglich machen \nwill und seine Benutzer nicht mit Meldungen \u00fcber Zertifikatsfehler \nabschrecken will. Dazu erzeugt man nach der in [19]<\/a> beschriebenen Vorgehensweise einen sogenannten Certificate Signing Request (CSR)<\/strong>,\n den man dann einer vertrauensw\u00fcrdigen Zertifizierungsstelle zur \nSignierung zusendet. Die Signaturstelle verlangt meistens noch mehr \nInformation, um pr\u00fcfen zu k\u00f6nnen, ob der Antragsteller auch wirklich \nexistiert und tats\u00e4chlich einen Server unter dem Namen unterh\u00e4lt, unter \ndem er den CSR<\/strong> erstellt hat. Dies ist aufw\u00e4ndig und kostet daher \nauch Geld. Die Preise sind aber unterschiedlich; ein Vergleich lohnt \nsich daher vor Abschluss eines entsprechenden Vertrags. Mit einem \nfremdsignierten Server-Zertifikat gibt es dann idealerweise keine \nProbleme mehr beim Aufrufen der SSL-gesch\u00fctzten Seite durch den \nBenutzer.\n<\/p>\n\n\n\n
Virtueller Server<\/h2>\n\n\n\n
Man kann auf einer Maschine auch mehrere, voneinander unabh\u00e4ngige Webangebote hosten, und das mit einem\n Apache-Server. Das nennt sich “virtuelles Hosting”. Webhoster nutzen \nbeispielsweise dieses Prinzip, um vielen Kunden eine eigene Domain \nanzubieten, wobei meist ganz viele Domains auf eine IP-Adresse \nabgebildet werden. Diese Webseiten liegen dann oft auch auf einer \nleistungsf\u00e4higen Maschine. Das schont Ressourcen und spart Geld, denn \nf\u00fcr eine private Webseite braucht man nicht unbedingt einen eigenen \nRoot- Server. Man unterscheidet dabei zwischen IP-basiertem virtuellem Hosting<\/strong> und namensbasiertem virtuellem Hosting<\/strong> [20]<\/a>. Das folgende Beispiel beschreibt das namensbasierte virtuelle Hosting [21]<\/a>, welches auf dem Caipiroska-Server<\/a> verwirklicht wurde. Dort gibt es folgende Domains:\n<\/p>\n\n\n\n
- Den Fingerabdruck des Zertifikats \u00fcberpr\u00fcfen (Bild Fingerabdruck des Zertifikats<\/strong>).<\/li>
- server.key nach \/etc\/apache2\/ssl.key\/<\/li><\/ul>\n\n\n\n
- server.crt<\/strong> nach \/etc\/apache2\/ssl.crt\/<\/li>
- Applications\u2192SuSEhelp\u2192DOC_ALLOW<\/strong> bleibt leer.<\/li>
- Der Filter f\u00fcr Server Side Includes (SSI)<\/a> wird aktiviert.<\/li><\/ul>\n\n\n\n
- Mit der Direktive DavDepthInfinity<\/strong> werden PROPFIND<\/strong>-Abfragen\n mit unendlicher Tiefe ausgeschaltet. Dies w\u00e4re bei meinem kleinen \nAnwenderkreis allerdings nicht unbedingt notwendig gewesen.<\/li>
- http:\/\/caipirinha.homelinux.org\/gnome-icons<\/a><\/li><\/ul><\/li>
- Mit DirectoryIndex<\/strong> legt man fest, dass Webseiten mit Namen index.shtml<\/strong>\n ebenfalls als Index-Seiten (also so wie index.html) betrachtet werden. \nManche Entwicklungswerkzeuge f\u00fcr Webseiten nehmen die Endung shtml<\/strong> f\u00fcr Webseiten, welche Server Side Includes (SSI)<\/a> enthalten.<\/li>
- Mit AddDefaultCharset<\/strong> wird UTF-8<\/strong> als \nStandard-Zeichensatz des Webservers eingestellt. Dadurch k\u00f6nnen auch \nTexte in nicht-lateinischen Buchstaben problemlos dargestellt werden. \nHeutzutage macht wegen der zunehmenden Internationalisierung eigentlich \nauch keine andere Einstellung mehr Sinn.<\/li>
- Caipiwiki auf [2]<\/a><\/li>