Journal « Raphael Kallensee » apache

Server Name Indication (SNI) mit Ubuntu 10.04 (“Lucid Lynx”)

Raphael Kallensee — Tue, 29 Jun 2010 22:47:04 +0000

Bei “Name-based virtual hosts” in Verbindung mit SSL gibt es ein Problem: “by design” war es nicht möglich, mehrere virtuelle SSL-Hosts mit unterschiedlichen Domains und Zertifikaten parallel auf einer IP-Adresse und demselben Port zu betreiben. Problem ist, dass zuerst zwischen Client und Server die verschlüsselte Verbindung aufgebaut wird (bei der das Zertifikat bereits benötigt wird). Erst anschließend werden die HTTP-Header über die verschlüsselte Verbindung gesendet, in denen dann auch der Hostname steht, der jetzt möglicherweise aber gar nicht mehr zum Zertifikat passt. Einzige Lösung war bisher, pro SSL-IP eine eigene IP-Adresse (bzw. notfalls einen anderen Port) zu verwenden.

Abhilfe gibt es theoretisch bereits seit mehreren Jahren: Server Name Indication (SNI) ist eine Erweiterung des SSL-Protokolls, bei der einfach bereits beim Verbindungsaufbau vor dem SSL-Handshake der gewünschte Hostname mitgesendet wird.

Serverseitig benötigt diese Erweiterung insbesondere OpenSSL ab Version 0.9.8f sowie Apache ab 2.2.12 – außerdem müssen beim Kompilieren diverse Flags gesetzt sein. Seit Ubuntu 9.10 “Karmic Koala” sind sämtliche Voraussetzungen erfüllt, ich habe SNI nun erstmalig problemlos mit 10.04 “Lucid Lynx” im Einsatz. SNI funktioniert mit Apache und OpenSSL nun ohne Neu-Kompilieren “out of the box”.

Die Vorgehensweise ist im Prinzip ganz einfach: nach einem

NameVirtualHost *:443

können in den Apache-Konfigurationsdateien mehrere virtuelle SSL-Hosts definiert werden, die jeweils eigene SSL-Zertifikate besitzen. Weitere Infos sind im Apache-Wiki sowie hier zu finden.

Eine weitere Option erlaubt das Erzwingen von SNI: übermittelt ein Client nicht die SNI-Header, kann er den jeweiligen virtuellen SSL-Host nicht erreichen. Diese Option ist standardmäßig auf “off”.

SSLStrictSNIVHostCheck on

Der Haken: neben dem Server muss natürlich auch der Client SNI unterstützen. Internet Explorer unter Windows XP unterstützen SNI generell nicht (wobei es Berichte gibt, dass mit XP SP3 die Unterstützung vorhanden ist), Konqueror beherrscht SNI ebenfalls nicht. Ein Überblick über die Browser-Unterstützung findet sich hier. Ob ein Browser SNI unterstützt, kann man bei sni.velox.ch testen.

Zumindest in einigen Bereichen kann man SNI trotz der teilweise fehlenden Client-Kompatibilität bereits einsetzen – die client-seitige Unterstützung wird sich in Zukunft weiterhin verbessern.

Ein Artikel zum Thema ist in der c’t 23/09 erschienen und ebenfalls bei sni.velox.ch zu finden.

WordPress 2.6 und Permalink-Problem

Raphael Kallensee — Tue, 15 Jul 2008 19:41:39 +0000

Zuerst: WordPress 2.6 ist da! Mit tollen neuen Features (Revisionierung von Beiträgen!), aber leider auch Bugs.

Nach meinem Upgrade konnte ich leider Permalinks zu Artikeln nicht mehr erreichen (das offizielle Theme gibt eine 404er-Fehlermeldung), die Übersicht samt Paging und Permalinks zu Kategorien und Tags sowie “Seiten” waren erreichbar.

Zur Erklärung: ich verwendete keine mod_rewrite-Permalinks, sondern die PATHINFO-Permalinks im Stil

http://www.kallensee.info/journal/index.php/2008/08/22/test-beitrag

Nur bei diesen Permalinks, in denen die index.php vorkommt, tritt auch der Fehler auf.

Das Problem ist auch bereits bekannt. Ein Workaround wäre, in der Konfiguration unter Permalinks für Tags und Kategorien eine “Basis” einzutragen (ganz unten). Dadurch ändern sich allerdings Links zu Tags und Kategorien.

Ich habe den Bug gleich dazu genutzt, meine Permalinks auf die mod_rewrite-Variante umzustellen und von unnötigen Informationen zu bereinigen. Der SEO Blog brachte mich auf den Gedanken, dass die Datumsangabe in der URL ziemlich unnötig ist.

Das neue Permalink-Schema für Artikel ist deutlich schlanker als zuvor:

http://www.kallensee.info/journal/test-beitrag

Jetzt ist es natürlich an der Zeit, sich um die alten URLs zu kümmern. Alle Links – bis auf die Beitrags-Permalinks – werden von WordPress automatisch vom alten Format auf die neue Link-Struktur umgeleitet – Tags, Archive usw. Wichtig sind natürlich aber vor allem die Beitrags-Permalinks – die ja bei Google und anderen Blogs noch im alten Permalink-Format vorliegen. Damit die nicht auf einer Fehlerseite landen, habe ich in meine Apache-Konfiguration für den entsprechenden Host eine RedirectMatch-Direktive eingefügt:

RedirectMatch permanent ^/journal/index.php/200(6|7|8)/[0-9][0-9]/[0-9][0-9]/([A-Za-z0-9-/#]*) http://www.kallensee.info/journal/$2

Diese Direktive leitet alle Anfragen auf Beiträge des alten URL-Formats auf das neue Format um. Im Test werden aber alle URL’s korrekt umgeleitet. Wichtig: durch den Parameter “permanent” erfolgt die Weiterleitung mit dem HTTP-Statuscode 301, auf Deutsch: dem Anfragenden wird neben der neuen Adresse mitgeteilt, dass die Seite permanent “verzogen” ist. Für Suchmaschinen äußerst wichtig zu wissen.

Für Verbesserungsvorschläge bin ich jederzeit offen – zumindest optimieren kann man den regulären Ausdruck mit Sicherheit…

Apache-Fehler: pcfg_openfile: unable to check htaccess file

Raphael Kallensee — Tue, 15 Apr 2008 12:59:00 +0000

Nachdem aus unerklärlichen Gründen ein Teil meines Webservers nicht mehr erreichbar war und der Browser immer meldete, dass der Zugriff auf das Verzeichnis nicht möglich sei, habe ich in den Apache-Error-Logs folgendes gefunden:

(13)Permission denied: /var/www/[...]/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

Kam mir unbekannt vor – und obwohl die Fehlermeldung recht aussagekräftig war, kam ich erst hier auf die Spur: das Verzeichnis (bzw. schon ein Verzeichnis einige Ebenen tiefer) war für den Apache-User einfach nicht lesbar…