Hallo allerseits,

wenn man wie ich gerade das Webhosting-Angebot hierzulande durchforstet, so fällt auf, dass so gut wie alle Hoster mittlerweile kostenlose Let’s Encrypt-Zertifikate für die bei ihnen gehosteten Domains anbieten. Zugleich teils aber auch SSL-Zertifikate anderer Hersteller für um die 100€ pro Jahr oder mehr.

Was unweigerlich die Frage nach sich zieht, worin denn der Mehrwert solcher Zertifikate bestehen soll. Als blutiger Laie hätte ich gedacht, SSL = SSL bzw. https = https.

Wer kann Licht in meine dunklen Hirnwindungen bringen?

Danke schonmal!

Extended-Validation-Zertifikat kann ein Argument sein. Ist aber auch ein besonders Teures.
Die Laufzeit von Let's Encrypt Zertifikaten beträgt 90 Tage. Dies soll Druck erzeugen das der Zertifikatswechsel voll automatisiert wird. Kostenpflichtige Zertifikate können bis zu 397 Tage gültig sein. Da mag es billiger kommen sie noch händisch zu wechseln.

Da du von gehosteten Domains sprichst lautet mein Rat: Verzichte auf die Kostenpflichtigen. Die Hoster haben ihre Angebote idR. so konfiguriert das Let's Encrypt Zertifikate auch automatisch erneuert werden und du sparst Geld.

mMn war das schon immer ein Kartell. Technisch muss man zwischen den "CIA"-Schutzzielen unterscheiden: Confidentiality und Integrity kannst du auch mit jedem beliebigen self-signed Zertifikat erreichen. Lediglich die Authenticity ist dabei ein Knackpunkt: Für die allermeisten Websites spielt es schließlich nicht nur eine Rolle, ob deine Daten abhörsicher übertragen werden, sondern ob sie auch das "wahre" Ziel erreichen.

Und genau hier kommen die CAs ins Spiel, welche eben überprüfen, ob Name und Adresse in den Zertifikatsinformationen mit denen des Handelsregisterauszugs o.ä. übereinstimmen. Dies kostet natürlich Geld.

Wer diese manuelle Zertifikatsbeantragung aber mal mitgemacht hat, weiß, dass die Prüfung bei weitem nicht so penibel ist, wie man vlt hofft (von den zuvor genannten EV-Zertifikaten mal abgesehen). In vielen Fällen wird lediglich überprüft, als ob eine zu der Domain passende E-Mail-Adresse auch erreichbar ist. Das geht natürlich komplett automatisiert und rechtfertigt keine vermeintlich hohen Prüfungsaufwände.

Mit anderen Worten: Die CAs verkaufen einfach nur überteuerte Textdateien, die jeder Laie auch selbst erzeugen kann.

Let's Encrypt ist da ein Segen. Da haben sich einige Leute zusammengetan und erkannt, dass der wirtschaftliche Schaden durch eine löchrige TLS-Landschaft deutlich höher ausfällt als durch die entgangenen Umsätze konventioneller CAs. Auch Let's Encrypt überprüft übrigens. Aber eben automatisiert und hier geht es um tatsächliche technische Sicherheit ("passt der Server zur Domain?"), nicht juristische Pseudo-Sicherheit ("Schreibt sich der Name im Personalausweis mit oder ohne h")

Ich nutze auf mindestens 50 Domains LetsEncrypt mit certbot (zum automatischen erneuern). Nie Probleme gehabt.

Wenn Du nicht auf eine Person / Institution validieren musst (Betonung auf musst) dann tu es nicht und nimm LetsEncrypt. Ansonsten haben meine Vorredner alles gesagt!

<korinthenkackermodus>SSL ist schon lange sehr tot, inzwischen verwendet man TLS.</korinthenkackermodus>

Davon abgesehen: Der Unterschied liegt, wie bereits von einigen erwähnt, in der Form der Validierung. Let's Encrypt kann prinzipbedingt nur DV (domain validated)-Zertifikate ausstellen, da die Validierung automatisiert erfolgt und man da halt nicht viel mehr prüfen kann als daß Du die Kontrolle über die Domain hast, für die Du ein Zertifikat brauchst. Das kannst Du z.B. per DNS-Eintrag oder durch Anlegen eines Files auf einem Webserver nachweisen.

Das reicht für Transportverschlüsselung aus, aber sonst für nicht viel, aber das ist ja auch genau das, was mit einem Zertifikat auf einem Webserver in den meisten Fällen erreicht werden soll. Daher hat Let's Encrypt auch so ziemlich den Markt aufgerollt, was eine sehr gute Sache ist.

Wenn Du aber jetzt "Weias Webshop" oder "Weias Bankhaus" betreiben willst, dann ist das Wissen, daß Du der Inhaber der betreffenden Domain bist, nicht ausreichend. Immerhin will man ja geschäftliche Transaktionen abwickeln, und da ist es auch wichtig, daß man die Identität seines Gegenübers einigermaßen zweifelsfrei kennt. Das aber kann Let's Encrypt nicht leisten, da keinerlei persönliche oder Geschäftsunterlagen validiert werden. Für diese Aufgaben gibt es OV (Organisation Validation), IV (Individual Validation) und EV (Extended Validation)-Zertifikate. Bei OV mußt Du die Identität Deines Unternehmens dokumentieren und belegen, bei IV Deine persönliche, und bei EV werden an diese Überprüfung erhöhte Maßstäbe angelegt - das erfordert in aller Regel auch die Involvierung eines Anwalts bzw. Notars bei der Beglaubigung. Diesen erhöhten Aufwand muß man natürlich bezahlen.

Auf der Habenseite kann man dann aber auch weit mehr mit den Zertifikaten anstellen. So kann man zwar technisch mit einem DV-Zertifikat ein Dokument signieren, praktisch nützt das aber nicht so viel - eine Signatur von einer Internet-Domain hat begrenzten Nutzen. Hast Du ein IV-Zertifikat, bestätigt die Signatur aber, daß der Unterzeichner zumindest im Besitz Deines privaten Schlüssels war, was idealerweise natürlich nur Du bist (früher gab es mal Siegel oder Unterschriftenstempel, die gab man ja auch nicht aus der Hand, auch wenn man es konnte).

Es gab mal ein Projekt, das in seinen Ansätzen deutlich ambitionierter war als Let's Encrypt, nämlich CAcert.org. Dort war die Validierung im Sinne eines "Web of Trust" organisiert, und damit konnten dann auch OV- und IV-Zertifikate ausgestellt werden. Das Projekt krankte aber leider an organisatorischen Mängeln und hat es nie auf die Reihe gebracht, sich vom CA/Browser-Forum zertifizieren zu lassen, was aber eine Grundvoraussetzung zum Eintrag in die Trust Chains der Betriebssysteme und damit zur Anerkennung der CA (die wiederum für die Gültigkeit der Zertifikate unerläßlich ist) ist. Inzwischen ist es leider ziemlich tot, spätestens Let's Encrypt hat CAcert endgültig den Boden unter den Füßen weggezogen.

Analoges wie für das Verschlüsseln von TLS-Traffic gilt auch für das von Mails mit S/MIME: Auch hier gibt es Zertifikate ohne oder mit persönlicher Verifikation der Identität. Erstere kann man wiederum zum Verschlüsseln und Signieren von Mail verwenden, auf die tatsächliche Identität des Signierers kann man aber nur mit einem Zertifikat der höheren Verifikationsstufen schließen. Let's Encrypt stellt grundsätzlich (noch?) keine S/MIME-Zertifikate aus, da ist man also dann auf die kommerziellen Anbieter wie SwissSign, die das zu relativ guten Tarifen machen, angewiesen. Der Ansatz von Let's Encrypt, Zertifikate für maximal drei Monate auszustellen, wäre bei S/MIME auch sehr hinderlich.

Daß die X.509-PKI mit ihren zig teils höchst dubiosen CAs schon im Ansatz kaputt ist, ist wiederum ein ganz anderes Thema ... dazu kann man aber ganze Romane schreiben.

Top erklärt!

EV ist nur Geldmacherei. Warum EV kaputt ist, liest man z,B. bei oder

Der frühere spezielle Vorteil der Kennzeichnung in der Browser-Adresszeile ist eh weg. Browser zeigen das seit mehreren Jahren schon nicht mehr an.

Statler_RGBG
Aber miserabel von dir zitiert. Mach dich mal über Tofu in Foren schlau
Es hätte ein einfacher Daumen rauf gereicht oder einfach nur dein Text ohne Zitat

Bleibt mal friedlich, bitte. Wir sind hier nicht im Wembleystadion.
Hakuna matata.

Vielen Dank an alle für die ausführlichen Erklärungen! Alles klar jetzt.
Gut, das ginge ja ebenso mit personenvalidierten S/MIME-Zertifikaten. Zwar nicht so leicht zu bekommen, aber immerhin nicht sooo viel teurer als nur adressvalidierte kommerzielle S/MIME-Zertifikate.

Da kann ich gerade ein Lied davon singen; ich habe Ende April versucht, bei D-Trust (Tochter der Bundesdruckerei) ein personenvalidiertes S/MIME-Zertifikat zu bestellen. Offenbar war ich aber der erste Kunde, denn bekommen habe ich bis heute nichts – der Bestellvorgang klemmt am x-ten Bug des Bestellprozesses und ein Ende ist nicht abzusehen … 🤬
Warum es hier nicht längst eine Let’s Encrypt entsprechende Initiative gibt, ist mir ein Rätsel. Seit über 2 Jahrzehnten kommen gesicherte Emails einfach nicht in die Gänge, stattdessen wird mancherorts nach wie vor von Faxen fabuliert.

Als ich vor kurzem mal auf der Website meines Finanzamts war, sah ich doch tatsächlich erstmals eine Passage, die sinngemäß lautete: Bitte beachten Sie, dass Emails an das Finanzamt zur Zeit nur unverschlüsselt möglich sind. Sprich, immerhin hat man dort jetzt gemerkt, dass man Emails auch verschlüsseln könnte … 🙄 Das stimmt ja regelrecht optimistisch für 2040.
Nicht zeitgemäß. Eine Serie auf Apple TV+ wäre erfolgversprechender.

Nun ja, ich habe mittlerweile schon das zweite SwissSign-Zertifikat und kann gut damit leben. Der Preis ist einigermaßen überschaubar und es funktioniert bislang überall - keine Beschwerden nirgendwo.

Leider stellen sie keine IV-Zertifikate aus... zumindest nicht für nicht-Schweizer.

Gruß - Matthias

Ja, ich ja auch (beides). Aber verschlüsselte Mails werden sich nur als Standard etablieren, wenn praktisch jeder Zertifikate benutzt. Und wenn Du daran denkst, wie viele Nutzer werbeverseuchte Mails versenden, nur um nicht einmal 1€ oder so pro Monat zahlen zu müssen, dann wird klar, dass sich verschlüsselte Mails bei Preisen, wie SwissSign sie aufruft, niemals durchsetzen werden. Das muss (so gut wie) kostenlos sein, um ein Standard zu werden, eben so wie bei Let’s Encrypt. Zum Beispiel grundsätzlich im Preis für Emails mit eigener Domain enthalten, auch wenn der nur 1 € pro Monat beträgt.

Zertifizierungsstellen bieten wenn man sie mit der "Normalen Welt" vergleicht Notar-Dienstleistungen.
Der Notar muss bezeugen, dass alle betroffenen Parteien die sind für die sie sich ausgeben.
Das das nicht kostenfrei ist sollte "in der Normalen Welt" eigentlich klar sein.

Lets Encrypt bietet die zertifikate kostenfrei an, da es eine gemeinnützige Institution ist.

Naja, in einem sehr eingeschränkten Sinn. Es geht für ein einfaches Mail-Zertifikat ja nur darum, dass dem Absender die Email-Adresse tatsächlich gehört. Das lässt sich automatisiert feststellen.
Ist es ja auch. Die virtuelle Welt gehorcht aber nunmal nicht denselben Gesetzen.
Schon klar. Finanziert von Unternehmen, die ein Interesse daran haben, dass verschlüsselte Websites allgegenwärtig sind. Warum sollte dasselbe nicht auch für Emails funktionieren?

Ist das Problem der Archivierung – Signaturverifizierung oder Entschlüsselung auch nach Jahrzehnten – oder die Durchsuchbarkeit in Mailprogrammen – bei verschlüsselten Emails – schon komfortabel und portabel gelöst?

Mir ist nicht ganz klar, von welchen Problemen Du redest, aber in jedem Fall haben sie offenkundig nichts mit dem Problem der möglichst großen Verbreitung von Zertifikaten zu tun. Problem X nicht anzugehen mit dem Hinweis, es gebe ja auch noch Problem Y, (und vice versa) war jedoch noch nie eine gute Strategie.

Wenn du zu einem späteren Zeitpunkt die Signatur verifizieren willst brauchst du dazu das Wurzelzertifikat des Ausstellers. Wenn dieses aber zwischenzeitlich abgelaufen ist – zugegeben haben die Wurzelzertifikate eine lange Laufzeit – steht es für gewöhnlich nicht mehr zur Verifizierung zur Verfügung, es sei denn du bewahrst es auf. Ähnliches gilt für die Verschlüsselung. Um Mails später, oder auch auf anderen Plattformen, wieder entschlüsseln zu können musst den privaten Schlüssel aufbewahren bzw. auch auf den anderen Plattformen die du benutzt verteilen.
Ich nutze sowohl macOS, Windows und Linux parallel. Möchte ich von all denen auf meine Mails zugreifen brauche ich dank IMAP und Exchange nur meine Credentials und mir stehen alle Emails überall zur Verfügung. S/MIME steht zwar überall zur Verfügung aber der Aufwand jedes Jahr überall meine Mailzertifikate zu erneuern ging mir auf den Keks. Hinzu kommt die Benutzung von Webmail: Eine wirklich brauchbare und sichere Benutzung von S/MIME ist eigentlich nur auf eigenen, vertrauenswürdigen Webmailern möglich.
Insofern haben diese Erfahrungen bei mir rückgekoppelt mit der Erkenntnis: Bei flüchtiger Kommunikation wie sie https bietet Gerne. Bei persistenten Nachrichten á la Email Nein Danke.

So richtig trennen kann man Problem X und Problem Y leider nicht.

Unternehmen unterliegen ja diversen Speicher- und Archivierungspflichten ihre Korrespondenz betreffend. Die Problematik, daß Zertifikate ablaufen, läuft darauf hinaus, daß man zusammen mit der archivierten Korrespondenz auch alle alten Zertifikate, die zu deren Signaturverifikation erforderlich sind, und alle alten privaten Schlüssel zu ihrer Entschlüsselung mit archivieren muß.

Da die aber nicht auf dem Mailserver liegen, müssen sie in einem separaten Sicherungsvorgang archiviert werden, was durchaus keine triviale Aufgabe und von den Betriebssystemen eher stiefmütterlich unterstützt ist.

Insofern kann ich mir gut vorstellen, daß es Vorbehalte gegenüber der Verschlüsselung gibt. Lösungen freilich auch - so können z.B. Security Gateways (einer meiner Kunden setzt z.B. Zertifikon ein) die Mails transparent entschlüsseln, bei den Adressaten im Haus kommen sie dann also schon als Klartext an und werden auch so archiviert. Das hat Vor- und Nachteile: Das beschriebene Archivierungsproblem ist weg, die Verschlüsselung allerdings auch, und für Signaturen hilft es nichts.

Ich fürchte, um das mal wirklich so richtig anzugehen würden wir eine Verschlüsselungspflicht analog zur Archivierungspflicht brauchen. Und wie ich unsere Gesetzgeber und ihr Verhältnis zum "Neuland" Internet kenne, wird das ganz sicher das letzte sein, was in Angriff genommen wird ... wenn überhaupt, der Trend geht ja eher in die Gegenrichtung.

In den allermeisten Fällen, wo bei größerer Verbreitung S/MIME-Emails eingesetzt würden, läuft es im Augenblick doch so ab:

Ich bekomme eine unverschlüsselte Email (von Behörde, Bank, Versicherung, …), dass auf meinem Nutzerkonto auf ihrem Server eine vertrauliche Nachricht zum gesicherten Abruf als PDF für mich bereit läge. Durch die Häufigkeit, mit der er mittlerweile Auftritt, nervt mich dieser zusätzliche Schritt des erforderlichen Abrufs ungemein.

Wäre S/MIME etabliert, könnte mir das PDF einfach in der Email gesandt werden. Ich sehe absolut nicht, was daran „persistenter“ wäre. Die Email lösche ich doch eh; was gespeichert wird, ist das PDF.

Und bei den wenigen anderen Emails, bei denen Verschlüsselung wichtig wäre, bei denen aber der wichtige verschlüsselte Inhalt direkt als Text und nicht als Attachment vorliegt, handelt es sich doch fast immer um flüchtige Informationen – vergessenes Passwort, momentaner Kontostand, … –, die sowieso niemand aufhebt.
Aber natürlich bewahre ich es auf – oder besser gesagt der Schlüsselbund. Das geht vollautomatisch ohne jegliches Zutun meinerseits. Wo ist da ein Problem?
Stimmt.
Warum sollte ich Mails auf anderen Plattformen entschlüsseln wollen als der, auf der sie liegen?
Das ist aber jetzt typische Bedenkenträgerei. Es wird immer irgendwelche Supersonderspezialfälle geben, die nicht ganz so einfach zu handeln sind, aber es ist unsinnig, deshalb das Problem erst gar nicht anzugehen. Wozu müssen Dir Deine verschlüsselten Emails immer und überall zur Verfügung stehen und das auch noch auf verschiedenen Plattformen? Bei allen alternativen Formen der Übertragung eines wichtigen Dokuments landet das doch auch nur lokal auf einem einzigen Computer, es sei denn, man betreibt besonderen Aufwand.
Wieso jährlich? Meine laufen 3 Jahre, aber zugegeben hat mich die Reduktion der Laufzeit von 5 auf 3 Jahre auch genervt. Der Prozess der Zertifikaterneuerung ließe sich durch höhere Automatisierung sicherlich noch deutlich verbessern. Das geht aber kein Betriebssystemhersteller und kein Zertifikathersteller an, solange eh kein Schwein S/MIME nutzt.
Ja dann benutzt man für wichtige Emails eben kein Webmail. Bei mir persönlich landen alle Emails ohnehin schnellstmöglich auf meinem lokalen Computer und werden sofort auf dem Server gelöscht, weil ich nicht will, dass irgendwelches Zeugs von mir auf fernen Servern liegt. Klar, das sehen Cloud-Fans natürlich anders. Aber in jedem Fall muss man irgendwo anfangen.

Anstatt S/MIME erstmal elementar zu einem verbreiteten Standard zu machen, kann man natürlich rufen: Aber dann geht dies und jenes nicht! Ja, so ist das dann eben. Im Istzustand geht verschlüsselt praktisch gar nichts.

Eigentlich ist die Antwort auf die eingangs gestellt Frage sehr einfach, wenn es einem nur um die Absicherung von Webseiten geht:

Bis auf die kurze Laufzeit gibt es funktionell keinen Unterschied.

OK, das ist doch aber kein Hexenwerk.

Zudem kann der Gesetzgeber getreu seinem Namen ja Gesetze auch ändern. PDF-Rechnungen hatten ihren Durchbruch auch erst, als allzu gestrenge Anforderungen fallengelassen wurden.
Das hat mich eh gewundert, als ich begann, S/MIME selbst zu nutzen: Ich hatte erwartet und hätte vorgezogen, dass die Mails, sobald sie in meinem lokalen Postfach liegen, entschlüsselt bleiben – was geschützt werden soll, ist doch ganz überwiegend der Transportweg und nur in seltenen Fällen die lokale Speicherung. Mit der Signatur hast Du natürlich recht; allerdings stand die bei der Nutzung für mich nie im Vordergrund. Ist eine Signatur auch noch lange nach Erhalt der Mail wirklich wichtig? Würde man in solch einem Fall nicht ohnehin ein digital signiertes PDF versenden?
Statt Pflicht ist mir seitens des Gesetzgebers ja Erleichterung immer lieber, so wie damals bei den PDF-Rechnungen.
Ach ja …

Für mich stände das auf der Wunschliste an eine neue Regierung ganz oben.
Was meinst Du jetzt damit? Faxe? 😱

Nein, ist es nicht. Aber Aufwand. Und solange es keine Konsequenzen hat, den Aufwand nicht zu betreiben, betreibt man ihn eben nicht, das ist dann weniger Aufwand und damit kostengünstiger.
Wenn er denn ein Interesse daran hat, ja. Aber wie gesagt ...
Nein, im Gegenteil.

Der Transportweg ist ja im Allgemeinen schon ganz gut geschützt, wenn man einigermaßen seriöse Provider nutzt. Die meisten Mailserver handeln untereinander die Verschlüsselung aus, und wenn nicht gerade irgendjemand sich aktiv dazwischenmogelt ist das dann eben eine TLS-basierte Transportverschlüsselung. Den Transportweg abzusichern ist nicht der primäre Zweck der Mailverschlüsselung, sondern ganz im Gegenteil die Absicherung der ruhenden Mail auf dem Server.

Die meisten Leute haben ja keinen eigenen Server im Keller stehen, ihre Mails befinden sich also bei irgendeinem Provider auf dem Server. Die Geburtstagsmail an Tante Erna ist da sicherlich nicht das Objekt der Begierde, aber das Angebot an einen Kunden kann schon interessanter sein und ganz sicher hätte der Anwalt oder Arzt gern die Kommunikation mit dem Klienten oder Patienten (oder umgekehrt ) fremden Blicken entzogen. Ich tausche z.B. mit meinem Buchhalter monatlich die Belege per Mail aus - ohne Mailverschlüsselung müßten wir die in irgendwelche verschlüsselten Archive verpacken, bevor wir sie versenden können.

Und ganz haarig wird es dann bei Journalisten, Bürgerrechtlern und ähnlichen Personengruppen, bei denen das Interesse oft von staatlicher Seite kommt. Da sind dann im Zweifel auch mal die Mittel da, um sich die Daten zu beschaffen.
Gerade langfristig kann das interessant sein. Die Authentizität juristisch relevanter Mails hätte ich gern auch in 10 Jahren, wenn der Rechtsstreit dann richtig interessant wird, noch verifizierbar - oder, weniger dramatisch, ich würde dem Finanzamt gegenüber die Gültigkeit einer signierten Rechnung von einem Lieferanten im Zweifel gern auch noch bei der Betriebsprüfung in ein paar Jahren belegen können (ich hatte schon mal einen Fall, bei dem es sehr nützlich gewesen wäre, wenn meine dämliche damalige Steuerberaterin den Mist, den sie gebaut hat, signiert hätte ... hätte mir einen Haufen Streß mit der Fahndung erspart).
Das Problem dabei: Nur weil es leichter geht, nimmt immer noch niemand Geld in die Hand und tut was, zumal wenn es potentiell zu seinem Nachteil ist. Signierung beispielsweise nutzt ja mir als Signierendem nichts, sondern dem Empfänger im Falle der Beweisführung. Verschlüsselung kostet Geld, und wenn ich als Firma im Fall eines unbeabsichtigten Datenreichtums keine Pflichtverletzung begangen habe, dann ist mir das gerade mal egal und ich spare mir den Akt.
Nein, die immer weiter überbordenden Rufe nach Schwächung der Verschlüsselung, Hintertüren, Staatstrojanern für alle und noch mehr Datenreichtum (für die Geheimdienste, versteht sich) in Form von Vorratsdatenspeicherung und "Online-Durchsuchungen". Da stört Verschlüsslung auf breiter Basis doch nur.

Alles natürlich wegen der Sicherheit.

Verstehe ich jetzt nicht. Ich lasse wichtige Emails doch auf keinem Server im Internet liegen, sondern speichere sie lokal ab und lösche sie vom Server. Für mich geht es bei der Verschlüsselung ausschließlich um den Transport (zu dem ich aber natürlich die paar Minuten bis Stunden auf Mailservern dazurechne).
Schon klar, aber mein Punkt wäre ja eben: Wenn die Rechnung (oder ein juristisch wichtiges PDF) eh schon digital signiert sind, wozu dann auch noch die Email, die sie/es transportiert?

Email-Signaturen finde ich eigentlich nur wichtig bei Erstkontakten, wenn ich mir nicht sicher sein kann, wer mich da überhaupt anschreibt.
Aber es ist doch nicht so, dass es in relevanten Fällen auch ohne Signatur ginge. Sie ist dann nur auf dem Papier statt digital und das macht den ganzen Prozess für beide Seiten aufwändiger. Also müssten beide Seiten ein Interesse daran haben, digitale Signaturen zu verwenden – es ist einfach ein effizienterer Prozess, wenn er denn mal gut etabliert ist.
Ach so, ja.

Korrektur: Zur Signatur-Verifizierung reicht das Leaf-Zertifikat. Die Signatur bleibt auch gültig UND verfizierbar, wenn dieses bereits lange abgelaufen ist. Jedoch hast du insofern Recht, als dass die meisten Programme (zurecht) die ganze Chain mitprüfen. Über die Nutzerfreundlichkeit kann man sich da natürlich streiten: Will man nur nen grünen Haken, wenn "alles" passt? Oder würden Abstufungen mehr bringen?

Den Private Key aufzubewahren ist ohnehin IMMER eine Gute Idee. Was für uns selbstverständlich ist, muss sich Tante Hildegard, 82, Vogelkundlerin a.d. natürlich noch lange nicht erschließen...

Vielleicht verbreitet sich ja der Einsatz von Blockchain-Technologie bald im Zertifikats-Umfeld, wie das hier angetönt wird

Erstens ist es ziemlich egal, wie lange Daten auf irgendeinem fremden Server liegen. Der Umstand, daß sie irgendwann mal unverschlüsselt dort gelegen haben, reicht schon. In dem Moment, wo jemand die Gelegenheit hatte, sie unverschlüsselt abzugreifen, sind sie als potentiell kompromittiert zu betrachten.

Zweitens ist Deine Annahme, daß Du aus Deiner Vorgehensweise (die nach dem obengesagten auch schon nicht so viel bringt, wie Du denkst) auf das allgemeine Benutzerverhalten schließen kannst, meiner Erfahrung nach vollkommen unrealistisch. Die meisten Leute nutzen irgendwelche Mailprovider, viele haben auch nicht mal ein Problem mit GMail. Im Gegenteil ziehen immer mehr Unternehmen mit ihrer Bürokommunikation "in die Cloud", so daß ihre Datenbestände in zunehmendem Maße nicht mehr unter ihrer Kontrolle sind.

Das Gros der Benutzer schert sich nicht einen Deut darum, wo die Daten liegen und holt seine Daten unter Garantie nicht vom Server, um sie lokal abzulegen.

Und um noch einen draufzusetzen: Bei Mails gibt es mindestens einen Absender und einen Empfänger. Daß Du Deine entverschlüsselte Mail in Sicherheit bringst ist schön und gut, aber Du kannst Dich nicht darauf verlassen, daß die andere Seite das auch tut. Und wann.

Ergo: Deine Methode ist gut gemeint, aber sie funktioniert nicht.
Das ist ein komplett anderer Anwendungsfall, und in (zumindest meiner) Praxis ziemlich irrelevant. Die Anzahl der Korrespondenten, von denen ich signierte PDFs bekommen habe, kann ich an den Fingern einer Hand abzählen. Ein paar Lieferanten, die ihre Rechnungen signieren, und ein Kunde, der seine Vertragsdokumente signiert - sonst nichts. Das ist Peanuts.

Um die Absender signierter Mails abzuzählen reicht es nicht einmal aus, wenn ich auch noch die Schuhe ausziehe.

Dabei ist nicht einmal nur die nachträgliche Validierung von Mails eine Motivation, sondern auch SPAM-Erkennung: Signierte Mails kann man bei der SPAM-Analyse recht großzügig mit Bonuspunkten bedenken, da SPAM fast nie (und das schreibe ich nur so vorsichtig, weil man nie "nie" sagen soll) signiert ist.

Ein Grund für die viel weitere Verbreitung signierter Mails gegenüber signierten PDF- oder anderer Dokumente ist natürlich auch die Bequemlichkeit: Mailsignierung passiert automatisch, Dokumente muß ich manuell signieren. Ersteres kann ich also als Default nehmen, letzteres nicht (so einfach) - ganz in Deinem Sinne der Vereinfachung.
Und beim zweiten Mal glaubst Du dann dem Header? Das wäre ... mutig

Signatur dient auch nicht nur der Verifikation des Absenders eines Dokuments oder einer Mail, sondern auch (und ganz wesentlich) der Verifikation ihres Inhalts gegen nachträgliche Veränderung. Daß die Rechnung verifizierbar von der Telekom kommt ist fein, aber wenn ich da zwischenzeitlich ein paar Zahlen zu meinen Gunsten verändern kann, dann ist damit nichts gewonnen.

Und Signatur hat noch einen weiteren wesentlichen Vorteil: Wenn ich signierte Mails versende, liefere ich dem Empfänger meinen öffentlichen Schlüssel frei Haus und der kann dann im nächsten Schritt seine Antwort verschlüsseln. Das ist dann tatsächlich mal wirklich vor allem bei der ersten Kontaktaufnahme wirklich interessant.
Da fehlt im ersten Satz ein "nicht", oder?

Was habe ich als Absender vom Signieren? Daß der Empfänger validieren kann, daß ich der Absender bin, nutzt mir als Absender erstmal nichts, bis ich beweisen kann, daß ich immer alle Mails signiere. Sonst kommt er mit einer überzeugenden Fälschung um die Ecke, die halt "zufällig" keine Signatur hat.

Gleiches gilt sinngemäß bei der Integritätsprüfung. Als Empfänger habe ich mehr davon als als Absender, von Ausnahmen (z.B. Rechnungen als signiertes PDF-Dokument) einmal abgesehen.

Aber wie gesagt: Ich bin da ganz bei Dir, das muß so einfach und selbstverständlich funktionieren, daß man es grundsätzlich immer tut. Beim Verschlüsseln ist das einfacher als beim Signieren, und selbst das kommt nicht so recht voran. Und gesetzgeberische Vorgaben sind aus den genannten Gründen eher unwahrscheinlich.

Das ist ein Widerspruch, und der zweite Teil ist der korrekte.

Ich kann eine Mail/ein Dokument nicht validieren, wenn ich nur das Leaf-Zertifikat habe, weil das ja wiederum gefälscht sein könnte. Dafür brauche ich die ganze Kette bis hin zur Root.
Zu 1: Ja. Zu 2: Nein.

Es gibt keine graduelle Validierung. Entweder die ganze Kette ist gültig, oder eine Validierung ist nicht möglich. Einen grünen Haken aufgrund eines passenden Leaf-Zertifikats ohne die Validierung dessen Gültigkeit kann man such aufs Brot schmieren.
Korrekt. Da fehlen die einfachen Prozesse, und auch deswegen ist es schwierig durchzusetzen. Wenn Tante Hildegard grundsätzlich alles verschlüsselt und vertüdelt beim Rechnerwechsel ihren private Key macht sie das mit der Verschlüsselung garantiert nie wieder. Das ist so ziemlich das, was sioh gestern meinte ("Archivierungsproblem").

"Blockchain"! Er hat "Blockchain" gesagt! Steinigt ihn!

Irgendwie reden wir gerade aneinander vorbei.

Ja, natürlich ist es so, wie Du schreibst. Genau deshalb will doch auch ich verschlüsselte Emails, obwohl ich die via TLS auf meinen Rechner hole und dann sofort vom Server lösche.

Mir ging es um Transport ↔︎ langfristige Speicherung. Und weil der Transport ungesichert ist, auch wenn man TLS benutzt (eben genau wegen der Zwischenlagerung auf Internet-Servern), will ich verschlüsselte Mails.

Ich persönlich bräuchte die Verschlüsselung aber eben nur dafür, weil ich sie via POP schnellstmöglich vom Server hole und dort lösche. Deswegen wäre es für mich wunderbar, wenn die Emails, sobald sie via POP hier angekommen sind, einmal entschlüsselt werden und dann dauerhaft entschlüsselt bleiben (wie andere Dateien halt auch, die nicht wichtig genug sind, sie extra zu verschlüsseln – was ich ggf. bei besonders wichtigen Mails ja auch machen könnte).

Und vor diesem Hintergrund wäre ich niemals auf die Idee gekommen, dass jemand S/MIME allen Ernstes benutzt, um Emails nicht nur für den Transport, sondern längerfristig zu verschlüsseln, um sie dann auf dem Server liegen zu lassen.
Ja, aber über diejenigen Nutzer, die nicht mal eine eigene Email-Domain haben, reden wir hier doch nicht (ginge S/MIME überhaupt mit Provider-Domains, also .icloud.com etc. – das weiß ich gar nicht?).
Kann sein, auch wenn ich das überhaupt nicht nachvollziehen kann. Aber dort könnten ggf. ja dann auch ihre entschlüsselten Emails liegen und wären damit halt so sicher oder unsicher wie all die anderen Dokumente auch.
Aber das geschieht bei Mail doch automatisch? (Jedenfalls, wenn man POP nutzt, bei IMAP weiß ich nicht.)
Na gut, aber das ist immer so. Über die andere Seite habe ich keine Kontrolle. Die kann mir das Dokument mit dem Anfahrtsplan zum Fundort des Steins der Weisen zehnmal per S/MIME schicken, wenn sie es gleichzeitig ungeschützt auf ihrem Rechner im Zeichenprogramm geöffnet lässt oder in ihrer Instagram-Story veröffentlicht, nützt mir S/MIME auch nix.
Was aber natürlich auch daran liegt, dass der Stand der Dinge da noch unausgegorener ist. Ich versuche seit Monaten vergeblich, das bei mir zum Laufen zu kriegen, aber weder gelingt es mir, ein 100% funktionierendes PDF-Programm dafür zu bekommen noch das entsprechende IV-Zertifikat. (Abenteuerroman hierzu im Forums-Thread Alternative zu kostenpflichtigen PDF Tools wie Acrobat Pro/DC oder pdf won...).
Guter Punkt, aber ich sage ja auch gar nichts gegen Validierung, nur, dass ich sie hauptsächlich kurzfristig relevant finde. Wenn die Nicht-SPAM-Mail zu Recht in meinem Eingangspostfach gelandet ist, brauche ich diesen Aspekt z.B. bereits nicht mehr.
Nein, da hast Du schon Recht, das war blöde von mir formuliert. Auch hier geht es um den Zeitaspekt. Wenn die Email einmal kontrolliert bei mir angekommen ist, dann ist das auch abgehakt.
Nö, da fehlt keins.

Als Absender hast Du z.B. davon, dass Du mit einem signierten Kreditantrag einen Kredit bekommst, mit einem nicht signierten aber nicht.

Die Frage in solchen Fällen ist doch nicht signiert oder nicht signiert, sondern digital signiert oder handschriftlich signiert. Und da wäre Ersteres – WENN es denn endlich mal problemlos funktionieren würde – einfach viel weniger umständlich und viel sicherer als Letzteres.

Das sollte eine gute GUI aber gewährleisten und bei macOS sehe ich da keine größeren Probleme, da der Schlüsselbund ja automatisch alles aufbewahrt.

Nutzt Tante Hildegard beim Rechnerwechsel den Migrationsassistenten, bleiben die Zertifikate auch dann erhalten. Nutzt sie ihn nicht, sind die Emails auch weg, also egal.

Dass Tante Hildegard auf die Idee kommt, in der Schlüsselbundverwaltung gezielt abgelaufene Zertifikate zu löschen, halte ich für sehr unwahrscheinlich. Aber da könnte man die GUI sicher noch verbessern, indem beim Versuch, ein abgelaufenes Zertifikat zu löschen, zunächst ein Dialog um Bestätigung bittet unter eindringlichem Hinweis, was das Löschen für Folgen hätte.

Mit Verlaub, das ist schlichtweg kryptografisch nicht korrekt. Das ist das Narrativ, welches dich die PKI-Anbieter wollen glauben lassen, aber wenn du Public Key + Signatur hast, kannst du einwandfrei die Authentizität der Signatur prüfen. Ob der Key abgelaufen ist, revoked wurde oder das Root Cert nicht mehr existiert, spielt keine Rolle.

Mathematisch betrachtet. Dass die GUIs die ganze Chain validieren ist ein anderes Thema, welches wie gesagt einen gewissen Sinn hat. Hier geht es aber eher um Leaks der Private Keys und die damit verbundene Möglichkeit, unautorisiert zu signieren. Eine solche Signatur ist dennoch GÜLTIG. Leaks zu unterbinden ist übrigens auch der Grund, warum es überhaupt Ablaufdaten gibt... Hier gehts tatsächlich nicht nur um Umsatzsteigerung


Ich seh da wie gesagt kein Problem. Nur kam es weiter oben so rüber, als sei es eine überaus exotische Angewohnheit, seine Private Keys aufzubewahren...

Mit Verlaub, das ist nur die halbe Wahrheit (OK, das war meine Aussage oben auch, dann sind wir wohl quit).

Wenn Du, das ist das, worauf Dein Einwand abzielt, den Public Key auf für Dich verifizierbarem und sicherem Wege erlangt hast, dann kannst Du ihn selbstverständlich zur Prüfung der Signatur einsetzen.

Darüber, daß das mit der aktuellen X.509-PKI eher ein Glücksspiel ist, müssen wir kein Wort verlieren - das ist hinlänglich bekannt. Auch aus diesem Grunde setze ich für viele Zwecke meine eigene (und wohlgesicherte) CA ein und vertraue dann auch ausschließlich dieser.

Aber irgendwie mußt Du das Zertifikat, das den Public Key zur Validierung der Signatur enthält, seinerseits validieren. Wie das passiert ist eine andere Sache, aber ein Weg ist der über die Root, und bei einem Großteil der "Normalverbraucher" wird das der einzige Weg sein, den sie je gehen werden.

Ich kann gut nachvollziehen, dass du das aus reiner Anwendersicht so siehst. Den Sinn hinter einer hierarchischen PKI zweifle ich ja gar nicht an.

Ich habe lediglich die kryptografische Ebene ergänzt, da die ursprüngliche Aussage fälschlicherweise nahelegt, abgelaufene Zertifikate seien nicht mehr zur Signaturprüfung geeignet und die Chain muss weiterhin validiert werden. Eine Zahl läuft aber schlichtweg nicht ab.

Die Prämisse hierbei war ja, dass man bereits in Besitz des Public Keys ist. Dass man diesen möglicherweise nicht mehr erhält, nachdem er abgelaufen ist, ist ja ein völlig anderes Thema.

Im Übrigen verifiziert jeder von uns ohne es zu wissen täglich zich mal Signaturen, die durch abgelaufene Zertifikate erstellt wurden. Das ist für das Betriebssystem im Kontext Codesigning Alltag. Wichtig hierbei ist lediglich, dass das Zertifikat zum Zeitpunkt der Signatur gültig war (Stichwort Timestamping).

Hm, aber gab es da nicht gerade z.B. das Problem, dass die alten macOS-Installationsprogramme sich nicht plötzlich mehr starten ließen, weil die Zertifikate abgelaufen waren?

Nicht ganz. Das Installationsprogramm lässt sich starten, verweigert aber das Öffnen zu alter Paketdateien. Die Installationspakete werden nicht mit Codesigning versehen, sondern verwenden ältere und "naivere" Techniken, die einfach nur Unversehrtheit und Herkunft des Pakets mit einem Zertifikat bestätigen.

Ich zitiere mich mal selbst, das macht es einfacher:Ich nehme an, das ist der Satz, auf dem unser Mißverständnis beruht.

Das Problem, auf das ich abhebe, ist eben das Kernproblem bei der Verifikation: Du mußt in der Lage sein, die Authentizität des Zertifikats irgendwie zu validieren. Da habe ich es mir mit dem Verweis auf die Zertifikatskette zu einfach gemacht, das geht natürlich auch anders (aber eben, wenn man der X.509-PKI vertraut, auch so, und es dürfte der Normalfall sein). Und an der Stelle war der Verweis auf den Ablauf natürlich Unfug, solange die Zertifikate noch irgendwie verfügbar oder archiviert sind.

Ein Zertifikat liefert Dir ja nur als eine seiner Funktionen den öffentlichen Schlüssel des Signierers. Damit kannst zwar sehr schön validieren, daß ein Dokument, eine Mail etc. mit einem dazugehörigen privaten Schlüssel signiert und danach nicht verändert worden ist, aber das war es dann auch - das ist nicht unbedingt das, was Du wissen willst.

Was Du bei einer Signaturprüfung wissen willst, ist auch und ganz wesentlich wer das Dokument signiert hat. Dafür brauchst Du die Metadaten aus dem Zertifikat (CN, DN, SAN etc.). Und deren Integrität und ihren Zusammenhang mit dem öffentlichen Schlüssel kannst Du nur validieren, wenn Du entweder das Zertifikat aus gesicherter Quelle hast, oder eben wenn Du die Signatur des Zertifikats anhand der Zertifikatskette prüfen kannst. Oder wenn Du den Inhaber des Zertifikats nach dem Fingerprint fragst und den dann manuell validierst. Das kann auch sehr lustig sein.

Ohne diese Voraussetzungen jubele ich dem Empfänger ein von mir selbst mit Phantasie-Metadaten signiertes Zertifikat und ein damit signiertes Dokument unter und er vertraut einer kompletten Luftnummer.
Nein, das war eigentlich genau das Ausgangsthema. Es ging um die Archivierung verschlüsselter bzw. signierter Daten und den Zusatzaufwand, der zur parallelen (und sicheren) Aufbewahrung der zugehörigen Zertifikate bzw. der privaten Schlüssel erforderlich ist.
Erstens: Das Thema "Ablaufdatum" haben wir jetzt hoffentlich mal endgültig vom Tisch. Zweitens: Erzähl das Apple ... (nur ein Beispiel von vielen).

Genau.

Eben, ich ging davon aus, dass die Aufbewahrung an Kommunikation beteiligter Schlüssel Prämisse aller nachfolgenden Aussagen war. Siehe dein Selbst-Zitat. 😉

Ich mache das zumindest so und kann problemlos uralte Mails durchsuchen und - sollte es drauf ankommen - deren Authentizität und Integrität heute noch beweisen, obwohl die Zertifikate der jeweiligen Absender längst abgelaufen sind. Genau deshalb, weil ich die Zertifikate immer noch habe und diese unabhängig von der Chain als authentisch einstufe.

Ja Apple ist in der Hinsicht nicht so vorbildlich (siehe )... Aber zum Glück besteht das Internet nicht nur aus Apple.

Ja, das mache ich ja grundsätzlich auch. Aber Du bist nicht Tante Hildegard (92), und ich auch nicht. Und wie viele Tante Hildegards es in Unternehmen gibt, willst Du gar nicht wissen.
Das ist aus verschiedenen Gründen ganz gut. Mir fällt da als einer der ersten Punkte die nicht vorhandene IPv6-Erreichbarkeit des Unternehmens ein. Damit sind sie nicht allein, aber das macht den Umstand, daß eines der zahlungskräftigsten Unternehen der Welt es nicht für nötig hält, in eine längst überfällige Umstellung der Infrastruktur zu investieren, die es am Leben hält.

Ob nun allerdings das Nichtakzeptieren ungültiger Codesignaturen vorbildlich ist oder nicht, darüber läßt sich auch streiten - ich erwarte z.B., daß im Fall eines zurückgerufenen Code-Signaturzertifikats die Software den Dienst verweigert. Bei einem abgelaufenen Zertifikat ist die Lage schon nicht mehr so eindeutig - da geht meine Tendenz eher in die Richtung, es lieber akzeptiert zu haben.

Ungültig ist das Zertifikat strenggenommen in beiden Fällen.

Tante Hildegard raucht zu viel:Sie altert rapide …

void ist halt charmanter als ich.

Ich erwarte von Hildegard (102) nicht, dass sie versteht, was da passiert. Wieviel Vorwissen notwendig ist und wieviel Komplexität vor der Anwenderin verborgen bleibt kommt natürlich immer auf die im Einzelfall eingesetzte Software an - aber noch benötigte Daten nicht einfach so zu löschen ist mMn eine der trivialer umzusetzenden Anforderungen, die man an Software im PKI-Umfeld stellen darf...

macOS schafft es anscheinend zumindest:


Revocation Lists, wie zb auch Apples Notarization-Ansatz, sind ein verwandtes, sinnvolles, jedoch wieder leicht anderes Thema. 😉

Code Signing dient vorrangig dazu, die Herkunft und Unversehrtheit der Binary überprüfbar zu machen. Beide Informationen verfallen nicht, von daher tu ich mich hier mit dem Begriff "ungültig" schwer, solange das Zertifikat seinen vorgesehenen Zweck erfüllt. Wichtig ist wie gesagt, dass die Signierung noch innerhalb der gültigen Periode stattgefunden hat (und idealerweise dann auch Time-Stamping zum Einsatz kam).

Bei MS Authenticode z.B. sind Code Signing Zertifikate je nach Einsatzzweck nur 1 Jahr gültig. Trotzdem willst du als Anwender die Software ja auch im Folgejahr noch installieren können UND dabei deren Authentizität prüfen können. Das Zertifikat ist dann schon abgelaufen - aber ist es deshalb "ungültig"? signtool.exe sagt: nein.

Um den Kreis zurück zu S/Mime zu schließen: Auch hier sind Signaturen noch gültig, wenn das Zertifikat des Absenders bereits abgelaufen ist. Den Kreis zu TLS schaffe ich jetzt allerdings nicht mehr zu schließen.