SSL-Proxy gemäß 1&1-FAQ: Caveats + Denkanstöße

[dl7awl]

Moin,

es geht um die in der 1&1-FAQ unter http://server.1und1.com/root_server/howto/6.html beschriebene Lösung zum Einrichten eines SSL-Proxy. Diese scheint mir in mehrfacher Hinsicht nicht ganz unproblematisch.

Zusätzlich zu den hier bereits diskutierten Problemen ( http://www.rootforum.org/forum/viewtopic.php?t=9042 ) bin ich über folgendes gestolpert:

1. Der Aufruf https://ssl.domain.de/pfad funktioniert NICHT wie nach den letzten beiden Kommentarzeilen zu erwarten, sondern führt - jedenfalls wenn "pfad" NICHT in der domaindb gefunden wird - zu einem 404 Error. Eigentlich sollte ja dann der Inhalt von ssl.domain/pfad angezeigt werden. Wird er aber nicht! Wenn ich die Sache richtig verstehe, ist das auch logisch: durch die letzte "RewriteRule" wird ja ein normaler http-Aufruf daraus - und außerhalb des https-Kontextes ist die Subdomain ssl.... ja gar nicht gültig (wenn man nicht extra dafür sorgt, aber das wäre ja widersinnig) - kann also so nicht gehen!

2. Der Aufruf https://ssl.domain.de//, was ja durch einen Tippfehler (an Absicht wollen wir nicht denken...) leicht mal passieren kann, führt je nach Browser ggf. zu Endlosaktivität und Dauer-Traffic; bei jedem Zyklus wird die URL-Zeile um ein "/" verlängert!
Meine vorläufige Lösung:

Code: Select all

Hinter der vorhandenen Zeile (BTW: kann mir die jemand erklären?):
   RewriteRule     ^/w3c/(.+)      -                               [L]
folgende einfügen:
   RewriteRule     ^//     /

Mit mod_rewrite (ist bekanntlich voodoo...) stehe ich nicht so ganz auf Du und Du, deshalb ist meine so offensichtlich und naheliegend scheinende Lösung nicht ganz optimal: sie führt immer noch zu einem überraschenden (unschädlichen) "Purzelbaum", wie man der Log-Datei entnehmen kann.
Immerhin aber kommt die Sache definiert zur Ruhe.

3. Die Zeile in sslproxy.conf nach "#RewriteLog /dev/null" müsste eigentlich heißen: "#RewriteLogLevel 0". Solange die Zeile auskommentiert ist, schadet das natürlich nichts, aber man sollte nach vollendetem (!) Debugging und Test das Logging deaktivieren, da nur noch unnütze Daten produziert werden und lt. Apache-Doku der Server unnötig ausgebremst wird.

4. Das lt. FAQ erforderliche Verzeichnis "home/www/webX/html/sslproxy" wird m.E. nicht wirklich benötigt. Gleiches gilt für den Eintrag"RewriteLock /var/lock/rewrite.lock" in sslproxy.conf.

5. Trotz Eintrages "ServerName ssl.domain.de" finde ich den Proxy/SSL-virtualhost auch unter "domain.de" oder beliebigen "xyz.domain.de" usw. erreichbar. Nicht schlimm, aber unschön und (für mich) nicht ganz erklärlich.

Könnt Ihr die o.g. Punkte nachvollziehen, bzw. hat jemand Ideen/Anregungen? Lasse mich ggf. auch gern korrigieren.

Grüße,

Manfred

[rootmaster]

hallo Manfred,

na dann wollen wir mal....

also die sslproxy-faq von 1&1 ist etwas "suboptimal", was die von dir angesprochenen fragen angeht ;)

du hast es natürlich richtig erfasst, dass alle requests an "normale" http-hosts weitergegeben werden sollen. ergo muss zu jedem HTTP-HOST ein entsprechender vhost existieren.
eine sonderrolle spielen nun die requests, die nicht über ssldomains auf einen vhost gemappt werden. es handelt sich hierbei speziell auch um zugriffe auf den stammpfad der aufgerufenen ssl-domain. natürlich könnte man jetzt mit ändern der aufgerufenen ssl-domain auch verschiedene stammpfade verschiedener vhosts erreichen (zb. mit https://confixx.domain.de den confixx-vhost). freilich ist das aber nicht im sinne des erfinders des ssl-protokolls bzgl. der authentifizierung des servers. ein zertifikat kann es ja nur für eine ssl-domain (auf dem 443-port) geben ! also muss man sich für ein documentroot entscheiden !
man könnte jetzt mit DocumentRoot diesen für die ssl-domain vorgeben. imho ist dies aber nicht notwendig/sinnvoll/überflüssig, da es einfacher ist (und konfusion vermeidet ;)), wenn man dafür einen normalen vhost mit gleichem ServerName einrichtet. dieser dürfte für die meisten auf den confixx-vhost mappen, da dort zugriffe auf den stammpfad notwendig sind (zb. /poplogin/). im übrigen ist bei den über sslproxy erreichbaren domains notwendig, dass bei links relative pfade (href="verzeichnis/link") und keine absoluten (href="/verzeichnis/link") angegeben werden, da dies i.a. (wenn nicht das präfix aus ssldomains hinzugefügt wird) auf den docroot der ssl-domain führt.

um mal eine lösung anzubieten 8)

1) man deaktiviere den ssl-vhost und den confixx-vhost.
2) man richte den sslproxy-vhost ein und den entsprechenden normalen vhost und schiebt sie ans ende der httpd.conf

also sieht das ende der httpd.conf folgendermaßen aus:

Code: Select all

RewriteLock     /var/lock/rewrite.lock

<VirtualHost IP:443>
  ServerName ssl.domain.tld

  SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
  SSLCertificateFile /etc/httpd/ssl.crt/server.crt
  SSLCertificateKeyFile /etc/httpd/ssl.key/server.key
  SSLEngine on
  RewriteEngine   on
  RewriteMap      lowercase       int:tolower
  RewriteMap      domaindb        txt:/etc/httpd/ssldomains
  RewriteRule     ^/icons/(.+)  -                               [L]
  RewriteRule     ^/w3c/(.+)      -                               [L]
  RewriteRule     ^/([^/]+)/(.*)  /${lowercase:$1}/$2             [S=1]
  RewriteRule     ^/(.*)          /${lowercase:$1}

RewriteRule     ^/([^/]+.[^/]+[^/])$   http://%{HTTP_HOST}/$1  [P,L]
RewriteRule     ^/([^/]+)/(.+..+)$     -       [S=1]
RewriteRule     ^/(.+[^/])$             /$1/    [R,L]
RewriteRule     ^/([^/]+)/(.*)          /${domaindb:$1|%{HTTP_HOST}/$1}/$2
RewriteRule     ^/(.*)                          http://$1    [P,L]

</VirtualHost>

<VirtualHost IP:80>
  ServerName ssl.domain.tld

  CustomLog /var/log/httpd/ssldomain_access.log "%h %l %u %t "%r" %s %b "%{Referer}i" "%{User-agent}i""
  ErrorLog /var/log/httpd/ssldomain_error.log
  DocumentRoot /home/www/confixx/html
  php_admin_value safe_mode_exec_dir /home/www/confixx/bin
  php_admin_value upload_tmp_dir /home/www/confixx/tmp
  ScriptAlias /cgi-bin/ /home/www/confixx/html/cgi-bin/
</VirtualHost>

die ssldomains wie gehabt, zb.

user1 http://www.domain1.de
domain2.de http://www.domain2.de

zu beachten ist hier (bei oberem sslproxy), dass domainnamen im proxy mit einem slash abgeschlossen werden müssen, um sie von files im stammpfad des sslproxys zu unterscheiden ! (zb https://ssl.domain.tld/domain1.de/, aber https://ssl.domain.tld/user1)

den confixx-vhost erreicht man so immer durch einfachen aufruf (zb https://ssl.domain.tld/user oder https://ssl.domain.tld/reseller ... oder https://ssl.domain.tld/poplogin)

möge es nützen ;)

"back to the roots"

[dl7awl]

Hallo Rootmaster,

ich möchte nicht den Eindruck von Ignoranz entstehen lassen, deshalb - wenn auch mit Verzögerung - erstmal herzlichen Dank für die Mühe, die Du Dir gemacht hast.

Das ist umso dankenswerter, da mein Posting eigentlich gar nicht primär als persönlicher "Hilferuf" gemeint war (bei mir läuft es so, dass man damit leben kann), sondern eher allgemein auf einige Haken und Ã?sen hinweisen sollte. Insbesondere die Sache mit der Endlosschleife finde ich schon etwas pikant... Ich habe auch die bei der 1&1-FAQ angebotene Feedback-Möglichkeit genutzt und auf die Probleme hingewiesen, aber die haben wohl wichtigeres zu tun als ihre FAQs zu verbessern...

Ich werde das, was Du geschrieben hast, auch noch praktisch nachvollziehen - bisher bin ich noch nicht dazu gekommen (hier auf dem flachen Land leider keine Flatrate, deshalb kann ich immer nur Sonntags mit XXL-Tarif in Ruhe am Server arbeiten, und da gibt's meist wichtigeres zu tun...)

Schöne Grüße,

Manfred

[franky777]

Hallo Rootmaster,

vielen Dank ersteinmal für diese Erklärungen. Es funktioniert jetzt bei mir mit WebFTP und Webmail bestens.

Bestehendes Problem:
Beim Einloggen über https://ssl.domain.tld/admin (bei reseller und user ebenso) kommt immer noch die Standard-Zertifikatswarnung (Name stimmt nicht mit Website überein). Ebenso möchte er nach erfolgreichem Einloggen als Reseller den letzten User (login springt dann auf mit confixx.p123456.pureserver). Durch "ok" oder "Abbrechen" konnte ich keine Unterschiede weiter feststellen. Andersrum genauso --> "User login" und reseller springt auf.

PS:Wäre schön, wenn einer dazu noch ne Lösung oder den Thread hat. Ich suche und probiere schon etwas länger daran.. hmm

[dl7awl]

Beim Einloggen über https://ssl.domain.tld/admin (bei reseller und user ebenso) kommt immer noch die Standard-Zertifikatswarnung (Name stimmt nicht mit Website überein).

Zumindest dafür ist die Lösung einfach: Eigenes Zertifikat mit den passenden Domaindaten erstellen, siehe http://server.1und1.com/root_server/security/9.html
Bei mir klappte das auf Anhieb, seitdem wird nicht mehr gemeckert.

Gruß, Manfred

[franky777]

Das Zertifikat wurde neu ausgestellt und müsste richtig sein. Ich habe ja auch absolut keine Probleme mit z.B phpmyadmin oder phpsysinfo. Dort kommen keine Meldungen.

Ich könnte mir zum jetzigen Zeitpunkt zwei Fehlerursachen vorstellen:
1) Confixx will einen Request nach confixx.p123456.pureserver.info stellen und dadurch kommt die Warnung, da der Zertifikatspfad verlassen wird
2) Mögliche Fehleinstellungen in der ssldomains

Code: Select all

#Pfad     ->     Domain
phpmyadmin      p123456.pureserver.info/phpmyadmin
confixx         confixx.p123456.pureserver.info
sysinfo         sysinfo.domain.tld/

Woran kann es also liegen?