ich weiß nicht, ob dies hier das richtige Unterforum ist, aber so sei es nun einmal.
Ich bin leider in der Serververwaltung nicht so firm. Ich habe 2 ssl.crt Dateien für 2 Domains die auf einem Server laufen. Der JBoss (Wildfly) funktioniert über http ohne Probleme. Mit https funktioniert es nun für eine Domain mit Hilfe von:
du kannst pro IP und Port-Kombination nur ein einziges SSL Zertifikat verwenden. Virtuelle Hosts, die auf dem selben Server laufen, sind also technisch nicht möglich.
Ursache dafür ist, dass der virtuelle Host nicht aufgelöst werden kann, weil dieser erst nach dem Aufbau der verschlüsselten Verbindung ersichtlich ist. Und für den Handshake muss schon das richtige Zertifikat verwendet werden.
Die einzige Lösung ist, dem Server eine weitere IP zu spendieren, sofern beide Hosts über den selben Port angesprochen werden sollen (was wahrscheinlich ist).
Beim JBoss kann ich ein Zertifikat angeben (als PCKS12 oder JKS). Ich habe nun 2 Subdomains (domain1@mydomain.com und domain2@mydomain.com). Das aktuelle Zertifikat ist für einen Server ausgestellt. Der andere meckert nun natürlich, dass er das Zertifikat nicht kennt.
Nein, das gilt für HTTPS, unabhängig vom Server:
[ol][li]SSL Verbindung aushandeln (dazu muss der Server schon ein Zertifikat auswählen)[/li][li]HTTP (an dieser Stelle für den Server dann ohne „S“) Header lesen (dort steht der virtuelle Host drin)[/ol][/li]
Die Entscheidung anhand eines virtuellen Hosts, welches Zertifikat zu wählen ist, könnte also erst getroffen werden, nachdem die Daten schon entschlüsselt sind. Und das geht natürlich nicht.
Daher kann man dem Server als Entscheidungsgrundlage nur die im TCP-Header bekannten Informationen nutzen zur Zertifikatswahl nutzen. Die IP und den Port.
Ich hab heute ja schon in einem anderen Thread geschrieben, dass ich mich mit JavaEE noch nicht sonderlich intensiv beschäftigt habe, daher kann ich dir nur sagen, dass es „sicherlich irgendwie geht“, indem du dem Server zwei IP-Adressen zuweist.
Ggf. findet man bei google ja was mit Stichworten wie „wildfly/jboss multiple ip addresses ssl“.
Die in der Apache-Doku aufgeführte Lösung sollte aber auch funktionieren, wenn die Voraussetzungen gegeben sind, weil du dann nur ein (Wildcard-)Zertifikat benötigst und der Server kein Zertifikat wählen muss.
*** Edit ***
Eine zweite IP-Adresse hinzufügen und (hier ist die Problematik ) den AS so konfigurieren, dass er das richtige Zertifikat anhand der IP-Adresse wählt.
Die Domains müssen im DNS natürlich auch auf die passende IP-Adresse verweisen.
Ich möchte aber eigentlich nicht 2 Zertifikate, sondern ein Zertifikat, welches für 2 Domains gültig ist. Dagegen sollte eigentlich nichts sprechen, oder? Das bekommen kostenpflichtige Anbieter anscheinend ja hin.
Ja, ein Multidomain-Zertifikat ist wahrscheinlich die einfachste Lösung. Das kann man natürlich nur dann machen, wenn es nicht stört, dass beide Domains im Zertifikat auftauchen, also die beiden Domains auch dem selben Betreiber gehören.
Ja, und da weiß ich leider nicht, wie ich den Keystore erweitern kann. Oder geht das in der Regel nur über den Anbieter? startssl.com bietet Multidomain-Zertifikate gegen Geld an. Ich hoffe aber, dass ich einfach 2 Zertifikate “mergen” kann. Geht das?
Das kann nicht gehen, weil das Zertifikat dadurch ungültig würde (das Zertifikat ist ja signiert und die Signatur wird nach einer Veränderung ungültig, damit auch das ganze Zertifikat).
Ich merke auch, dass das nicht gehen kann. Eigentlich schade. Da muss ich wohl doch Geld in die Hand nehmen. Ein selbstsigniertes Zertifikat reicht leider nicht aus.
Ich glaube, ich bringe einfach einen eigenen Browser auf den Markt, der erst einmal nur mein Zertifikat als sicher erklärt. Wenn dann 90% der Weltbevölkerung meinen Browser nutzen, ermögliche ich gegen viel Geld die Nutzung eigener Zertifikate…
Man kann sehr wohl zwei SSL-Zertifikate für zwei unterschiedliche Domains auf einer IP-Adresse laufen lassen. Dazu müssen sowohl Server und Client SNI unterstützen. Wir haben das erfolgreich mit nginx laufen und aktuelle Browser haben keine Probleme damit. Kompatibilitäten sind u.a. in der verlinkten Seite angegeben. Da muss man einfach abwägen. Grundsätzlich kann man aber schon sagen, dass gängige Browser und Betriebssysteme, die keinen SNI-Support haben, auch keine Sicherheitsupdates erhalten und damit sowieso von deren Verwendung dringend abzuraten ist.
Wow, ich höre zum ersten Mal davon. Ich habe die Kompatibilitätsliste noch nicht im Detail geprüft, aber Support für Browser der Generation „Windows XP“ kann man sicherlich fallen lassen.
Abgesehen davon kann man bestimmt auch ein unverschlüsseltes Fallback für diese Browser einrichten.
Ich hoffe nur, dass @Sym aufgrund meiner Fehlinformationen noch kein neues Zertifikat gekauft hat
*** Edit ***
:twisted: wenn ich den von mir selbst geposteten Link besser gelesen hätte, hätte ich ganz oben gesehen:
Also see SSL with Virtual Hosts Using SNI
*** Edit ***
Ich habe noch ein wenig recherchiert und es scheint, dass Java erst ab Version 8 serverseitig SNI kompatibel ist.
Man wird also um einen Reverseproxy wahrscheinlich vorerst nicht herum kommen.
Nein, ich habe mir noch kein Zertifikat gekauft. Aber SNI scheint interessant. Ich habe aber auch noch keine Möglichkeit zur Nutzung von Java 7 gefunden. Mal sehen, was sich da ergibt.
[QUOTE=cmrudolph]Wow, ich höre zum ersten Mal davon. Ich habe die Kompatibilitätsliste noch nicht im Detail geprüft, aber Support für Browser der Generation „Windows XP“ kann man sicherlich fallen lassen.
Abgesehen davon kann man bestimmt auch ein unverschlüsseltes Fallback für diese Browser einrichten.[/quote]
Was zumindest im nginx hilft, ist die Seite, die auf jeden Fall korrekt gesichert werden soll, als erstes anzugeben oder die entsprechende listen-Direktive mit default_server zu markieren. Dann erhalten SSL-Clients, die ohne SNI arbeiten eben das erste Zertifikat. Wir haben bei uns Entwicklungs- und Demo-Umgebung hinter einer IP. Die Entwicklungs-Infrastruktur ist nur für uns relevant und wir verwenden nur aktuelle Systeme, von daher sind die Kundensysteme als Default eingetragen.
Ich muss aber zugeben, dass es Probleme beim Tooling gibt. Obwohl Java 7 angeblich alles unterstützt, haben wir leider Probleme mit Jenkins/Nexus, weil immer das falsche Zertifikat genommen wird. Auch mit Maven auf den lokalen Maschinen ist das manchmal Hit and Miss. Vielleicht wird das mit Java 8 besser.
Ich hoffe nur, dass @Sym aufgrund meiner Fehlinformationen noch kein neues Zertifikat gekauft hat
Kann man zum Glück oft zurückgeben.
Ich habe noch ein wenig recherchiert und es scheint, dass Java erst ab Version 8 serverseitig SNI kompatibel ist.
Man wird also um einen Reverseproxy wahrscheinlich vorerst nicht herum kommen.
Ist imho so oder so sinnvoll.
SNI ist transparent und entweder an oder aus. Bei Java 7 muss man es explizit ausschalten, sonst ist es an.
Ja, sehe ich auch so. Zumindest mit Blick auf zukünftiges loadbalancing.
Da ich Tomcat nutze, hätte ich eigentlich gerne AJP verwendet. Aber ein vollwertiger Apache httpd erscheint mir etwas übergewichtig als Reverseproxy bzw. SSL-Gateway (da müsste man mal Performancetests machen).
Ein nginx könnte AJP nur mit einer selbst zu kompilierenden Erweiterung, die mir bei etwas genauerer Betrachtung als nicht sonderlich liebevoll entwickelt und auch nicht so funktionsreich erscheint. Alternativ bleibt nur http für die Verbindung von nginx zum Backend, was den negativen Beigeschmack hat, dass Arbeit doppelt gemacht wird.
Auch Punkte wie Session-Stickiness könnten noch Probleme ergeben, das ließe sich mit einem Apache mit mod_jk wahrscheinlich sehr einfach lösen, aber mit nginx geht es wahrscheinlich auch irgendwie.
Lighttpd wäre ggf. auch noch eine Option. Da sieht die AJP-Erweiterung etwas weniger stiefmütterlich aus.
Ganz abgesehen davon, werden abgesehen von mod_jk und mod_proxy_ajp offiziell keine AJP Clients unterstützt.
) den AS so konfigurieren, dass er das richtige Zertifikat anhand der IP-Adresse wählt.
Eigentlich schade. Da muss ich wohl doch Geld in die Hand nehmen. Ein selbstsigniertes Zertifikat reicht leider nicht aus.
