Fallback Vhost (https)

suther

Member
Ich habe ein seltsames Verhalten auf dem Server festgestellt.
Wenn ich für eine Domain, die kein SSL aktiviert hat im Browser die https-Adresse eingebe, und die Warnung übergehe, lande ich auf der Webseite, die ich laut "apache2ctl -t -D DUMP_VHOSTS" als erste unter *:443 als NameVirtualhost stehen habe.

Wie bekomme ich es hin, das bei Seiten, bei denen kein SSL aktiviert ist, gar kein HTTPS angezeigt wird, oder zumindest nicht auf eine Fremde Seite weitergeleitet wird?
 

suther

Member
Ich habe nun noch etwas getestet und geprüft, und bin dabei ggf. auf zwei ISP-Bugs gestoßen.
1. BUG)
Also, in der Kundenvorlage, die ich für den Kunden verwendet habe, war "Lets Encrypt" nicht aktiviert, aber die Checkbox erschien in der Config-Ansicht des Kunden dennoch.
2. BUG)
In dieser Konstellation ist mir auch aufgefallen, das selbst wenn ich SSL aktiviert habe (ohne Lets Encrypt und obwohl SSL-Aktivieren in der Kundenvorlage aktiviert war), wurde bei der Domain keine 443er Virtualhost eingetragen (die Vhost-Datei hatte nur einen Eintrag für *:80).

Dies hat sich aber auch nicht geändert, nachdem ich in der Kundenvorlage Letz Encrypt aktiviert habe, und es erneut versucht habe.
Für diese Domain wird seltsamerweise kein Virtualhost 443 eingetragen.
 

Till

Administrator
Zu Deinem ersten POST: das was Du da beschreibst ist das normale Verhlaten des apache und nginx web servers, daran ist nicht seltsam, das ist genau so zu erwarten.

Wie bekomme ich es hin, das bei Seiten, bei denen kein SSL aktiviert ist, gar kein HTTPS angezeigt wird, oder zumindest nicht auf eine Fremde Seite weitergeleitet wird?

Das wurde schon häufig beantwortet:

a) Nutze eine IP für Hosts mit SSL und eine andere für hosts ohne ssl.
b) aktiviere ssl für alle seiten.

Zu Deinem 2. Post:

1) Ich vermute Du warst als admin eingelogged und nicht als Kunde. Bei mir erscheint sie definitiv nicht wenn ich als Kunde eingelogged bin und der admin sieht immer alle Felder.
2) Es wird kein SSL vhost angelegt wenn es kein gültiges SSL cert gibt, denn sonst würde ja apache nicht mehr starten. Der 443 vhost wird nur angelegt wenn es ein SSL cert gibt und die SSL checkbox angehkt ist.
 

suther

Member
Zu deiner Antwort 2.2... was bedeutet das unterm Strich? Was ist zu tun?

Bei anderen Vhosts geht es so:
SSL und Let's Encrypt checkboxen aktivieren, und alles nötige, damit die Domains via https erreichbar sind, wird von ispconfig erledigt.

Habe das für eine andere Domain ausprobiert, da funktioniert es tadellos.

Folgendes habe ich nun aktuell noch ausprobiert:
Erstmal als Kunde angemeldet, und versucht die Einstellung zu ändern. Dann meckert er, das die IP nicht geändert werden kann.
Als Admin steht diese auf *, der Kunde hat nur den IP-Eintrag.
Stelle ich als Admin die IP auf eine IP, anstatt auf *, werden plötzlich auf allen anderen Kundenseiten die auf * stehen, die Inhalte der Seite die ich auf IP gestellt habe angezeigt.

Zu testzwecken, um bei dem SSL-Problem sicherheit zu bekommen, hab ich es dennoch kurz so gelassen (also diese Domain auf IP gestellt):
VERSUCH 1
1) Als Kunde angemeldet (ich sehe SSL und Lets Encrypt - Checkbox).
2) SSL und Let's encrypt aktiviert
3) Nach erneutem Aufruf der Domaineinstellungen sind beide checkboxen wieder deaktiviert
3a) dIe Vhost der Domain hat keinen 443 Eintrag
4) https der im Browser verlinkt immer noch auf eine falsche Domain

VERSUCH 2
1) Als Kunde angemeldet (ich sehe SSL und Lets Encrypt - Checkbox).
2) nur checkbox für SSL aktiviert
3) Nach erneutem Aufruf der Domaineinstellungen ist die Checkbox noch aktiviert
3a) dIe Vhost der Domain hat immer noch keinen 443 Eintrag
4) https der im Browser verlinkt immer noch auf eine falsche Domain

VERSUCH 3
Dann zurück als Admin (und Host wieder auf * gestellt):
1) SSL (ist ja noch vom Kunden) aktiviert.
2) Let's encrypt aktiviert und gespeichert
3) rufe ich die Website-Einstellungen erneut auf, ist die Let's encrypt checkbox wieder deaktiviert
3a) dIe Vhost der Domain hat immer noch keinen 443 Eintrag

Grübel Grübel und Studier...
Ich kann scheinbar machen was ich will, für die Domain legt er keinen 443 VirtualHost Eintrag an. Also hab ich überlegt, woran könnte es liegen, was ist bei der Domain anders, als bei den anderen???

Und die LÖSUNG
Scheinbar die einzige Besonderheit, die diese Domain aufweißt... sie hat einen Domainalias einer Umlaut-Domain (xn-- ).
Also hab ich folgendes gemacht:
1) den Umlaut-Domain-Alias gelöscht
2) SSL deaktiiert & gespeichert
3) SSL + Lets Encrypt aktiviert & gespeichert
3a) siehe da, Vhost-Eintrag für 443 erscheint nun
4) https Seite funktioniert.

Schlussendlich habe ich die Umlaut-Domain wieder angelegt, und es funktioniert immer noch.

ABER
ändert man dann etwas an der Config der Domain (scheinbar also immer dann wenn die vhost neu geschrieben wird), verschwindet der 443er Eintrag wieder koplett!


Vielleicht testet Ihr das mal genauer. Ggf. gibt es hier einen BUG, der sich wie oben beschrieben nachstellen lässt, wenn vor der aktivierung von SSL eine Umlaut-Domain als Domainalias existierte.
 
Zuletzt bearbeitet:

Till

Administrator
Alle Deine Versuche sind genauso zu erwarten, erstens kannst Du nicht IP und * mischen, denn das muss dazu führen das aller traffic bei der website mit der IP landet. das istw ie von mir beschrieben immer so bei apache und nginx, hat nichts mit ispconfig zu tun. Wenn es für eine domain keinen port 443 vhost gibt, dann sucht sich apache den ersten port 443 vhost und leitet den traffic darauf um. Auch das ist nicht ispconfig spezifisch. Dann zum deaktivieren des LE, wenn Du kein LE in den Kundenlimits erlaubst und dann als Kunde die webseite editierst, dann muss ispconfig LE deaktivieren um die von Dir vorgegebenen Limits für den Kunden einzuhalten. Was Du also dafür tun musst ist einfach LE für den Kunden in seinen Limits erlauben, wenn er denn LE haben darf.
 

suther

Member
Ja, das mit * und IP verstehe ich, ich habe hier nur ausgiebig geschildert, was ich getan habe.
Schritt 1-3 sind, damit Ihr es reproduzieren könnt, was versucht wurde.

LE war ganz am Anfang mal in den Kundenvorlagen versehentlich "nicht erlaubt". Hatte ich vergessen zu erwähnen, das ich das in den Kundenvorlagen aktiviert hatte?! Hatte ich auf jeden Fall dann gemacht. Also vollen SSL Zugriff und vollen LE Zugriff für den Kunden.

Der Bug, der nach wie vor bleibt, ist kurz gesagt der mit dem Umlautdomain-Alias. Und das ist beliebig oft reproduzierbar.
Sobald eine Umlautdomain als Alias eingetragen wurde, zerschießt es die SSL-Config.
Bitte versucht es zu reproduzieren, es ist definitiv ein Bug.
 

Till

Administrator
Das ist kein Bug, Dein LE Client kann nur noch keine Umlautdomains. LE hat unterstützung für Umlautdomains gerade erst freigegeben und die meisten clients können es noch nicht. ISPConfig ist bereits darauf vorbereitet, Du musst also nur eine certbot oder letsencrypt version installieren die bereits Umlautdomains unterstützt.
 

suther

Member
Ach so... gut, das war mir nicht bewusst.
Ich war der Meinung, das ISPconfig die <VirtualHost *:443> Einträge setzt und verwaltet. Mir war nicht bewusst, das LE die Macht hat, den gesamten Virtualhost-Eintrag aus der Vhost-Datei zu werfen, selbst wenn ISPConfig den "SSL" Flag immer noch gesetzt hat.

Ich wäre jetzt davon ausgegangen, das wenn ich die SSL-Checkbox aktiv setze UND LE aktivere, dass wenn LE ein Problem hat, dies dann halt für die Domain nur nicht ausgeführt wird, aber die sonstige SSL-Config unangetastet bleibt.

Ein "kleiner Bug" scheint es dann dennoch zu sein, den wenn der <VirtualHost *:443> Eintrag aus der Vhost verschwindet, bleibt die Checkbox im Backend von ISPconfig "ssl" aktiviert
 

Till

Administrator
Ich war der Meinung, das ISPconfig die <VirtualHost *:443> Einträge setzt und verwaltet. Mir war nicht bewusst, das LE die Macht hat, den gesamten Virtualhost-Eintrag aus der Vhost-Datei zu werfen, selbst wenn ISPConfig den "SSL" Flag immer noch gesetzt hat.

Hatte ich bereits in post #3 punk 2) geschrieben. Wenn es kein SSL cert gibt, dann wird auch kein 443 vhost angelegt da apache sonst nicht startet. Wenn also LE kein cert erstellen kann dann gibt es kein cert und somit auch keinen port 443 vhost.

Ein "kleiner Bug" scheint es dann dennoch zu sein, den wenn der <VirtualHost *:443> Eintrag aus der Vhost verschwindet, bleibt die Checkbox im Backend von ISPconfig "ssl" aktiviert

Das ist ja auch gemau richtig so, denn dies echeckbox weist ispconfig an bei vorliegen eines gültigen ssl certs einen 443 vhost anzulegen, wenn Du kein cert hat, z.B. weil LE keines erstellt oder Du keines auf dem SSL Reiter eingefügt hat, dann wartet ISPConfig mit der Aktivierung bis ein SSL cert vorliegt, ich verweise nochmal auf post #3 punk 2.
 

Werbung

Top