TLS-Verschlüsselung - Frage zu Zertifikaten

[coltseavers]

Servus,

kleine Frage zur Verschlüsselung:
Wenn man Webseiten per https verschlüsselt, prüft der Browser ja, ob er die CA kennt. Wenn das Zertifikat von z.B. VeriSign signiert ist, wird es akzeptiert, wenn es von Anton Müller signiert ist, kommt die Nachfrage, ob es angenommen werden soll.

Frage nun: Verhält sich das bei E-Mail-Clients absolut identisch?
Kann man für eine E-Mail-Verschlüsselung ebenfalls auf Zertifikate von trusted CAs zurückgreifen, um beim Client keine Nachfrage auszulösen?
Greifen die auf die Browser-Informationen zurück, oder haben die eine eigene Liste von CAs, denen sie trauen?
Ich möchte nämlich nicht, dass man im Client (wenn auch nur einmalig) ein Zertifikat "manuell" speichern/akzeptieren muss - das soll automatisch ablaufen.

Danke & Gruß,
Colt Seavers

[daemotron]

Mailclients verhalten sich unterschiedlich. Outlook und Windows Mail greifen auf den CA-Speicher des Internet Explorers zurück, Thunderbird hingegen hat einen eigenen Zertifikatspeicher, ebenso Claws Mail. Gerade unter Linux/Unix gibt es jedoch noch weitere Spielarten, z. B. das zentrale CA-Verzeichnis (meist /etc/ssl/certs) oder Mozillas NSS Shared DB. Evolution und KMail greifen auf die globalen Krypto-Tools der jeweiligen Desktop-Umgebung zurück (Seahorse bzw. Kleopatra).

[EdRoxter]

Wenn du generell und grundsätzlich nicht willst, dass die Clients das Zertifikat erst akzeptieren müssen, musst du zwangsläufig eins von einer CA benutzen, die von allen gängigen Clients als vertrauenswürdig eingestuft wird - also Thawte, VeriSign usw.

Wie meine Vorposter schon sagten: Wenn du solch ein Zertifikat schonmal für eine Domain hast, dann kannst du es ohne Probleme auch für SMTP mit TLS und IMAPs/POP3s benutzen, solang die User über die selbe Domain zu den Maildiensten verbinden wie der CN des Zertifikats - sollte klar sein.

[nyxus]

Ich habe mein Zertifikat von Commodo (oder so ähnlich, gibt noch ein paar weitere günstige Anbieter), das kostet nur ein Bruchteil wie von den "Großen" und läuft ohne Probleme mit Lighty, Courier und Postfix. Thunderbird/Firefox, Opera, IE und Safari/Mail.app haben damit auch keine Probleme.

[EdRoxter]

Zertifikate werden immer daraufhin überprüft, ob CN mit Domain übereinstimmt. Da macht schon ein fehlendes oder hinzugekommenes "www." am Anfang Probleme (außer bei Wildcard-Zertifikaten natürlich, obwohl die ja eigentlich mehr eine Art etablierter Workaround sind).
Entsprechend meckert der Browser natürlich auch, wenn auf eine deiner Kundendomains (VHost) auf den Server zugegriffen wird, der aber auf der IP das einzig vorhandene Zertifikat mit deiner eigenen Domain als CN zurückgibt. Halbwegs gangbare Lösung wäre unter dem Stichwort SSL-Proxy zu suchen.

StartSSL bietet übrigens derzeit seine Level 2-Zertifikate, die von vielen Browsern als vertrauenswürdig erkannt werden, für ein Jahr kostenlos an. Das wäre zum Rumtesten schonmal recht praktisch.

[nyxus]

StartSSL bietet übrigens derzeit seine Level 2-Zertifikate, die von vielen Browsern als vertrauenswürdig erkannt werden, für ein Jahr kostenlos an. Das wäre zum Rumtesten schonmal recht praktisch.

Über StartSSL hat Heise vor kurzem berichtet:
http://www.heise.de/security/artikel/SS ... 80221.html
Irgendwo habe ich gelesen, das die Bedingung für die kostenlosen Zertifikate wäre, das die einem die Schlüssel berechnen. Aber lt. Artikel ist das doch optional. Trotzdem aufpassen, sonst kann der Mossad mitlesen ... ;-)

[Joe User]

(außer bei Wildcard-Zertifikaten natürlich, obwohl die ja eigentlich mehr eine Art etablierter Workaround sind)

Und mit denen nicht alle Clients (unter Anderem der MSIE und MSOutlook) klarkommen und das Zertifikat dann gar nicht akzeptieren...

[EdRoxter]

Genau das wollte ich mit "etabliertem Workaround" ausdrücken - ein Euphemismus für "Denk besser nicht einmal daran, es zu benutzen". ;)

[nyxus]

Und mit denen nicht alle Clients (unter Anderem der MSIE und MSOutlook) klarkommen und das Zertifikat dann gar nicht akzeptieren...

könnte man als erzieherische Maßnahme ansehen. :-)

[EdRoxter]

SSL Proxy und am besten unter der selben Domain auch POP3s und SMTPs bzw. SMTP mit STARTTLS-Option laufen lassen - ja, darauf läuft's hinaus.
Soll den Kunden dann selbst überlassen sein, ob sie SSL nutzen wollen oder nicht. Und wenn sie ein eigenes Zertifikat wollen, dann biete ihnen halt ein Paket mit eigener IP und Zertifikat an und schlag's auf die Rechnung drauf. Das ist ganz übliches Geschäftsgebahren.

[daemotron]

Zertifikate werden immer daraufhin überprüft, ob CN mit Domain übereinstimmt. Da macht schon ein fehlendes oder hinzugekommenes "www." am Anfang Probleme (außer bei Wildcard-Zertifikaten natürlich, obwohl die ja eigentlich mehr eine Art etablierter Workaround sind).

Nicht ganz richtig. Die SSL-Spezifikation schreibt vor, zuerst einen Abgleich mit Subject Alternative Names vom Typ "DNS" zu machen. Bei einem Match gilt das Zertifikat als verifiziert; gibt es keinen Match oder sind keine SubjectAltName Informationen eingebettet, wird als Fallback der CN geprüft (mit den von Dir beschriebenen Nebenwirkungen).

Die Anzahl der einbettbaren SubjectAltName-Informationen ist nicht begrenzt (außer durch die Policy der CA; die wollen schließlich für jede Info, die sie vorher verifizieren müssen, auch Kohle sehen). Technisch ist das also die beste (und eleganteste) Lösung, um bei nur einer IP oder nur einem lauschenden Dienst SSL oder TLS sauber auch unter verschiedenen FQHNs anbieten zu können.

[EdRoxter]

Ja, stimmt, wäre möglich. Hatte ich sogar schonmal von gehört, aber war mir wegen der Preise eh egal. ;)

Bei Comodo, die schon recht günstig sind, kostet ein MultiDomain-Zertifikat rund 90 Tacken im Jahr mit 3 Domains inklusive, für jede weitere Domain, die du via SubjectAltName dazu absichern willst, nochmal rund 30-50 Euro im Jahr mehr. Und das sind nur die Preise, die ich gerade auf die Schnelle über meinen favorisierten Reseller gefunden hab - teilweise sind die im Direktvertrieb noch teurer.

[EdRoxter]

Thawte (Strato verkauft die) bietet m.W. keine MultiDomain-Certs.

Edit meint, dass ich warte, bis du wieder PM empfangen kannst. ;)

[coltseavers]

Meine Ansicht ist die folgende:
Wenn ich einen Mailserver habe (mail.server1.de)
und ich habe kundendomains kunde1.de, kunde2.de, kunde3.de

dann kann ich doch die mails der kundendomains über meinen mailserver (bei postfix: virtuelle mailboxen) laufen lassen. das heisst: jeder kundenmailclient verbindet sich mit nur mit dem einen host mail.server1.de zum senden und empfangen von mails.
Dann brauch ich auch nur ein Zertifikat, nämlich für CN mail.server1.de
und es kann für alle kunden benutzt werden. für welche domains dann die mails darüberlaufen ist dem Zertifikat egal, hauptsache der CN stimmt.
bei zahlreichen kunden-domains kann man sich dann mal ein einzelnes zertifikat aneignen.
bei mir läuft es nun so problemlos.

günstige zertifikate gibts übrigens bei CA godaddy.com

[EdRoxter]

So isses. Wenn die Kunden SSL für ihre eigenen Domains haben wollen, dann hat dafür natürlich nicht der Provider die Kosten zu tragen.