Apache und mehrere SSL-Zertifikate?

[coltseavers]

Hallo zusammen,

ich suche derzeit nach einer Lösung, wie ich auf dem Apache2.2 unter Squeeze mehrere SSL-Zertifikate für verschiedene Onlineshops hinterlegen kann.
Habe gelesen, dass das wohl eigentlich nicht ohne Weiteres geht.

Da gibts dann natürlich die Option mit den Multi-Domain-Zertifikaten.
Was mich daran stört: Wenn man das so einrichtet für z.B. 5 Onlineshops und einen davon dann besucht und sich das Zertifikat anzeigen lässt, kann man darin auch die URLs der anderen Onlineshops - soweit ich weiss - sehen. Sehe ich das richtig, oder ist das ein Irrtum?
Wenn das richtig ist, wäre das für mich auch nicht gerade eine Traumlösung, weil die Kunden voneinander natürlich nichts wissen sollen.

Dann gibts die Option mit SNI
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
Gefällt mir aber auch nicht, weil da die alten Browser nicht mitspielen.
Denn man will ja schliesslich keine potentiellen Käufer von vornherein aussperren.

Frage also: gibts eine Alternative?
Mit weiteren IPs, die auf den Server laufen, wäre das doch kein Problem, oder gibts da irgendwelche Besonderheiten/Einschränkungen/Stolpersteine?

Gruß & vielen Dank vorab,
Colt

[Joe User]

Mehrere IPs wäre eine Lösung, allerdings ist SSL heutzutage für die RIRs (hier wohl RIPE) kein Grund mehr (es gibt ja SNI), weitere IPs zu genehmigen. Ob Du also ausreichend IPs von Deinem Anbieter zugeteilt bekommst (er muss das gegenüber der RIPE rechtfertigen), ist eher fraglich.

Nur so als Hinweis abseits einer echten Problemlösung.

[Roger Wilco]

Sehe ich das richtig, oder ist das ein Irrtum?

Das ist richtig. Alle Domains, welche von dem Zertifikat abgedeckt werden sollen, müssen in diesem natürlich als Common Name (CN) oder SubjAltName aufgeführt werden.

Eine früher öfter genutzte Variante wäre ein "SSL-Proxy", bei dem eine Domain auf deinem System ein Zertifikat bekommt und die anderen Domains dann durch diese "getunnelt" werden.

Zum Beispiel ist ein Zertifikat für example.com vorhanden und die Seite example.net und example.org wären dann durch https://example.com/ssl/example.net/ und https://example.com/ssl/example.org/ erreichbar. Das ist allerdings fast noch unschöner, als alle anderen Lösungen.

Ich persönlich würde ja dazu übergehen, nur noch SNI zu nutzen. Man will ja nicht ewig auf antike Software Rücksicht nehmen…

[daemotron]

Da gibts dann natürlich die Option mit den Multi-Domain-Zertifikaten.
Was mich daran stört: Wenn man das so einrichtet für z.B. 5 Onlineshops und einen davon dann besucht und sich das Zertifikat anzeigen lässt, kann man darin auch die URLs der anderen Onlineshops - soweit ich weiss - sehen. Sehe ich das richtig, oder ist das ein Irrtum?

Kein Irrtum, das siehst Du absolut korrekt. Man muss zwar schon aktiv nach den Informationen suchen (Unter Firefox Zertifikat Anzeigen => Details und dann im Zertifikatsbaum den richtigen Knoten rauswühlen), aber auffindbar ist die Information eben.

Mit weiteren IPs, die auf den Server laufen, wäre das doch kein Problem, oder gibts da irgendwelche Besonderheiten/Einschränkungen/Stolpersteine?

Technisch gesehen ist die Einrichtung mit mehreren IPs kein Problem. Grundsätzlich verstößt dieses Vorgehen zwar auch gegen die SSL-Spezifikation, aber zumindest mit Apache ist es bekanntermaßen kein Problem, da für ein SSL-Handshake immer das Zertifikat verwendet wird, das im ersten virtuellen Host mit der gerade getriggerten IP angegeben ist.

[daemotron]

Ich persönlich würde ja dazu übergehen, nur noch SNI zu nutzen. Man will ja nicht ewig auf antike Software Rücksicht nehmen…

Hmm, wenn auf Antiquitäten keine Rücksicht genommen werden muss, dann lieber gleich IPv6 nehmen und kranke (weil am Protokoll vorbeihexende) Amendments wie SNI meiden...

[Roger Wilco]

Zwar unterstützt sogar Windows XP IPv6 (im Gegensatz zu SNI mit dem IE), aber bis zur flächendeckenden Einführeung desselben wird es wohl noch länger dauern.

Wenn SNI nicht unterstützt wird, kann man ggf. einen aktuelleren Browser installieren, der das kann. Wenn IPv6 nicht unterstützt wird, müsste man erstmal einen Provider finden, der das anbietet. ;)

[daemotron]

<ot>
*g* nimm's mir nicht übel, ich rege mich halt nur zu gerne über die kaputte Implementierung von SSL auf Seiten der Browser (und Mailclients) auf. Das SSL Handshake Protokoll verlangt nämlich zu keiner Zeit, dass der Domain Name zur Identifikation des Remote Hosts herangezogen wird - es könnte auch etwas anderes im CN stecken, z. B. die IP oder ein per DNS veröffentlichter Fingerprint oder wasweisich. Theoretisch könnte auch ein anderes Attribut überprüft werden, es muss nicht mal zwangsweise der CN sein...
</ot>

[coltseavers]

...was passiert eigentlich, wenn der Browser SNI nicht unterstützt, und eine Seite von einem Server aufgerufen wird, der SNI einsetzt?

Kommt ne Fehlermeldung, oder wird die Seite ohne Verschlüsselung ausgeliefert?

[Roger Wilco]

Es kommt eine Fehlermeldung im Client (da das Zertifikat ggf. nicht passt) und je nach Webserver wird der falsche VirtualHost ausgeliefert.

Beim Apache httpd normalerweise der erste (HTTPS-) VirtualHost. Es ist also ein Fallback zum Verhalten von nicht-namensbasierten VirtualHosts (siehe Doku).