Let's Encrypt auch verschlüsselt?

3

3df

Registered User
Hallo, sind die Let's Encrypt SSL Zertifikate auch verschlüsselt, also verschlüsseln diese z.B. auch den E-Mail Verkehr, oder sind diese nur dazu da, eine Gültigkeit anzuzeigen?

Danke
 
Ich versteh die Frage nicht ganz, aber die sind nicht für S/MIME da, nur Webserver.

Zitat aus der Let's Encrypt FAQ:

Can I use certificates from Let’s Encrypt for code signing or email encryption?

No. Email encryption and code signing require a different type of certificate than Let’s Encrypt will be issuing.
Click to expand...
 
XioniX said:
Ich versteh die Frage nicht ganz, aber die sind nicht für S/MIME da, nur Webserver.
Click to expand...

Nicht ganz korrekt, sie lassen sich auch für andere TLS-Verbindungen nutzen, z.B. bei einem SMTP-Server, IMAP-Server oder auch Mumble/Murmur.
Ansonsten verstehe ich dir Frage des TE aber auch nicht so ganz: Zertifikate von Lets Encrypt sind ganze normale domain-verifizierte Zertifikate, sie könenn für Transport-Verschlüsselung (TLS) genauso eingesetzt werden wie die von anderen (i.d.R. kostenpflichtigen) Zertifizierungsstellen.
 
Hallo, sind die Let's Encrypt SSL Zertifikate auch verschlüsselt
Click to expand...
Nicht böse aber ich glaube du hast die Grundidee hinter CA-Zertifikaten ("HTTPS") nicht ganz verstanden.
Eine HTTPS-Verbindung ist im Grund eine verschlüsselte (TLS) Verbindung über welche "normaler" HTTP-Verkehr läuft. Der Server beweist mit dem Zertifikat seine Identität und verwendet die im Zertifikat enthaltenen Krypto-Informationen in Verbindung mit dem sogenannten Diffie-Hellman Algorithmus um eine verschlüsselte Verbindung auf zu bauen. Es macht also immer sowohl Identitätsprüfung des Servers UND Verschlüsslung.

Was genau über die Verbindung läuft ist TLS und dem Zertifikat dabei egal, es kann also auch Email-Verkehr, VPN, ... sein.

Signieren kann man aber mit Webserver-Zertifikaten generell nicht, das ist ein anderes Protokoll, generell S/MIME.
 
Ich frage deshalb, weil mir jemand gesagt hat, dass das Let‘s Encrypt Zertifikat z.B. Keine E-Mails verschlüsseln würde (wenn man es im Mailserver einsetzt), und diese auch mit dem Zertifikat im Klartext versendet werden. Das Let‘s Encrypt wäre nur dazu da die „Echtheit“ zu bestätigen. Also das man keine Meldung bekommt das das Zertifikat z.B. Nicht gültig sei.

Da ich aber meine E-Mails gerne verschlüsselt haben möchte, würde ich mir dann nun ein Zertifikat kaufen, falls Let‘s Encrypt nicht ausreicht bzw. die Mails damit trotzdem nicht verschlüsselt gesendet werden.
 
Wenn du einzelne Mails verschlüsselt versenden willst, benötigst du (im Falle von S/MIME) das Zertifikat des Empfängers bzw. dessen öffentlichen Schlüssel (der im Zertifikat enthalten ist). Mit deinem eigenen Zertifikat kannst du keine verschlüsselten Mails versenden, sondern nur signieren (und der Empfänger kann dann anhand deines Zertifkats prüfen, dass die Mail von dir stammt und nicht verändert wurde). Dein Gegenüber kann dir mit deinem Zertifikat dann auch verschlüsselte Mails senden. Prinzipiell ist das Zertifikat nur zur Identitätsprüfung da, die eigentliche Verschlüsselung erfolgt über den öffentlichen Schlüssel (der u.a. im Zertifikat enthalten ist, aber auch ohne ausgetauscht werden kann) und die Endschlüsselung mit dem privaten Schlüssel (welcher nur dir vorliegt).
 
3df said:
... Keine E-Mails verschlüsseln würde (wenn man es im Mailserver einsetzt), und diese auch mit dem Zertifikat im Klartext versendet werden...
Click to expand...
Man könnte es so sagen: Die unverschlüsselten Mails werden über eine verschlüsselte Verbindung gesendet.

Die Mail ist also unverschlüsselt und unsigniert. Was nach der Übermittlung von deinem MTA auf den nächsten mit der Mail weiter passiert entzieht sich deinem Zugriff. Sie könnte also auf dem nächsten Teilstück über einen Klartext-Transport gehen (oder auch in Kopie zu CIA und SWR geschickt werden...).
 
Also wird der E-Mail Versand auch bei einem gekauften SSL Zertifikat nicht verschlüsselt übertragen sondern weiterhin im Klartext?

Denn ich möchte nicht, dass die E-Mail bei der Übertragung vom Server zum Empfänger im Klartext versendet wird.
 
3df said:
Also wird der E-Mail Versand auch bei einem gekauften SSL Zertifikat nicht verschlüsselt übertragen sondern weiterhin im Klartext?
Click to expand...

E-Mail Versand != E-Mail-Text verschlüsseln.

Der Transport der E-Mail kann verschlüsselt passieren, dies hängt aber vom jeweiligen Client UND Mailserver ab.

Manche erzwingen das, manche sagen nur "Hey, ich kann TLS".

Auch wenn der Transportweg ("Versand") via TLS verschlüsselt ist, bleibt die E-Mail dennoch im Klartext.

Anmerkung: PGP verschlüsselt keine Metadaten (Betreff, Versender, Empfänger etc.)
 
Okay. Und was mache ich jetzt am besten serverseitig? Oder reicht das Let’s Encrypt Zertifikat völlig aus?
 
3df said:
E-Mail Versand auch bei einem gekauften SSL Zertifikat nicht verschlüsselt übertragen sondern weiterhin im Klartext?
Click to expand...

Ob Du für das SSL/TSL-Zertifikat bezahlst oder einen kostenfreien Anbieter wie Let's Encrypt verwendest ändert nichts an den technischen Gegebenheiten.

Ein TLS/SSL-Zertifikat schützt TLS/SSL-Kommunikation, also den Transportweg von Server zu Server. In der Mailbox am Zielserver liegt die Mail im Klartext, der Mailserver-Admin könnte sie also ebenso wie der legitime Empfänger lesen. Lediglich der Transportweg ist geschützt, nicht aber die Ablage in den Mailboxen selbst.

Das Problem hierbei: Nicht alle Mailserver unterstützten TLS-Transportverschlüsselung und prüfen meist auch die Zertifikate gar nicht. Du kannst Deinen Server aber freilich so konfigurieren, dass Du keine Klartext-SMTP-Verbindungen annimmst und auch abgehend nur verschlüsselte Verbindungen zulässt. Die meisten Mailserver unterstützen Verschlüsselung - an manche Empfänger wirst Du dann allerdings nichts mehr senden können.

Eine ausführliche Anleitung zur Mailserver-Konfiguration auch mit DANE findest Du hier: https://hitco.at/blog/sicherer-e-mail-dienste-anbieter-dnssec-dane/

Ein SMIME-Zertifikat hingegen schützt den Inhalt der Mail (aber exclusive Mailheader & Subject-Line). Das Problem dabei: Es nützt dir als Empfänger nichts, wenn Du ein SMIME-Zertifikat besitzt, die Personen die Dir Mails senden es allerdings weiterhin im Klartext tun. Abgesehen von technisch sehr versierten Anwendern oder solchen denen Du den Mailclient persönlich so konfigurierst, dass sie Dir verschlüsselt senden wirst Du also kaum verschlüsselte Mails erhalten - weder von Firmen noch von Privatpersonen.

SMIME oder GPG/PGP Ende-zu-Ende Verschlüsselung ist daher in der Praxis kaum breitflächig nutzbar, es fehlt einfach die Awareness und technische Versiertheit der Anwender und Unternehmen. Gut nutzbar ist es hingegen innerhalb von Unternehmen (Mitarbeiter A sendet an Mitarbeiter B des gleichen Unternehmens) - da erhalten einfach alle von der unternehmenseigenen CA ein Zertifikat und der gesamte interne Mailverkehr bleibt auch gegenüber der Mailserver-Admins vertraulich und der Absender ist zudem garantiert.
 
Okay, mir geht es nicht darum, dass die Mail verschlüsselt im Mailbox Ordner oder im Mail Client liegt, sondern es geht mir nur um den Transportweg.
 
Dann mal noch eine doofe Frage, wozu sollte man sich dann noch kostenpflichtig Zertifikate kaufen wenn es Let’s Encrypt gibt?
 
Weil LetsEncrypt beispielsweise keine OV oder EV Zertifikate anbietet und auch weil der Kundensupport seitens LetsEncrypt stark eingeschränkt ist.
 
Für schlichte Domainvalidierte Zertifikate gibt es wenig Gründe, warum man einen kostenpflichtigen Anbieter Let's Encrypt gegenüber bevorzugen sollte.

Es gibt aber auch andere Validierungsformen, Verwendungszwecke abseits von TLS/SSL und Szenarien in denen der CertBot eher nicht oder unkonfortabel anwendbar ist. Zuletzt bleibt auch noch die Eigenschaft des sehr kurzen Gültigkeitszeitraumes von nur 90 Tagen, was eine Automatisierung des Renewal-Vorganges erfordert. Manch einer zahlt da lieber ein paar Euro und nutzt weiterhin ein traditionelles Dienstleister-Modell mit 1-3 Jahren gültigen Zertifikaten, eventuell sogar mit Extended-Validation.
 
Ok also um es abzuschließen. Ist so alles in Ordnung wie es bei mir ist und ein kostenpflichtiges Zertifikat würde mir außer vielleicht die Jahre lange Gültigkeit und den Support nicht mehr bringen.
 
Um nur den reinen Transport zu verschlüsseln reicht Lets Encrypt aus - sofern man die Zertifikatserneuerung automatisieren kann (z.B. mit Certbot, gibt auch andere).
Wenn du aber darüber hinausgehende Anforderungen hast, dann kaufst du dir ein kostenpflichtiges Zertifikat, z.B. bei einem Online-Shop oder einer Bank. Die Zertifizierungsstelle prüft dann beispielsweise die Daten des Zertifikatsinhabers, d.h. bei amazon.de steht da als Organisation "Amazon.com, Inc." drin, während hier beim SSF in dem Feld nix drin steht.
Rein auf die Verschlüsselung hat das aber keine Auswirkung, sie wird dadurch nicht besser oder schlechter, das regeln einzig die Einstellungem im jeweiligen Server und Client (z.B. Webserver und Browser).
 
Wenn du aber darüber hinausgehende Anforderungen hast, dann kaufst du dir ein kostenpflichtiges Zertifikat, z.B. bei einem Online-Shop oder einer Bank. Die Zertifizierungsstelle prüft dann beispielsweise die Daten des Zertifikatsinhabers
Click to expand...
Ob weitere Informationen drin stehen hängt stark vom Angebot des Anbieters ab. Viele günstige Zertifikate, insbesondere Comodo und Comodo-signierte Derivate, sind ausschliesslich DV (Domainvalidiert) und haben damit keine Zusatzinfos. Das gilt auch für die entsprechenden Wildcard-Zertifikate.
Die kostenpflichtigen Zertifikate von StartCOM (RIP) bspw aber waren alle inhabervalidiert.

Grob gibt es 3 Stufen

a) DV: Domain-Validated. Hier läuft alles auf Seiten der CA automatisch ab, sie hat somit kaum Kosten. Deshalb kann LetsEncrypt kostenfrei DV Zertifikate anbieten.

b) OV: Owner/Org-Validated. Hier wird in einem CA-internen Prozess validiert ob der Besitzer gültig ist und der Besitzer dann im Certificate veröffentlicht. Die Validierung reicht von Fotos des Perso über Telefonanrufe bis zu Briefvalidierung.

c) EV: Diese Zertifikate haben einen grünen Balken, sind aber ansonsten ähnlich OV ausser dass die Validierungsprozedur standardisiert ist (CA Forum).
 
You must log in or register to reply here.
Back
Top