SSL-Option f. Kunden verhinderbar?

[osterhase]

Hallo!

Wie wir alle wissen ist es ja außer mit SNI von SSL aus lediglich möglich nur ein SSL-Zertifikat pro IP-Adresse auszugeben. Soweit so gut.

Nun haben wir eine Seite mit einem SSL-Zertifikat laufen und möchten daher verhindern, dass ein anderer Kunde denkt "Na hervorragend - dann aktiviere ich mal SSL bei mir - ist eh besser."

Hier zum besseren Verstädnis das Bsp. von falcon37:

https://www.test1.com ruft https://www.test1.com auf
https://www.test2.com aber https://www.test1.com
https://www.test3.com -> https://www.test1.com

Quelle: http://www.howtoforge.de/forum/allgemein-11/https-problem-4835/

Allerdings bemerkt ufreier einen Post später:
"Dabei ist noch folgendes interessant: irgendwie habe ich noch keine Möglichkeit gefunden zu unterbinden, dass ein Kunde bei seiner Website den Reiter SSL angezeigt bekommt, d.h. wenn ich es richtig verstehe, kann doch jeder Kunde für seine Site SSL einrichten? Und damit passiert dann genau das, was Du geschildert hast."

Gibt es da inzwischen eine Lösung von ISPConfig aus für dieses Problem? Bspw. durch "Limits" dies zu verhindern?

Bin für einen Hinweis dankbar,

Viele Grüße
osterhase

 

[Till]

Es gibt schon immer die Möglichkeit die Veränderung der Web-Einstellungen zu blockieren. Dazu legst Du einfach die Webseite als admin für den Kunden an, also Du bist dabei als admin eingeloggt während die neue Seite erstellt wird. Dies wird in den Webseiteneinstellungen automatisch vermerkt, so dass der Kunde dann keine der Basiseinstellungen wie ssl on / off über seinen Login mehr ändern kann.

 

[osterhase]

Hey Till,

vielen Dank für die schnelle Antwort. Allerdings sind unsere Kunden teilweise Webentwickler/Reseller d.h. sie erstellen ihre Domains selber. Gibt es hierfür auch eine Lösung?

Viele Grüße
osterhase

 

[Till]

Weise die IP Adressen unter System > Server IP dem jeweiligen Kunden fest zu. Denn sobald Du ssl auf einer IP liegen hast, macht es ja keinen Sinn dort andere Kunden oder Websites drauf zu haben, denn die würden ja auch alle in dem SSL web landen,sobald man sie mit https aufruft.

 

[osterhase]

Das bedeutet natürlich eine Reihe von IPs - sonst könnte ja ein Reseller / Webentwickler auf die Idee kommen SSL bei sich zu aktivieren und dann müssen alle anderen Webentwickler auf dem Server eine andere IP zugewiesen bekommen.

Für ein vollautomatisiertes Hosting-System ist das viel händische Arbeit. Es wäre schon die SSL-Option in den Limit-Einstellungen unterbinden zu können. Aber das ist dann wohl eher ein Feature-Request...

Vielen Dank für die ganze Arbeit!

 

[Till]

Normalerweise setzt man ja ein System so auf:

1) eine globale, freie IP, die für alle Webs genutzt wird die kein SSL haben. Diese IP ist keinem Client zugeordnet und sie ist auch nicht in ISPConfig unterSystem > Server IP angelegt aber auf diese IP verweist Du alle DNS Records der Domains die kein SSL haben. Der Client bzw. Reseller hat also nur die Möglichkeit * auszuwählen und das läuft dann alles über die IP. SSL ist per SNI möglich, aber es kann eben kein client einem anderen die IP "wegnehmen".

2) Wenn Du ein SSL Web hast, dann fügst Du die SSL IP unter System > Server IP hinzu und weist sie einem Kunden zu. Diese IP it dann fest an den Kunden gebunden und kann nicht von anderen Kunden verwendet werden.

 

[osterhase]

Vielen Dank nochmals für den Hinweis. Gerade mit den IPs hatten wir neulich ein nicht ganz unerhebliches Problem, mit dem wir einen Bock geschossen haben. Allerdings war das ein Konfigurationsfehler auf unserer Seite, den wir perspektivisch beheben müssen (ist allerdings wiederum einen anderen Thread wert).

Was mir noch nicht ganz klar ist Punkt 1:
Wenn ISPConfig keine IP-Adressen registriert hat - also nur * zur Verfügung steht - kann der Client doch immer noch die SSL-Option anwählen oder habe ich das was mißverstanden?

 

[Till]

Wenn ISPConfig keine IP-Adressen registriert hat - also nur * zur Verfügung steht - kann der Client doch immer noch die SSL-Option anwählen oder habe ich das was mißverstanden?

Das ist richtig, es handelt sich dabei aber um ssl per sni. Da normalerweise ein ssl default vhost für * auf dem System existieren sollte (bei debian kann man das mit "a2ensite default-ssl" aktivieren), werden alle ssl anfragen für nicht existierende Seiten oder Anfragen von Browsern ohne sni Unterstützung auf den default vhost und nicht eine falsche Webseite umgeleitet. Es bestehen also nicht die negativen Auswirkungen wie bei der Verwendung der IP für andere Webs, wenn ein user ssl bei sich aktiviert. Es gibt also das folgende Szenario für die * hosts:

a) User hat ssl aus, jemand greift per ssl auf seine Domain, request landet im default vhost, wo Du als Provider ja eine entsprechende Seite wir "Diese Webseite unterstützt kein ssl oder Ihr Browser unerstützt kein SNI" oder ähnliches hinterlegen kannst. Wenn Du es ganz geschickt machen willst, fragst Du den Browser in der Seite per javascript an und zeigst den SNI text nür für alte Browser an.

b) user hat ssl an und die Anfrage kommt von sni fähigem browser, in dem Fall funktioniert ssl vollständig und der seiteninhalt wird ssl verschlüsselt angezeigt.

c) User hat ssl an und Anfrage kommt von altem browser, dann landet die Anfrage wie bei a) auf dem default ssl host.

Es ist also so, dass beim einschalten von ssl im besten fall alles funktioniert, im schlechtesten fall eine Hinweisseite erscheint. Es wird abre in keinem Fall ein anderes web in Mitleidenschaft gezogen.