SSL-Zertifikate werden Domainübergreifend verwendet

web2s · 10. Oktober 2014

Hallo und Guten Abend zusammen,

ich habe vergangene Woche einen neuen Root-Server installiert.

Standard-Installation apt-get install liveconfig-meta liveconfig

An sich schien alles zu laufen, war es von Liveconfig auch nicht anders gewöhnt.
Nun habe ich für die IP-Adresse HTTPS über SNI aktiviert und ein Zertifikat erstellt und einem Kunden A zugeordnet.

Per Zufall rief ich nun eine andere Domain des Kunden B über https auf und bekam eine Zertifikatswarnung. Nachdem ich mich wunderte, weil ich diesem Kunden gar kein https aktiviert hatte schaute ich nach und stellte mit erschrecken fest, dass es das Zertifikat des Kunden A war.
Was allerdings noch schlimmer ist, ist die Tatsache, dass wenn man die Warnung ignoriert bzw. als Ausnahme anlegt, dann wird die Webseite von Kunde A angezeigt - unter der Domain von Kunde B.

Was hab ich falsch gemacht bzw. was ist das Problem?

kk · 11. Oktober 2014

Das Problem ist, dass bei "klassischem" SSL erst der SSL-Handshake stattfindet, und dann der HTTP-Request erfolgt. Mit anderen Worten: pro SSL-Zertifikat braucht(e) man eine eigene IP-Adresse; man kann keinen "anderen" Content zuverlässig auf der selben IP hosten.
SNI verschafft da theoretisch Abhilfe - funktioniert allerdings nicht mit dem IE unter Windows XP u.ä. (was immerhin noch rund 10% der Internetnutzer betrifft).

Legen Sie die Datei /etc/apache2/conf.d/sni mit folgendem Inhalt an:

Code

<IfModule mod_ssl.c>
SSLStrictSNIVHostCheck on
</IfModule>

Starten Sie Apache danach neu. Mit dieser Einstellung (SSLStrictSNIVHostCheck on) sollten dann nur noch "richtige" SNI-Zugriffe durchgestellt werden. Beachten Sie aber bitte, dass eben noch nicht alle Browser SNI beherrschen.

Viele Grüße

-Klaus Keppler

web2s · 11. Oktober 2014

Vielen dank für die schnelle Rückmeldung Herr Keppler.
Der Problematik SNI bin ich und mein Kunde sich bewusst.
Leider brachte das anlegen der Datei und ein /etc/init.d/apache2 restart keinen Erfolg.
Muss man noch irgendwo ein Menü öffnen um die Config neu zu schreiben?

antondollmaier · 11. Oktober 2014

Völlig normales Verhalten, lässt sich auch nur über getrennte IPs lösen (soweit ich weiß).

Die Domain von Kunde B hat auf Port 443 (HTTPS) keinen vHost, weshalb der Apache einen Fallback auf den ersten "passenden" vHost macht - das ist nun offenbar die HTTPS-Domain des Kunden A.

Confixx löst es so, dass es einen Default-vHost gibt, der auf Confixx geht - und immer verwendet wird, wenn für eine Seite SSL nicht angezeigt wird. Gibt aber trotzdem die SSL-Warnung.

andreas · 12. Oktober 2014

Zitat von kk
Das Problem ist, dass bei "klassischem" SSL erst der SSL-Handshake stattfindet, und dann der HTTP-Request erfolgt. Mit anderen Worten: pro SSL-Zertifikat braucht(e) man eine eigene IP-Adresse; man kann keinen "anderen" Content zuverlässig auf der selben IP hosten.
SNI verschafft da theoretisch Abhilfe - funktioniert allerdings nicht mit dem IE unter Windows XP u.ä. (was immerhin noch rund 10% der Internetnutzer betrifft).

Legen Sie die Datei /etc/apache2/conf.d/sni mit folgendem Inhalt an:
Code
<IfModule mod_ssl.c>
SSLStrictSNIVHostCheck on
</IfModule>
Starten Sie Apache danach neu. Mit dieser Einstellung (SSLStrictSNIVHostCheck on) sollten dann nur noch "richtige" SNI-Zugriffe durchgestellt werden. Beachten Sie aber bitte, dass eben noch nicht alle Browser SNI beherrschen.

Viele Grüße

-Klaus Keppler
Alles anzeigen

Hallo Herr Keppler,
auch bei mir bringt der o.g. Code keine Veränderung

kk · 13. Oktober 2014

Zitat von andreas

auch bei mir bringt der o.g. Code keine Veränderung

Was für eine Veränderung erwarten Sie denn?
Mit dieser Einstellung (SSLStrictSNIVHostCheck=on) werden keine Inhalte von "fremden" Seiten mehr angezeigt, falls der Browser kein SNI unterstützt bzw. falls er über einen "falschen" Hostnamen auf den Server zugreift (in diesem Fall antwortet Apache mit einem 403 - Forbidden).
Dass dem Besucher aber auch in diesem Fall irgendein SSL-Zertifikat präsentiert wird lässt sich nicht ändern (siehe oben). Wenn ein Browser eine SSL-Verbindung anfordert, dann muss der Server ja mit irgendwas antworten. Die einzige saubere Lösung besteht eben darin, SSL-Websites auf eine separate IP-Adresse zu legen. Das hat nichts mit LiveConfig zu tun, sondern mit den technischen Grundlagen von SSL.

kk · 13. Oktober 2014

Nachtrag: ich hatte das nur mit dem IE unter Windows XP getestet. Wenn ein Browser mit SNI-Unterstützung auf den Server zugreift, kommt tatsächlich die Seite vom zuerst konfigurierten SSL-vHost - trotz der SSLStrictSNIVHostCheck-Einstellung.
Wir werden LiveConfig so anpassen, dass bei SSL auf Shared IPs (=SNI) automatisch ein selbst-signiertes Zertifikat erzeugt wird, welches dann auf die Standard-Fehlerseite ("Diese Domain ist nicht verfügbar...") verweist. Müsste im Laufe dieses Tages fertig sein.

Viele Grüße

-Klaus Keppler

antondollmaier · 13. Oktober 2014

Zitat von kk

Wir werden LiveConfig so anpassen, dass bei SSL auf Shared IPs (=SNI) automatisch ein selbst-signiertes Zertifikat erzeugt wird, welches dann auf die Standard-Fehlerseite ("Diese Domain ist nicht verfügbar...") verweist. Müsste im Laufe dieses Tages fertig sein.

yeah!

Ich mag diese "Mini"-Updates

andreas · 13. Oktober 2014

Zitat von kk

Nachtrag: ich hatte das nur mit dem IE unter Windows XP getestet. Wenn ein Browser mit SNI-Unterstützung auf den Server zugreift, kommt tatsächlich die Seite vom zuerst konfigurierten SSL-vHost - trotz der SSLStrictSNIVHostCheck-Einstellung.

Viele Grüße

-Klaus Keppler

Ah, danke. Das meinte ich. Hatte mich nur gewundert gehabt. Danke für die Rückmeldung!

andreas · 14. Oktober 2014

Zitat von kk

Nachtrag:
Wir werden LiveConfig so anpassen, dass bei SSL auf Shared IPs (=SNI) automatisch ein selbst-signiertes Zertifikat erzeugt wird, welches dann auf die Standard-Fehlerseite ("Diese Domain ist nicht verfügbar...") verweist. Müsste im Laufe dieses Tages fertig sein.

Viele Grüße

-Klaus Keppler

Hallo Herr Keppler,
wird es dafür ein Stable-Update geben oder kommt dies erst in die Preview?

viele Grüße

solidius · 26. November 2014

Guten Abend Herr Keppler,

leider besteht bei mir dieses Problem auch nach dem Update auf 1.7.5-r3127 noch immer.
Die Domain https://lokalbote-hamburg.de/ hat eigentlich keine SSL Konfiguration. Trotzdem ist über diese URL der Inhalt der Domain http://linkbuy.info.

Ich habe bereits bei der betreffenden Domain mal die Apache Konfig neu schreiben lassen. Bisher ohne erfolg wie man sehen kann.

Wie kann ich dieses Problem nun beheben. Es sind div Domains bei mir betroffen, gerade im Bezug auf die SSL Offensive von Google wird nun massenhaft falscher Content von Google indiziert. Was gerade bei Seiten mit einem hohen Pagerank sehr zum Nachteil werden kann.

kk · 26. November 2014

Noch mal: Inhalte, die nur per HTTP erreichbar sind, sollten am besten immer nur auf einer IP betrieben werden die nicht mit SSL genutzt wird. Das war schon immer so und wird auch immer so bleiben.

Unabhängig davon: bearbeiten Sie bitte im LiveConfig einfach irgend eine IP-Gruppe (z.B. irgendwas am Namen einer IP-Gruppe ändern - das reicht schon). Danach erzeugt LiveConfig automatisch auch die Default-vHosts neu und sollte diesen ein eigenes Standard-SNI-Zertifikat zuweisen.

Viele Grüße

-Klaus Keppler

Jetzt mitmachen!