Let's Encrypt kann E-Mail-Servern Probleme machen

[Patrick Ben Koetter]

* Daniel <postfixbuch-users at listen.jpberlin.de>:
> Neue Zwischenzertifikate von Let's Encrypt können zu abgewiesenen E-Mails
> führen. Der Fehler ist nicht groß, zeigt aber grundsätzliche Probleme.
> 
> Ganzer Artikel hier
> https://www.golem.de/news/dane-let-s-encrypt-kann-e-mail-servern-probleme-machen-2012-152559-rss.html
> 
> Nehmt ihr Änderungen am Server und/oder DNS vor?

Nein, denn wie die meisten anderen auch, müssen wir nichts ändern.

Änderungsbedarf besteht nur dann, wenn eine Domain alternativ oder zusätzlich
zum Fingerprint des Serverzertifikates auch den Fingerprint des Zertifikates
der signierenden Sub-CA als weiteren TLSA Record veröffentlicht hat.

Den Fingerprint des Serverzertifikates erkennst Du an der 3 1 1 Zeichenfolge
im TLSA Record wie in diesem Beispiel:

$ dig +short TLSA _25._tcp.mail.sys4.de
3 1 1 236831AEEAB41E7BD10DC14320600B245C791B338121383D5A2916F7 EF97B49B

Wer einen TLSA RR erhält, der mit einer 2 1 1 Zeichenfolge beginnt, der hat
(auch) den Fingerprint des Zertifikates der signierenden CA im DNS.

Dieser TLSA Record muss jetzt erneuert bzw. ausgetauscht werden, denn LE hat
das Zertifikat seiner signierenden Sub-CA ausgetauscht und jetzt passen der im
DNS veröffentlichte Fingerprint und der des Sub-CA-Zertifikates nicht mehr
zusammen.

Handlungsbedarf besteht also nur wenn

- LE-Zertifikate genutzt werden
- der Fingerprint des Zertifikates der Sub-CA im DNS veröffenlicht wurde
- der Fingerprint des Zertifikates der Sub-CA im DNS nicht der der neuen
  Sub-CA ist


= Warum ist das erforderlich?

LE hat das Signierzertifikat der Sub-CA gewechselt und das hat jetzt einen
neuen Fingerprint. Mit diesem Signierzertifikat werden alle neuen/erneuerten
Serverzertifikate signiert. In deinem Serverzertifikat hättest Du also die
neue Sub-CA und im DNS die alte Sub-CA und wenn dann der Fingerprint Deines
Serverzertifikates nicht mit den Angaben im DNS passt und eine Verfizierung
des Serverzertifikates fehlschlüge.


= Welches Risiko besteht?

Wenn weder die Verifizierung des Serverzertifikates noch die des der Sub-CA
gelingen, dann wird der SMTP-Client keine Mail senden, weil die
Voraussetzungen für einen sicheren Transport nicht gegeben sind. Nachrichten
werden sich in der Queue sammlen und entweder bouncen oder zugestellt werden,
sobald das Fingerprint-Problem behoben wurde.


= Wie wahrscheinlich ist, dass der Fall eintritt?

Ich persönlich halte die Wahrscheinlichkeit für sehr gering, denn nur sehr
wenige nutzen die Möglichkeit auch die Sub-CA im DNS als trusted zu announcen.
Und die, die das tun, haben ihren Laden für gewöhnlich im Griff.


= Zum Artikel

Ich halte den Artikel für wenig nützlich. Er spricht spekulativ von einem
"kann" und so wie das Zitat von Phil Pennock genutzt wird, entsteht der
Eindruck man *müsse* jetzt „Unterstützung für die neuen Zwischenzertifikate”
(golem) hinzufügen.

Fakt ist: Niemand muss das. Jeder kann das. Kaum einer tut es.

Aus meiner Sicht ist der Erkenntnisgewinn in diesem Artikel sehr gering und
eine Hilfestellung, was denn jetzt getan werden kann, erkenne ich nicht im
Ansatz. Es ist ein "Da hast Du ein Problem und keine Lösung"-Artikel.

Stattdessen transportiert er eher Verunsicherung und wertet DANE am Ende als
unbedeutend ab.

Fakt ist: Microsoft implementiert DNSSEC/DANE für seine Cloud-Plattformen und
Google sitzt auch dran. Ein „International ist DANE aber bedeutungslos“ kann
ich, anders als der Artikel es behauptet, nicht erkennen.

p at rick

-- 
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG,80333 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief
Aufsichtsratsvorsitzender: Florian Kirstein

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 4436 bytes
Beschreibung: nicht verfügbar
URL         : <https://listi.jpberlin.de/pipermail/postfixbuch-users/attachments/20201204/3c1a9158/attachment.p7s>