SSLClientAuth für bestimmte Pfade

[arob]

Hi,

ich habe gerade ein ganz großes Problem mit meinem Apache Server, der standardmäßig alle Seiten über SSL ausliefert.
Die "Startseite" ist dabei ohne Authentifikation aufrufbar - einige Pfade erfordern hingegen SSLClientAuth über eine SmartCard.

Für jeden Pfad, der eine Authentifikation erfordert habe ich einen eigenen <Location> Abschnitt in meiner vhost-Config. Insgesamt sind es drei und der Inhalt ist 100% identisch:

Code: Select all

<Location /mediawiki>
    Order deny,allow
    Allow from All
    AuthType Basic
    AuthName "Wiki"
    AuthUserFile /etc/apache2/vhosts.d/wiki-users.certlist
    Require valid-user
    AddDefaultCharset UTF-8
    SSLRequireSSL
    SSLOptions +FakeBasicAuth +StdEnvVars +ExportCertData
    SSLVerifyClient require
    SSLVerifyDepth 6
  </Location>


Das Dumme ist: Bei 2 der 3 Locations funktioniert alles wie gewünscht, nur bei MediaWiki gibt es Probleme:

FireFox 3.6.2 meldet dann immer "ssl_error_handshake_unexpected_alert"
Apache 2.2.15 mit OpenSSL 0.9.8n meldet im Log: "Re-negotiation handshake failed: Not accepted by client!?"

Ich denke das problem hängt irgendwie mit der renegotiation-Schwachstelle und den Workarounds zusammen - allerdings verstehe ich nicht, wieso bei identischer Kofiguration nur eine Location betroffen ist. Was macht mediaWiki so anders als die anderen locations (eine der anderen ist z.B. Gallery - also auch eine komplexere PHP-Anwendung).

Hat einer von euch noch Ideen an welchen Schräubchen man drehen kann oder was Apache bzw. Firefox hier Probleme bereitet?

Robert

[Nobbie]

Ich vermute mal, dass Mediawiki ein aufwändiges URL-Rewriting veranstaltet, so dass die Location-Anweisung irgendwie damit kollidiert. Vielleicht solltest Du es mal statt in einen Location in einen Directory-Container legen.

[arob]

Gute Idee - nur Leider funktioniert die SSL-Clientauthentifikation für Unterverzeichnisse nicht über den Directory-Eintrag.

Wenn ich den Eintrag von <Location> auf <Directory> ändere ist das Verzeichnis /mediawiki plötzlich komplett ungeschützt, d.h. man braucht gar keine Client-Authentifikation mehr. Kopiere ich den Eintrag und mache einen zum <Location> den anderen als <Directory> kommt wieder der "ssl_error_handshake_unexpected_alert".

BTW: Kann URL-Rewriting wirklich das Problem sein? Wenn mediaWiki das nutzen würde, dann müsste s doch irgendwo in der vhost oder einem der .htaccess-Dateien auftauchen, da das rewriting doch nur über mod_rewrite funktioniert, richtig?
Solche Einträge finde ich jedoch nicht für MediaWiki, nur für Gallery, das wie schon gesagt ja einwandfrei funktioniert.

Bleiben also nur noch ein oder mehrere HTTP-Redirect, die direkt aus PHP heraus von MediaWiki genutzt werden. Die müssten demnach die Ursache des Problems sein.

[Nobbie]

Gute Idee - nur Leider funktioniert die SSL-Clientauthentifikation für Unterverzeichnisse nicht über den Directory-Eintrag.

Blödsinn (sorry).

Wenn ich den Eintrag von <Location> auf <Directory> ändere ist das Verzeichnis /mediawiki plötzlich komplett ungeschützt, d.h. man braucht gar keine Client-Authentifikation mehr

Du mußt natürlich auch den Wert "/mediawiki" ersetzen, das ist die Location, aber nicht das Directory (da muss dann der physikalische Pfadname hin, also beispielsweise c:/xampp/htdocs/mediawiki o.ä.)

BTW: Kann URL-Rewriting wirklich das Problem sein? Wenn mediaWiki das nutzen würde, dann müsste s doch irgendwo in der vhost oder einem der .htaccess-Dateien auftauchen, da das rewriting doch nur über mod_rewrite funktioniert, richtig?

Das ist richtig, wenn es keine .htaccess irgendwo gibt, gibt es auch kein URl-Rewrite. Aber dann immer noch mediawiki via PHP-Header-Funktion einen Redirect veranlassen, der vielleicht in die Hose geht. Ich weiß ja auch nicht, was da veranstaltet wird. Nur finde ich eine Authorisierung für ein Directory angemessener, denn ganz sicher muss mediawiki innerhalb dieses Directorys laufen.

Bleiben also nur noch ein oder mehrere HTTP-Redirect, die direkt aus PHP heraus von MediaWiki genutzt werden. Die müssten demnach die Ursache des Problems sein.

Ja, s.o. Ist aber dennoch geraten, stelle mal "richtig" auf Directory um.

Btw.: Du kannst natürlich auch selbst eine .htaccess in das Mediawiki Verzeichnis legen, dann läßt Du den <Directory>-Container drum herum weg. Das kommt aufs gleiche hinaus, hat den kleinen Vorteil, dass man sich bei der Directory-Pfadangabe nicht vertun kann. Allerdings muss AllowOverride das erlauben.

[arob]

Du mußt natürlich auch den Wert "/mediawiki" ersetzen, das ist die Location, aber nicht das Directory (da muss dann der physikalische Pfadname hin, also beispielsweise c:/xampp/htdocs/mediawiki o.ä.)

Klar - das Brett vor'm Kopf war etwas zu groß Habe es jetzt ausprobiert und korrekterweise den absoluten Pfad zum Verzeichnis "mediawiki" verwendet.
Dummerweise hatte es keine Auswirkungen auf den Fehler.

Interessant ist dass ich zwischen drin die Datenbank heruntergefahren hatte dann tatsächlich die MediaWiki-Fehlermeldung kam, dass die Verbindung zur Datenbank nicht funktioniert. D.h. der Auslöser des Problems liegt tatsächlich irgendwo in MediaWiki "vergraben".

[Nobbie]

Klar - das Brett vor'm Kopf war etwas zu groß Habe es jetzt ausprobiert und korrekterweise den absoluten Pfad zum Verzeichnis "mediawiki" verwendet.
Dummerweise hatte es keine Auswirkungen auf den Fehler.

Interessant ist dass ich zwischen drin die Datenbank heruntergefahren hatte dann tatsächlich die MediaWiki-Fehlermeldung kam, dass die Verbindung zur Datenbank nicht funktioniert. D.h. der Auslöser des Problems liegt tatsächlich irgendwo in MediaWiki "vergraben".

Da habe ich auch noch eine Idee: das Mediawiki wird installiert per Installer und verlangt (soweit ich weiß) irgendwo einen Servernamen. Wenn dieser Name bei Installation nicht identisch ist mit dem, was Du nachher in der URL eingibst, dann führt ein interner Redirect zu unvorhersehbaren Fehlern. Als Beispiel: Du gibst als Servername 127.0.0.1 an und rufst nachher via http://localhost/mediawiki auf, oder irgendeine andere Kombination (vielleicht auch mit VirtualHosts). Dann stimmt auf einmal der Servername nicht mehr mit dem Zertifikat überein. Ohnehin muss auch in httpd.conf der richtige ServerName stehen, d.h. an vier Stellen (httpd.conf, Mediawiki Installation, SSL Zertifikat, BrowserURL) muss unbedingt der gleiche richtige ServerName stehen.