RootForum Community

Hi,

eigentlich wollte ich eine Kostengünstige Lösung unsere Domains / Subdomains durch SSL Zertifikate zu "sichern".
Jetzt fällt mir da nur ein blöder umstand auf.


Das jeweilige SSL Zertifikat (ich spreche dabei von einem 123 SSL123 Certificate) bindet sich ja an eine IP. Kann ich aber leider nicht direkt an eine Domain binden.

Auf einer ip 123.123.123.123 lauschen aber alle Domains der Firma.

Welches Zertifikat wäre denn hier geeignet, um alle (ich spreche von ca. 4 Domains zzgl n Subdomains) mit einem gültigen unbemängeltem SSL Zertifikat zu versehen? Ein Wildcard scheint mir etwas zu teuer für die Anforderung.

Andere IPs sind derzeit leider nicht frei.

Wie sieht es denn mit SubjectAlternativeName (vom Typ DNS) aus? Ich nutze das für meinen Reverse Proxy mit einem Zertifikat von CACert - dadurch kann ich SSL für alle Domains anbieten, ohne Unmengen von IP-Adressen dafür zu blockieren...

Ich weiß allerdings, dass das nicht von allen CAs angeboten wird und teilweise deftige Aufpreise nach sich zieht.

Du meinst sowas wie das Multidomain Zertifikat von psw.net?

https://www.psw.net/ssl-zertifikate.cfm

Siehe spalte Bronze?

<OT>
Da es derzeit keine vertrauenswürdige CA gibt, würde ich SNI mit selbstsignierten Zertifikaten einsetzen...
</OT>

ddm3ve wrote:Du meinst sowas wie das Multidomain Zertifikat von psw.net?

https://www.psw.net/ssl-zertifikate.cfm

Siehe spalte Bronze?

Ja, scheint so als hätten die Multi-Domain mit SAN umgesetzt. Man muss dabei allerdings im Kopf behalten, dass nicht jeder Webserver damit kann. Apache funktioniert (definitiv), IIS soll damit angeblich auch umgehen können. Mit Lighty und Nginx habe ich es noch nicht probiert.

@Joe User: Klar, self signed ist aus meiner Sicht (also aus der des Ausstellers) am vertrauenswürdigsten - nur erklär das mal den DAUs, die mit dem roten Panik-Geblinke in Firefox nix anfangen können...

P. S. SNI ist eine zweischneidige Geschichte. Einen echten Vorteil gegenüber SAN sehe ich nicht direkt (es sei denn, man setzt kommerzielle Zertifikate ein, dann kann man auf die teureren Multi-Domain oder Wildcard-Zertifikate verzichten). SNI erfordert aber einen SNI-fähigen Client. Gerade ältere oder exotische Browser unterstützen das nicht. Bevor man das also im kommerziellen Umfeld einführt, muss man sich vergewissern, dass der Kunde nicht an einen SNI-unfähigen Browser (wie etwa den IE6) gekettet ist. In Firmen geistert das Teil immer noch rum...

Genau das ist das Problem mit den selbst signierten, bisher hätte mir das auch gereicht.

Aber im Kundenshop tendiert der Umsatz nahezu zu 0% wenn das Zertifikat nicht stimmt. Schlimmer aber sind auch noch die meisten Mailclients, da macht man keinen Kunden mit glücklich, wenn diese laufend die Zertifikate erneut akzeptieren müssen. importieren hat nicht gereicht.

Hallo,

nun ja, das ist ja der einzige Vorteil, den die großen CA wie VeriSign etc gegenüber selbst erstellten Zertifikaten haben: sie lösen keine Warnung aus im Browser.
Und wie Du selbst schon sagst: in kommerziellen Systemen wie Onlineshops etc kann man natürlich auch nicht vom User erwarten, Zertifikatswarnungen zu akzeptieren. Denn die Warnungen sind ja auch gut und richtig!
Wie sonst könnte einem nach einer Manipulation (z.B. Umleitung der Seite) auffallen, dass hier was nicht stimmt?! Von daher sehe ich das etwas anders als daemotron - das Panik-Geblinke hat schon seinen Sinn und hat nichts mit DAUs zu tun...

Bei SAN-Zertifikaten (Multi-Domain-Zertifikaten) solltest Du bedenken, dass in dem Zertifikat alle Domains nachzulesen sind, die darüber abgesichert sind.
Beispiel:
Angenommen Du hast Onlineshop1.de und Onlineshop2.de.
Surfst Du im Onlineshop1.de kannst Du Dir das Zertifikat anzeigen lassen und siehst darin, dass Onlineshop2.de ebenfalls mit diesem Zertifikat abgesichert ist. Wenn das also Kunden sind, die nichts voneinander wissen sollen, wäre das wohl zu vermeiden. Ebenso könnte Deine Konkurrenz auch leicht mal nachschauen, was Du sonst noch für Projekte am Start hast...

Wenn man selbstsignierte Zertifikate in E-Mail-Clients importieren möchte, klappt das durchaus! Aber auch dabei kann man Fehler machen. Ich empfehle das Root-Zertifikat der eigenen CA in den Mailclient zu importieren - dann kannst Du ggfs auch mal andere Zertifikate ausstellen ohne dann gleich wieder an den Mailclients was importieren zu müssen.


Eigentlich wäre also SNI nicht schlecht
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
Denn das wäre eine technisch saubere Lösung, um mit einer IP mehrere verschiedene SSL-Zertifikate zu nutzen.
Aber wie die Vorredner schon gesagt haben, spielen da nicht alle Browser mit. Es ist übrigens nicht nur die IE6 - selbst der IE8 unter XP kann das nicht...
http://de.wikipedia.org/wiki/Server_Nam ... on#Browser

Nach meinem Kenntnisstand bleiben somit nur noch folgende Möglichkeiten: mehrere IPs einsetzen bzw einzelne Domains evtl auf kleine vserver oder externe Hostingpakete auszulagern.

coltseavers wrote:Von daher sehe ich das etwas anders als daemotron - das Panik-Geblinke hat schon seinen Sinn und hat nichts mit DAUs zu tun...

Na ja, der Durchschnitts-User interpretiert da sehr einfach - grün = gut, rot = böse. Diese Interpretation ist aber schlicht murks, denn die Symbolgebung basiert auf dem Browser bekannten CA-Zertifikaten (teilweise sogar nur CA-Zwischenzertifikaten), und nicht darauf, ob eine Verbindung manipuliert wurde oder nicht.

Kaum jemand dürfte sich das Zertifikat genauer ansehen und Abweichungen in den Attributen prüfen (z. B. O=XY-Bank statt O=XY Bank), zumal oft auch (korrekte) Vergleichsinformationen gar nicht vorliegen. Bei einigen CAs wäre es (entsprechende kriminelle Energie vorausgesetzt) nicht weiter schwierig, mit (eventuell gefälschten) HR-Auszügen ein Zertifikat zu bekommen, dessen O- und CN-Attribut sich kaum von denen einer Bank oder eines Shops unterscheiden. Gegen diese Form des Angriffs helfen die roten Warnungen im Browser aber leider genau gar nichts.

Die Chancen, dass eine Warnung nur durch das technische Umfeld ausgelöst wurde, sind daher IMHO genauso groß wie die Wahrscheinlichkeit, dass eine "grüne" Seite trotzdem manipuliert werden könnte.

coltseavers wrote:Bei SAN-Zertifikaten (Multi-Domain-Zertifikaten) solltest Du bedenken, dass in dem Zertifikat alle Domains nachzulesen sind, die darüber abgesichert sind.

In der Tat ein interessanter Punkt. Danke für den Hinweis; bei mir war das bisher kein relevanter Aspekt. Es gibt natürlich noch andere Möglichkeiten, an diese Informationen zu gelangen (WHOIS-Records von Domains, MX-Records, die auf denselben Mailserver verweisen, etc.), aber so bequem frei Haus bekommt man sie natürlich aus dem Zertifikat am einfachsten.

coltseavers wrote:Eigentlich wäre also SNI nicht schlecht
http://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
Denn das wäre eine technisch saubere Lösung, um mit einer IP mehrere verschiedene SSL-Zertifikate zu nutzen.

SNI ist IMHO eine gute technische Lösung, es kommt halt auf die Clientel drauf an, ob man sie einsetzen kann. In Umgebungen, in denen man die eingesetzten Browser kontrollieren kann (Intranet o. ä.), sehe ich keine Gründe, SNI nicht einzusetzen. Für Shops halte ich es aber für derzeit nicht einsetzbar - dazu ist Win XP einfach noch zu weit verbreitet.