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 Gruß Daniel |
Hi Daniel.
On 04.12.20 12:32, Daniel wrote: > 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? > > Gruß Daniel > Erstmal betrifft das nur diejenigen, die DNSSEC + DANE via TLSA Record überhaupt aktiviert haben. Außerdem (was ich sowohl an der Aussage von dem Exim Dev als auch im Golem Artikel vermisse), entstehen die Probleme meines Wissens nach nur bei DANE-TA, d.h. bei "Certificate Usage" == 2 im TLSA Record. Ich persönlich würde nur DANE-EE, d.h. "Certificate Usage" == 3 im TLSA Record verwenden, dabei wird die Trust Chain des Zertifikates nicht weiter geprüft, was meiner Meinung nach in diesem Fall auch nicht weiter notwendig ist. Via DNSSEC wird eine überprüfbare/vertrauenswürdige DNS Auflösung vermittelt (sofern der Resolver das AD Flag auch weitergibt) und in diesen DNS Daten werden dann die ausgewählten Informationen über Zertifikat bzw. Pubkey veröffentlich. Wenn das dann beim Verbindungsaufbau übereinstimmt, hat man auch eine "trusted" Verbindung. Nachzulesen hier: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Certificate_usage Aktuell zögere ich noch mit einem TLSA Record bei LetsEncrypt, da ich beim Renew auch immer einen frischen Key generieren lasse. Somit bräuchte ich ein automatisiertes System, was zunächst den neuen (zusätzlichen) TLSA Record veröffentlich, 2x die TTL abwartet und erst dann den Postfix mit dem neuen Zertifikat reloaded. Anschließend kann dann alte TLSA Record entfernt werden. Um das ganze rock-solid zu bekommen ist etwas frickeln und viel Testen notwendig, daher bin ich diesen Schritt noch nicht gegangen, steht aber definitiv auf der Wunschliste. :) Grüße, Thore -- Thore Bödecker GPG ID: 0xD622431AF8DB80F3 GPG FP: 0F96 559D 3556 24FC 2226 A864 D622 431A F8DB 80F3 |
Hallo Thore,
bei der Neugenerierung verzichte ich auf die Erzeugung eines Schlüssels und erteuge nur das Zertifikat neu. Grüße Klaus. -- Diese Nachricht wurde von meinem Android-Gerät mit FairMail gesendet. Von: Thore Bödecker <[hidden email]> An: Diskussionen und Support rund um Postfix <[hidden email]> Empfangen: 04.12.2020 12:52:29 Betreff: Re: Let's Encrypt kann E-Mail-Servern Probleme machen > Hi Daniel. > > On 04.12.20 12:32, Daniel wrote: >> 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? >> >> Gruß Daniel >> > > > Erstmal betrifft das nur diejenigen, die DNSSEC + DANE via TLSA Record > überhaupt aktiviert haben. > > Außerdem (was ich sowohl an der Aussage von dem Exim Dev als auch im > Golem Artikel vermisse), entstehen die Probleme meines Wissens nach > nur bei DANE-TA, d.h. bei "Certificate Usage" == 2 im TLSA Record. > Ich persönlich würde nur DANE-EE, d.h. "Certificate Usage" == 3 im > TLSA Record verwenden, dabei wird die Trust Chain des Zertifikates > nicht weiter geprüft, was meiner Meinung nach in diesem Fall auch > nicht weiter notwendig ist. > Via DNSSEC wird eine überprüfbare/vertrauenswürdige DNS Auflösung > vermittelt (sofern der Resolver das AD Flag auch weitergibt) und in > diesen DNS Daten werden dann die ausgewählten Informationen über > Zertifikat bzw. Pubkey veröffentlich. > Wenn das dann beim Verbindungsaufbau übereinstimmt, hat man auch eine > "trusted" Verbindung. > > Nachzulesen hier: https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities#Certificate_usage > > > Aktuell zögere ich noch mit einem TLSA Record bei LetsEncrypt, da ich > beim Renew auch immer einen frischen Key generieren lasse. Somit > bräuchte ich ein automatisiertes System, was zunächst den neuen > (zusätzlichen) TLSA Record veröffentlich, 2x die TTL abwartet und erst > dann den Postfix mit dem neuen Zertifikat reloaded. Anschließend kann > dann alte TLSA Record entfernt werden. > Um das ganze rock-solid zu bekommen ist etwas frickeln und viel Testen > notwendig, daher bin ich diesen Schritt noch nicht gegangen, steht > aber definitiv auf der Wunschliste. :) > > > Grüße, > Thore > > -- > Thore Bödecker > > GPG ID: 0xD622431AF8DB80F3 > GPG FP: 0F96 559D 3556 24FC 2226 A864 D622 431A F8DB 80F3 |
In reply to this post by Daniel-6
* Daniel <[hidden email]> [2020-12-04 12:32]:
> 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? Ich verwende für DANE einen 3 1 1 TLSA Record, das hängt dann nur am Private Key der sich nicht ändert. Gruß Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant |
In reply to this post by Daniel-6
* Daniel <[hidden email]>:
> 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@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 |
In reply to this post by Sebastian Wiesinger
* Sebastian Wiesinger <[hidden email]> [2020-12-04 13:36]:
> * Daniel <[hidden email]> [2020-12-04 12:32]: > > 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? > > Ich verwende für DANE einen 3 1 1 TLSA Record, das hängt dann nur am > Private Key der sich nicht ändert. Also der Record hängt natürlich eigentlich am Public Key Hash. ;) Jedenfalls ist das Zertifikat bzw. die Chain egal. Gruß Sebastian -- GPG Key: 0x58A2D94A93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant |
In reply to this post by Daniel-6
geben wenn z.B. noch ältere Smpartphones genutzt werden, die keine Updates mehr erhalten und das neue CA-Zertifikat dadurch nicht kennen. Viele Grüße Gerald
|
Free forum by Nabble | Edit this page |