Blogix

Möchte man SSL-Zertifikate mit Zwischenzertifikaten einsetzen (um höhere Sicherheit zu gewährleisten werden fast ausschließlich Zwischenzertifikate verwendet), so müssen diese in Apache, Dovecot bzw. Postfix zusätzlich zur üblichen SSL-Konfiguration hinterlegt werden.

Apache:

In der Datei “/etc/apache2/httpd.conf” muss folgende Zeile eingefügt werden:

SSLCACertificateFile /etc/ssl/certs/SSL123_CA_Bundle.pem

Dovecot:

In der Datei “/etc/dovecot/dovecot.conf” muss folgende Zeile eingefügt werden:

ssl_ca_file = /etc/ssl/certs/SSL123_CA_Bundle.pem

Postfix:

In der Datei “/etc/postfix/main.cf” muss folgende Zeile eingefügt werden:

smtpd_tls_CAfile=/etc/ssl/certs/SSL123_CA_Bundle.pem

Statische Dateien (z.B. CSS, JS, Bilder) verfügen in der Standardkonfiguration von diversen Webservern über keine Expires-Header. Dies führt dazu, dass Dateien i.d.R. vom Browser nicht im Cache zwischengespeichert werden und stets eine Anfrage an den Server gesendet wird. Neben einer größeren Belastung für den Server führt es außerdem zu langsameren Ladezeiten der Webseite. Mit dem Apache-Modul mod_exprires – bei Debian z.B. standardmäßig mit Apache installiert – kann der Expires-Header gesetzt und dem Browser mitgeteilt werden, wie lange sich dieses Element nicht ändern wird. Hierfür fügt man der .htaccess-Datei folgende Zeilen hinzu:

<IfModule mod_expires.c>
	ExpiresActive On
	#ExpiresDefault "access plus 7 days"
	ExpiresByType image/bmp "access plus 7 days"
	ExpiresByType image/gif "access plus 7 days"
	ExpiresByType image/jpeg "access plus 7 days"
	ExpiresByType image/jpg "access plus 7 days"
	ExpiresByType image/png "access plus 7 days"
	ExpiresByType image/x-icon "access plus 7 days"
	ExpiresByType text/css "access plus 7 days"
	ExpiresByType text/javascript "access plus 7 days"
	ExpiresByType text/x-js "access plus 7 days"
	ExpiresByType application/javascript "access plus 7 days"
	ExpiresByType application/x-javascript "access plus 7 days"
</IfModule>

Die Verwendung von ExpiresDefault (hier nicht aktiviert) würde dazu führen, dass für jede ausgelieferte Datei ein Expires-Header gesetzt werden würde. Dies sollte bei dynamisch generierten Webseiten vermieden, da diese aus dem Browser-Cache und nicht vom Server geladen werden und somit nicht den aktuellen Stand widerspiegeln würden. Header für JPG-Bilder und JavaScript werden in diesem Beispiel mehrfach gesetzt, damit unterschiedliche Mime-Types aufgrund verschiedener Konfigurationen von Servern und Ausgaben von Skripts abgedeckt sind.

Alternativ ist es auch möglich, den Expires-Header anhand der Dateiendung zu setzen:

<FilesMatch "\.(bmp|gif|jpg|jpeg|png|ico|css|js)">
	<IfModule mod_expires.c>
		ExpiresActive On
		ExpiresDefault "access plus 7 days"
	</IfModule>
</FilesMatch>

Diese Methode zeigt allerdings nur bei statischen Dateien Wirkung, weshalb bei z.B. dynamisch generierten Bildern die Mime-Type-Lösung gewählt werden muss.

Im Head-Tag jeder Webseite kann man das Charset/Zeichensatz festlegen, mit dem die Datei gespeichert wurde. Der korrekte Zeichensatz kommt dann zum Tragen, wenn es um Umlaute geht. ISO-8859-1 benötigt genau 1 Byte um alle enthaltenen Zeichen darzustellen, UTF-8 hat eine variable Länge bis zu 4 Byte. Daran lässt sich erkennen, dass UTF-8 mehr Zeichen darstellen kann, diese aber zum Teil auch eine andere Bytes- bzw. Bitkombination aufweisen als das selbe Zeichen in ISO-8859-1.

Neben der Übermittlung des verwendeten Zeichensatzes im Head-Tag, besteht auch die Möglichkeit den Zeichensatz im Header, der im Browser nicht angezeigt wird, sondern nur für die Kommunikation erforderlich ist, zu übermitteln.

Werden der verwendete Zeichensatz sowohl im Head-Tag als auch im Header übermittelt, so vertraut der Browser üblicherweise auf den im Header. Dieser muss allerdings nicht immer korrekt sein, schließlich ist sehr häufig ein Standardwert eingestellt, der nicht unbedingt mit dem tatsächlich verwendeten Zeichensatz übereinstimmt. Das Ergebnis sind dann Fragezeichen oder Quadrate anstelle von Umlauten.

Nun folgt noch, wie man die Charset-Einstellungen auf verschiedene Arten und Weisen setzen kann:

Im Head-Tag:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

Header mit PHP-Skript setzen:

header("Content-Type: text/html; charset=utf-8");

In der php.ini:

default_charset = "utf-8"

In der Apache-Konfiguration oder in einer .htaccess-Datei (“AllowOverride FileInfo” muss hierfür erlaubt sein):

AddDefaultCharset Off

Um den Zeichensatz je nach Dateiendung festzulegen kann man in der Apache-Konfiguration oder in einer .htaccess-Datei folgende Einstellung treffen:

AddCharset UTF-8 .html

Auf Shared Hosting-Umgebungen (mehrere Benutzer teilen einen Webserver) ohne suphp oder PHP im CGI-Mode kommt es zu dem Problem, dass der Apache-Webserver und PHP für alle Domains mit einem Benutzer (z.B. “www-data”) ausgeführt werden. Das hat zur Folge, dass von PHP erstellte Dateien dem Apache-Benutzer gehören und meist auch nur der Besitzer (Apache-Benutzer) schreibend darauf zugreifen darf. Shared Hosting-Kunden melden sich aber mit FTP-Accounts an, die ungleich dem des Apache-Benutzers sind. Das führt dazu, dass FTP-Benutzer die vom Apache-Benutzer angelegten Dateien überlicherweise nicht löschen dürfen.

Um die Dateien wieder ändern oder löschen zu können, hat man zwei Möglichkeiten:

1. Beim Erstellen führt man direkt ein chmod() oder chown() aus und gewährt dem eigenen FTP-Benutzer die notwendigen Berechtigungen.
2. Man schreibt ein Skript, das diese Aufgabe hinterher ausführt und ruft dieses mit einem Browser auf.

Ein derartiges Skript könnte wie folgt aussehen (in diesem Beispiel werden alle Dateien und Ordner aus dem Ordner “fileadmin” gelöscht, der sich auf der selben Ebene wie das Skript befindet):

function recursive_readdir($path)
{
	$handle = opendir($path);
	while (($file = readdir($handle)) !== false)
	{
		if ($file != '.' && $file != '..')
		{
			$filepath = $path . '/' . $file;
			echo $filepath.'<br />';
			if (is_dir($filepath))
			{
				rmdir($filepath);
				recursive_readdir($filepath);
			}
			else
			{
				unlink($filepath);
			}
		}
	}
	closedir($handle);
}

recursive_readdir('./fileadmin');

In Firmennetzwerken (z.B. Webagenturen) ist es notwendig, dass auf interne Webseiten aus dem lokalen Netzwerk ohne Passworteingabe zugegriffen werden kann, aus externen Netzwerken (z.B. dem Internet) sollte hingegen der Aufruf der Seiten zwar auch möglich sein, allerdings nur nach erfolgreicher Authentifizierung mit Benutzername und Passwort. Somit wird externen Mitarbeitern oder Kunden der Zugriff ermöglicht und alle anderen Besucher, die keinen Zugriff haben sollen, ausgeschlossen.

Mit Apache und dem Modul mod_auth ist diese Konfiguration sehr einfach zu bewerkstelligen. Obendrein ist es auch möglich bestimmten externen IP-Adressen (z.B. von externen Mitarbeitern mit fixen IP-Adressen) den Zugriff ohne Passworteingabe zu ermöglichen. Hierfür wird folgende Konfiguration benötigt:

Order Allow,Deny
AuthType Basic
AuthName "Restricted Files"
AuthUserFile "/var/www/.htpasswd"
Require valid-user
Allow from 127.0.0.1 localhost
Allow from 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 169.254.0.0/16
Satisfy Any

Die Benutzernamen und Passwörter werden in diesem Fall in der Datei “/var/www/.htpasswd” gespeichert. Diese kann recht einfach mit dem Programm “htpasswd” über die Konsole bearbeitet werden. Der Zugriff ist im Beispiel vom lokalen Rechner und aus lokalen (privaten) Netzwerken erlaubt. Zusätzliche vertrauenswürdige IP-Adressen oder ganze Netzwerke können selbstverständlich hinzugefügt werden.

Die Konfiguration kann sowohl in einer .htaccess-Datei eingefügt werden, als auch direkt in den Konfigurationsdateien des Apache (httpd.conf bzw. apache2.conf) erfolgen.