StartSSL bietet die Möglichkeit, einen Schlüssel zu erzeugen, statt einen selbst erstellten zu verwenden.
Danke für die Klarstellung, da habe ich wohl irgendwie unterwegs den Faden verloren ...
mfenske schrieb:
hatte ja auch irgendwie gehofft, das man eins alleine ausstellen kann über openssl
Der Rückzug auf StartSSL ist mir entgangen und ich habe mir auch erst jetzt deren Angebot einmal angesehen (soweit das ohne Registrierung geht).
Idealerweise würde dieser Schlüssel lokal im Browser erzeugt, aber ich habe das nicht überprüft. Laut einem Bericht kürzlich in ct soll es Anbieter geben, die einem zwangsweise einen von ihnen generierten Schlüssel ins Zertifikat schreiben, was natürlich am Zweck des Ganzen vorbei läuft.
Ich kann eine gewisse "Faulheit" ja verstehen. Es gibt sicherlich auch sehr unterschiedliche Beweggründe, um überhaupt ein eigenes Zertifikat zu verwenden.
Was mir aber absolut nicht in den Kopf will, ist irgendein Grund, warum man einen privaten Schlüssel (solange man nicht
absolut sicher ist, daß dabei per Javascript ausschließlich lokale Operationen verwendet werden ... und wer kann das bei unendlich langen EventListener-Chains heutzutage noch) innerhalb einer Webseite einer
israelischen Firma, die netterweise
kostenlose Zertifikate an beliebige - der Beschreibung des Prozesses nach wenigstens per E-Mail legitimierte - Nutzer ausstellt, generieren sollte.
Wenn es nur um das "Abstellen" einer Zertifikate-Warnung beliebiger Browser geht, ist das letzten Endes genauso "sinnlos" (unter Sicherheitsaspekten), wie die bisher bei AVM praktizierte Verwaltung der Zertifikate in der Box.
Wenn ich nur meinen Nachbarn vom Mitlesen meiner Kommunikation mit der Box abhalten will, macht es vielleicht auch nichts, wenn irgendein Dienst meinen privaten Schlüssel gleich bei der Generierung "frei Haus" erhält.
Das hat dann aber mit "
Secure Socket Layer" nur noch wenig zu tun (eher mit "sometimes SSL").
Letzten Endes bringt auch eine bereits in jedem Browser installierte Root-CA nur dann überhaupt einen Sicherheitsgewinn, wenn man - auch hier wieder
absolut - sicher sein kann, daß da nicht jemand einfach noch ein weiteres Zertifikat mit denselben Subject-Daten und einem anderen "public key" anfordern konnte (sei es nun eine Ermittlungsbehörde oder auch nur durch das Kapern des benutzten E-Mail-Accounts) und dieses dann für MITM einsetzen kann, ohne daß man davon überhaupt etwas bemerkt. Hier hat dann jede Verschlüsselung mit einem nicht eingehaltenen Sicherheitsversprechen einen gewaltigen Pferdefuß.
Wenn ich mir so die unendlich langen Listen der standardmäßig installierten Root- und Intermediate-CAs in den verschiedenen Browsern ansehe (vom "Nachladen" beim MS-Crypto-API ganz zu schweigen), dann will
ich nicht allen dort vorhandenen Institutionen vertrauen.
Da ist eine eigene CA (und sei es nur für die Fritz!Box) die bessere Alternative - im einfachsten Fall ist das eine Installation von openssl in Kombination mit der
sicheren Speicherung einer einzigen Datei (nämlich des privaten Schlüssels der CA).
Insofern kann man eigentlich jedem, der wirklich
sicher auf seine Fritz!Box (und den dort vielleicht angeschlossenen Speicher) aus dem Internet zugreifen will, von der Verwendung solcher Angebote wie bei StartSSL in meinen Augen nur abraten ... egal, wo der Schlüssel generiert wurde. Schon deren "CA policy" ist unzureichend für ein sicheres Handling, wenn sie eine E-Mail-basierte Authentifizierung ermöglicht.
Wenn man nur die "nervigen" Sicherheitswarnungen loswerden will, sollte man sich die Ursachen dieser Warnungen einfach mal vor Augen halten ... was man dagegen effektiv tun kann (unter Beibehaltung einer wenigstens einer minimalen Sicherheit), kann man erst nach der Freigabe der Release-Version einschätzen.
Wenigstens die bisherige Praxis, für sichere FTP-Verbindungen nach jedem Neustart ein neues Zertifikat auf der Box zu generieren, scheint man bei AVM nun über Bord geworfen zu haben ... das war allerdings auch der größte Fauxpas, den man sich vorstellen konnte.
Wenn sich der Katholik bei seinem Priester auf die Einhaltung des Beichtgeheimnisses verläßt, muß er immer noch sicherstellen, daß er auch wirklich dem Priester (und nicht dessen Ehefrau - um mal einen beliebten Ansatz für Witze zu verwenden) beichtet. Wenn der Priester bei jeder Beichte wechselt, ist das wahrscheinlich etwas schwierig. Ich bin aber Atheist und kenne mich da nicht wirklich aus ...
Ich finde nicht, dass es im Deutschen komplizierter oder im Englischen einfacher ist. Im Prinzip sind es in beiden Fällen die gleichen Begriffe.
Ich meinte, die verschiedenen "schlüssel"-Ableitungen. Wenn der private Schlüssel mit einem Schlüssel (aka Kennwort) ver-schlüssel-t wird, ist das für
Laien durchaus manchmal etwas undurchsichtig. Und "encrypted private key" ist - für mich - klarer als "verschlüsselter privater Schlüssel" ...
Die meisten schalten verständlicherweise bei der Erläuterung der Primfaktor-Zerlegung auch ab ... deshalb habe ich mir einfach die - zugegebenermaßen falsche - Erklärung angewöhnt, das key-File enthielte den 'private' und den 'public' key. Ansonsten ist es schwer zu erklären, warum man zur Generierung eines Zertifikat-Requests den "privaten" Schlüssel (also das key-File) als Quelle verwendet, wenn doch nur der "öffentliche" Schlüssel dort enthalten sein soll.
