Welche Zertifizierungsstelle würdet ihr für SMIME bzw. https empfehlen?
Hallo,
ich bin dabei einen Server von HTTP auf HTTPS umzustellen beziehungsweise den Emailversand mehrerer Adressen (eine Domain) S/MIME zu zertifizieren.
Welche Zertifizierungsstelle würdet ihr da bevorzugen?
VeriSign ist mir ehrlich gesagt preislich etwas zu heftig...
StartSSL Verified Company gefällt mir bisher ganz gut....
Ich wäre froh über einige Meinungen was noch Preis/Leistungstechnisch zu empefhlen wäre oder ob etwas gegen Startssl spricht.
Viele dank schonmal
Theo
ich bin dabei einen Server von HTTP auf HTTPS umzustellen beziehungsweise den Emailversand mehrerer Adressen (eine Domain) S/MIME zu zertifizieren.
Welche Zertifizierungsstelle würdet ihr da bevorzugen?
VeriSign ist mir ehrlich gesagt preislich etwas zu heftig...
StartSSL Verified Company gefällt mir bisher ganz gut....
Ich wäre froh über einige Meinungen was noch Preis/Leistungstechnisch zu empefhlen wäre oder ob etwas gegen Startssl spricht.
Viele dank schonmal
Theo
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 193055
Url: https://administrator.de/forum/welche-zertifizierungsstelle-wuerdet-ihr-fuer-smime-bzw-https-empfehlen-193055.html
Ausgedruckt am: 15.04.2025 um 08:04 Uhr
16 Kommentare
Neuester Kommentar
Hallo,
wie stellst du dir denn die technische Infrastruktur vor. Sprich: Wie kommen die Nutzer an ihre S/MIME-Zertifikate? Oder vielleicht noch anders gefragt: Wie viele Nutzer hast du?
Für S/MIME gibt es z.B. Verschlüsselungsgateways, die automatisch Zertifikate von einer "vertrauenswürdigen" CA beziehen. Da das proprietäre Lösungen sind, ist die Menge der verfügbaren CAs eingeschränkt, ich würde also erstmal von der Seite an das Thema gehen.
Wenn du nur eine Hand voll Nutzer hast lohnt da natürlich wenig Aufwand, dann kannst du die Zertifikate einzeln manuell ausstellen. Da muss ich sagen: Ich habe die extremen Preisunterschiede für die verschiedenen CAs noch nie verstanden. Das für mich wichtige Ergebnis ist, dass auf der Gegenseite (Browser, EMail-Empfänger) ein grünes Häkchen dran ist, und das können alle CAs ziemlich genau gleich gut (gerade bei VeriSign hatte ich übrigens schon echt Ärger mit ausgetauschten (bzw. fehlenden) Zwischenzertifikaten).
Gruß
Filipp
wie stellst du dir denn die technische Infrastruktur vor. Sprich: Wie kommen die Nutzer an ihre S/MIME-Zertifikate? Oder vielleicht noch anders gefragt: Wie viele Nutzer hast du?
Für S/MIME gibt es z.B. Verschlüsselungsgateways, die automatisch Zertifikate von einer "vertrauenswürdigen" CA beziehen. Da das proprietäre Lösungen sind, ist die Menge der verfügbaren CAs eingeschränkt, ich würde also erstmal von der Seite an das Thema gehen.
Wenn du nur eine Hand voll Nutzer hast lohnt da natürlich wenig Aufwand, dann kannst du die Zertifikate einzeln manuell ausstellen. Da muss ich sagen: Ich habe die extremen Preisunterschiede für die verschiedenen CAs noch nie verstanden. Das für mich wichtige Ergebnis ist, dass auf der Gegenseite (Browser, EMail-Empfänger) ein grünes Häkchen dran ist, und das können alle CAs ziemlich genau gleich gut (gerade bei VeriSign hatte ich übrigens schon echt Ärger mit ausgetauschten (bzw. fehlenden) Zwischenzertifikaten).
Gruß
Filipp
Hallo,
Alles, was ein Zertifikat, tut ist zu bestätigen, dass die Seite, die mir mein Browser anzeigt, auch von der Adresse (www.meinhost.de) kommt, die ich angesurft habe. Bei EV wird zusätzlich noch angegeben, wer diese Seite betreibt.
Jetzt kann ein Nutzer sagen "oh, da steht zwar, dass die Daten von www.meinhost.de kommen, aber das hat nur startssl bestätigt, und nicht verisign - dann verlasse ich die Seite lieber wieder". Aber ich habe noch _nie_ einen Anwender gesehen, der sich dafür interessiert hätte, wer das Zertifikat ausgestellt hat. So lange der Browser "grün" anzeigt ist alles gut.
Gruß
Filipp
Meinst du mit grünem Hacken die "Trust Bar"?
Damit meine ich, dass der Client dem Zertifikat vertraut. Sei es jetzt in einem Browser eine "Trust Bar" (wenn man halt mein, EV zu benötigen) oder einfach nur ein Schloß oder im Mailclient ein Haken an der emfpangenen Mail oder was auch immer. Hängt ja auch vom Client ab.. wichtig ist, wie gesagt, dass dem Zertifikat vertraut wird.Hast du etwas negatives von Startssl gehört?
Was soll man denn da negatives hören? Bestimmt gibt es Stimmen die behaupten "das ist total unsicher, weil das ist ja so billig, und nur Verisign ist gut, weil das ist teuer". Aber das ist ja nun totaler Blödsinn. Die Verschlüsselung ist immer genau gleich sicher, ob sie nun von VeriSign oder Startssl oder sonstwem kommt - die Schlüssel werden nämlich so oder so bei dir auf dem Computer generiert, und der private Schlüssel darf den auch nie verlassen.Alles, was ein Zertifikat, tut ist zu bestätigen, dass die Seite, die mir mein Browser anzeigt, auch von der Adresse (www.meinhost.de) kommt, die ich angesurft habe. Bei EV wird zusätzlich noch angegeben, wer diese Seite betreibt.
Jetzt kann ein Nutzer sagen "oh, da steht zwar, dass die Daten von www.meinhost.de kommen, aber das hat nur startssl bestätigt, und nicht verisign - dann verlasse ich die Seite lieber wieder". Aber ich habe noch _nie_ einen Anwender gesehen, der sich dafür interessiert hätte, wer das Zertifikat ausgestellt hat. So lange der Browser "grün" anzeigt ist alles gut.
Gruß
Filipp
Ehrlich gesagt schnurz, weil niemand auf den Zertifikat-Chain achtet (höchstens noch auf EV-SSL).
Und mit Sicherheit kann man da bei allen bisher bekannten Lücken auch nicht mehr argumentieren.
Ich benutze für S/MIME grade TrustCenter (weil kostenlos)
Und für SSL http://www.onestepssl.com/ (weil am billigsten).
Und mit Sicherheit kann man da bei allen bisher bekannten Lücken auch nicht mehr argumentieren.
Ich benutze für S/MIME grade TrustCenter (weil kostenlos)
Und für SSL http://www.onestepssl.com/ (weil am billigsten).
Zitat von @theoberlin:
Hallo,
Es geht darum, einen HTTP Kundenserver mit HTTPS auszurüsten da ist selfsigned für mich ein nogo weil die Kunden auf
keinen Fall ein "Unbekanntes" oder " nicht vertrauenswürdiges" zu Gesicht bekommen sollen
Hallo,
Es geht darum, einen HTTP Kundenserver mit HTTPS auszurüsten da ist selfsigned für mich ein nogo weil die Kunden auf
keinen Fall ein "Unbekanntes" oder " nicht vertrauenswürdiges" zu Gesicht bekommen sollen
Moin,
Deswegen fragte ich ja, ob das eine Option wäre.
Allerdings sind die gekauften zertifikate geausowenig "vertrauenswürdig" wie die selbstsignierten. Im Gegenteil, wenn man diginotar & co. sieht, sind die sogar noch gefährlicher als die selbstsignierten, weil man sich in falscher Sicherheit wiegt.
lks
Hallo
Bitte trennen zwischen Verschlüsselung und Authentifizierung. Die Sicherheit der Verschlüsselung ist völlig unabhängig davon wer dein Zertifikat unterschreibt. Die Authentifizierung ist wie du schon selbst bemerkt hast für die meisten Gegenüber nur bis zu dem Punkt nachvollziehbar, bei dem ein buntes Schloss im Browser angezeigt wird. Also kauf dir das ein was zum günstigsten Preis den Zweck erfüllt. Wenn die Authentifizierung wirklich sicher sein soll könnt Ihr euch immer noch die Hashwerte am Telefon vorlesen.
Gruß
Andi
Bitte trennen zwischen Verschlüsselung und Authentifizierung. Die Sicherheit der Verschlüsselung ist völlig unabhängig davon wer dein Zertifikat unterschreibt. Die Authentifizierung ist wie du schon selbst bemerkt hast für die meisten Gegenüber nur bis zu dem Punkt nachvollziehbar, bei dem ein buntes Schloss im Browser angezeigt wird. Also kauf dir das ein was zum günstigsten Preis den Zweck erfüllt. Wenn die Authentifizierung wirklich sicher sein soll könnt Ihr euch immer noch die Hashwerte am Telefon vorlesen.
Gruß
Andi
Zitat von @AndiEoh:
Hallo
Bitte trennen zwischen Verschlüsselung und Authentifizierung. Die Sicherheit der Verschlüsselung ist völlig
unabhängig davon wer dein Zertifikat unterschreibt.>
Hallo
Bitte trennen zwischen Verschlüsselung und Authentifizierung. Die Sicherheit der Verschlüsselung ist völlig
unabhängig davon wer dein Zertifikat unterschreibt.>
Eben nicht.
Und man bekommt keine sichere Verschlüsselung mit public keys, wenn die Authentizität des gegenübers nicht sichergestellt ist. Denn es könnte geneusogut ein MITM sein. Das ist ja die Krux mit den ganzen liederlichen Truscentern, die entweder nicht genau prüfen, oder sich hacken lassen.
lks
PS: Man sollte sich Hashwerte immer geben lassen, wenn man mitm ausschließen will. Insbesondere beim online-Banking sollte man die hash-werte prüfen. Allerdings sind da manche Bankmitarbieter doch etwas unbedarft, weil die einfach Ihren Browser aufmachen wollen und dann die Hashwerte, die sie über das Internet bekommen vorlesen wollen, statt diese direkt von Ihrem zertifikat auszulesen.
Zitat von @Lochkartenstanzer:
> Zitat von @AndiEoh:
> ----
> Hallo
>
> Bitte trennen zwischen Verschlüsselung und Authentifizierung. Die Sicherheit der Verschlüsselung ist völlig
> unabhängig davon wer dein Zertifikat unterschreibt.>
Eben nicht.
Und man bekommt keine sichere Verschlüsselung mit public keys, wenn die Authentizität des gegenübers nicht
sichergestellt ist. Denn es könnte geneusogut ein MITM sein. Das ist ja die Krux mit den ganzen liederlichen Truscentern, die
entweder nicht genau prüfen, oder sich hacken lassen.
> Zitat von @AndiEoh:
> ----
> Hallo
>
> Bitte trennen zwischen Verschlüsselung und Authentifizierung. Die Sicherheit der Verschlüsselung ist völlig
> unabhängig davon wer dein Zertifikat unterschreibt.>
Eben nicht.
Und man bekommt keine sichere Verschlüsselung mit public keys, wenn die Authentizität des gegenübers nicht
sichergestellt ist. Denn es könnte geneusogut ein MITM sein. Das ist ja die Krux mit den ganzen liederlichen Truscentern, die
entweder nicht genau prüfen, oder sich hacken lassen.
Das ist genau der Punkt. Die Verschlüsselung kann von unbeteiligten Dritten nicht gebrochen werden, durch MitM wird der Angreifer aber zum Beteiligten. Die Authentifizierung ist deshalb getrennt zu betrachten.
Um wirklich "sicher" zu sein müsste man über einen unabhängigen Kanal z.B. den Hashwert prüfen. Allerdings ist für die meisten schon das überprüfen ob https anstatt http verwendet wird zu aufwendig. Deshalb ist es völlig belanglos von welcher CA die Zertifikate unterschrieben sind, da es zumindest besser als unverschlüsselt ist und ein wirklich sicheres Verfahren sich niemals durchsetzen lässt, weil dazu beim Anwender zumindest fundametale Sicherheitskenntnisse benötigt werden.
Zitat von @AndiEoh:
> Zitat von @Lochkartenstanzer:
> ----
> > Zitat von @AndiEoh:
> > ----
> > Hallo
> >
> > Bitte trennen zwischen Verschlüsselung und Authentifizierung. Die Sicherheit der Verschlüsselung ist
völlig
> > unabhängig davon wer dein Zertifikat unterschreibt.>
>
> Eben nicht.
>
> Und man bekommt keine sichere Verschlüsselung mit public keys, wenn die Authentizität des gegenübers nicht
> sichergestellt ist. Denn es könnte geneusogut ein MITM sein. Das ist ja die Krux mit den ganzen liederlichen
Truscentern, die
> entweder nicht genau prüfen, oder sich hacken lassen.
Das ist genau der Punkt. Die Verschlüsselung kann von unbeteiligten Dritten nicht gebrochen werden, durch MitM wird der
Angreifer aber zum Beteiligten. Die Authentifizierung ist deshalb getrennt zu betrachten.
> Zitat von @Lochkartenstanzer:
> ----
> > Zitat von @AndiEoh:
> > ----
> > Hallo
> >
> > Bitte trennen zwischen Verschlüsselung und Authentifizierung. Die Sicherheit der Verschlüsselung ist
völlig
> > unabhängig davon wer dein Zertifikat unterschreibt.>
>
> Eben nicht.
>
> Und man bekommt keine sichere Verschlüsselung mit public keys, wenn die Authentizität des gegenübers nicht
> sichergestellt ist. Denn es könnte geneusogut ein MITM sein. Das ist ja die Krux mit den ganzen liederlichen
Truscentern, die
> entweder nicht genau prüfen, oder sich hacken lassen.
Das ist genau der Punkt. Die Verschlüsselung kann von unbeteiligten Dritten nicht gebrochen werden, durch MitM wird der
Angreifer aber zum Beteiligten. Die Authentifizierung ist deshalb getrennt zu betrachten.
Eben nicht.
Das Ziel ist es doch, wenn Alice und Bob miteinander reden, daß Cäsar nicht mitbekommt, was die reden.
Wenn nun nicht geprüft wird, mit wem man redet, kann sich Cäsar einfach dazwischen stellen und zu Alice so tun, als ob er Bob wäre und zu Bob, als ob er Alice wäre. Damit hat ein "unbeteiligter" dritter die Kommunikation abgehört und mußte dafür nciht einmal die verschlüsselugn brechen. Genau deswegen muß die Authentifikation immer besdtandteil eines Schlüsselaustausches sein und genau deswegen wurden auch zertifikate "erfunden".
lks
In der Sache sind wir uns ja einig aber bitte um Verwirrung zu vermeiden beim korrekten Vokabular bleiben.
Verschlüsselung ist z.B. AES bzw. Schlüsseltausch über RSA. Die Authentifizierung kommt erst durch die PKI mit Ihren Vertrauensstellungen rein und ist nur insofern mit der Verschlüsselung verheiratet das sie wegen des Schlüsseltausches benötigt wird um festzustellen mit wem ich Schlüssel tausche. Wenn man schon das "Ziel" (Alice,Bob etc.) ins Gespräch bringt sollte man von einer sicheren Verbindung sprechen und nicht von Verschlüsselung.
Aus genau diesem Grund hört man sonst immer wieder den Quatsch von Verschlüsselung gebrochen wenn wieder mal die Authentifizierung entweder weggelassen wurde oder umgangen werden kann.
Ist aber nun OT und sollte beendet werden.
Gruß
Andi
Verschlüsselung ist z.B. AES bzw. Schlüsseltausch über RSA. Die Authentifizierung kommt erst durch die PKI mit Ihren Vertrauensstellungen rein und ist nur insofern mit der Verschlüsselung verheiratet das sie wegen des Schlüsseltausches benötigt wird um festzustellen mit wem ich Schlüssel tausche. Wenn man schon das "Ziel" (Alice,Bob etc.) ins Gespräch bringt sollte man von einer sicheren Verbindung sprechen und nicht von Verschlüsselung.
Aus genau diesem Grund hört man sonst immer wieder den Quatsch von Verschlüsselung gebrochen wenn wieder mal die Authentifizierung entweder weggelassen wurde oder umgangen werden kann.
Ist aber nun OT und sollte beendet werden.
Gruß
Andi
Hier noch eine Meldung von heise zu dem Thema:
http://www.heise.de/security/meldung/SSL-Zertifikate-und-der-gefaehrlic ...
Wie ich (implitzit) schon sagte: Die größte Schwachstelle ist die Prüfung des Zertifikats der Gegenstelle.
lks
http://www.heise.de/security/meldung/SSL-Zertifikate-und-der-gefaehrlic ...
Wie ich (implitzit) schon sagte: Die größte Schwachstelle ist die Prüfung des Zertifikats der Gegenstelle.
lks