# SSL für EINE Website aktivieren



## awl (17. Apr. 2013)

*SSL für EINE Website aktiviert - dann ALLE nicht mehr per http erreichbar!*

Hallo,

als relativer ISPconfig-Neuling sage ich erstmal ein dickes DANKE für dies tolle, geradlinige und durchdachte Tool! Ich bin wirklich beeindruckt. Da steckt unübersehbar eine Menge Expertise drin - Hut ab! Vor allem: alles lief auf Anhieb völlig reibungslos (Einzelserver mit Debian bei OVH).

Nun ja, ein kleines Problem gibt es nun doch - oder ich bin noch zu neu, um die Konzepte und Zusammenhänge ganz zu durchschauen...

Ich wollte diesen coolen Tipp umsetzen und habe also die dafür vorgesehene Webpräsenz auf SSL (vorerst selbst-signiert) umgestellt. Problem danach: auf einmal sind *alle* Webpräsenzen des Servers nicht mehr per http zu erreichen!  Es erfolgt immer eine sofortige Redirection auf die jeweilige http*s*-URL nebst typischer Browser-Warnung. Ich musste die SSL-Einstellung vorerst schleunigst zurücknehmen, damit die Besucher nicht verwirrt werden.

Was läuft da falsch? Leider habe ich nur _eine _IP und muss damit irgendwie eine friedliche Koexistenz zwischen mehreren http-Sites und der einen http*s*-Site hinkriegen (selbst wenn das bedeuten müsste, dass ISPconfig selbst nicht mehr https-geschützt sein kann, was sich ja aber durch den Proxy-Tipp kaschieren ließe).

Bin für jeden Tipp dankbar.

Gruß,

awl


----------



## ramsys (18. Apr. 2013)

Hallo awl,

hast Du in der Serverkonfiguration unter Web -> SSL-Einstellungen SNI aktiviert?


----------



## awl (18. Apr. 2013)

> hast Du in der Serverkonfiguration unter Web -> SSL-Einstellungen SNI aktiviert?


*nachguck* --> JA

Muss zugeben, dass ich bis zu dieser Einstellmöglichkeit noch gar nicht bewusst vorgedrungen war; sie befand sich also noch in der "Werkseinstellung". Ich bin nur ganz treuherzig dem Howto aus dem ISPconfig-Manual gefolgt.

Allerdings verstehe ich noch nicht, weshalb die _globale _Einstellung "SNI" für mein Problem verantwortlich sein sollte. Nach meinem Verständnis kann SNI  _mehrere_ SSL-Sites auf einem Server bzw. unter einer IP ermöglichen, soweit klar. Ich erkenne aber noch nicht, wie und warum es mein Problem bewirken könnte, nämlich dass sich  _alle _vHosts so verhalten, als sei bei ihnen SSL aktiviert, sobald es nur bei einem einzelnen der Fall ist. Das ist doch in jedem Fall unlogisch, egal wie SNI eingestellt ist, oder? 

Freundliche Grüße,

awl


----------



## Till (18. Apr. 2013)

Ich denke nicht dass es was mit SNI zu tun hat.

Entferne bitte mal den proxy code und aktivier ssl für eine webseite wie im Handbuch beschrieben, kannst Du dann per ssl auf diese Webseite zugreifen und funktionieren die anderen Seiten noch?

Des weiteren stell bitte siche dass Du nicht * und IP Adressen bei Webseiten mischst, also entweder * für alle Seiten oder die IP für alle Seiten auswählen.


----------



## awl (18. Apr. 2013)

Vielen Dank, Till!



> Des weiteren stell bitte siche dass Du nicht * und IP Adressen bei Webseiten mischst


Verstehe. Mischen impossible. 

Habe also alle Sites von * auf die fixe Server-IP umgestellt. Nachdem ich alle deine Empfehlungen umgesetzt habe, sieht es schon besser aus, auch wenn es weiterhin Seltsamkeiten gibt. Aber mal der Reihe nach:


Die SSL-Website ist jetzt wahlweise per _http _oder _http*s* _erreichbar - gut so, kann so bleiben. (Proxy-Geschichte teste ich dann separat, das werd ich hinkriegen.)
Die _übrigen _Websites sind - richtigerweise - per http erreichbar. Auch gut. Damit ist immerhin mein krasses Eingangsproblem schon mal behoben.
ABER: auch die Nicht-SSL-Websites reagieren auf http*s*-Requests, was eigentlich nicht sein sollte, da dort gar kein SSL freigegeben ist. Noch schlimmer: wenn man sie per http*s* aufruft, sieht man nicht ihre eigenen Inhalte, sondern die der SSL-Website. Also aus Sicht des Besuchers völlig fremde und verwirrende. Hijacking sozusagen. Da vermischen sich also dann Inhalte über Domaingrenzen hinweg, was natürlich nicht sein sollte.
Ich hab jetzt doch mal probeweise SNI abgeschaltet, aber das ändert schlichtweg gar nichts am vorstehend beschriebenen Verhalten.

Noch irgendwelche Tipps? (Außer zweite IP besorgen, das scheidet vorliegend aus.)

Gruß & Dank

awl


----------



## Till (18. Apr. 2013)

> ABER: auch die Nicht-SSL-Websites reagieren auf https-Requests, was eigentlich nicht sein sollte, da dort gar kein SSL freigegeben ist. Noch schlimmer: wenn man sie per https aufruft, sieht man nicht ihre eigenen Inhalte, sondern die der SSL-Website. Also aus Sicht des Besuchers völlig fremde und verwirrende. Hijacking sozusagen. Da vermischen sich also dann Inhalte über Domaingrenzen hinweg, was natürlich nicht sein sollte.


Das ist immer so im apache, denn apache leitet bei einem nicht existierenden vhost die Anfrage an den ersten passenden vhost auf dem gleichen Port weiter. Deshalb sollte man bei ssl ja auch eine extra IP pro Web haben oder aber alle nicht ssl vhosts auf einer IP sameln und alle anderen vhosts auf einer anderen


----------



## awl (18. Apr. 2013)

Hui, das ging aber schnell!



> Das ist immer so im apache,


Okay, aber warum gibt es dann die gleichen Cross-Effekte nicht auch zwischen ISPconfig und den Nicht-SSL-Sites? Da klapppt die Koexistenz auf einem Server unter gleicher IP doch auch wunderbar.

Das zeigt doch, dass es im Prinzip möglich sein müsste.

Nochmals Gruß,

awl


----------



## Till (18. Apr. 2013)

> Okay, aber warum gibt es dann die gleichen Cross-Effekte nicht auch zwischen ISPconfig und den Nicht-SSL-Sites?


Es gibt doch den glechen Effekt. Wenn Du domain123.tld:8080 eines Kunden eingibst erhältst Du ispconfig und nicht die Kundenwebseite da ispconfig der einzige vhost auf port 8080 ist, würdest Du einen vhost im apache für domain123.tld für port 8080 anlgene, dann würdest Du die kumdenwebseite und nicht ispconfig erhalten. ist also genau das gleiche.


----------



## awl (18. Apr. 2013)

Hm, haste auch wieder Recht. War wohl ein Denkfehler von mir... 

Vielleicht sollte ich meinen SSL-vHost auch auf einen Non-Standard-Port legen, dann ist das Problem zumindest weniger auffällig. Versehentlich (oder auch absichtlich) https statt http eingeben passiert sicherlich eher mal als auch noch eine fremde Portnummer dranhängen.


----------



## Till (18. Apr. 2013)

Du kannst versuchen in der ssl webseite eine .htaccess Datei anzulegen die im falle dass der zugriff per ssl erfolgt, die domain aber nicht die der ssl seite ist den request auf "nicht ssl" umbiegt. Ich hab da nichts fertiges parat, als Grundlage kannst Du das hier nehmen:

RewriteEngine On
RewriteCond %{HTTPS} on
.....
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}

wo .... steht müsstest Du noch eine weitere RewriteCond einfügen die beasgt "wenn %{HTTP_HOST} nicht dein ssl host ist.


----------



## awl (18. Apr. 2013)

Dankeschön, ich werde es probieren und dann berichten!


----------

