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

[Daniel-6]

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

[Thore Bödecker]

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

[Klaus Tachtler]

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

[Sebastian Wiesinger]

* 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

[Patrick Ben Koetter-2]

* 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, [phone]
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

[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

[Gerald Galster-2]

Neue Zwischenzertifikate von Let's Encrypt können zu abgewiesenen E-Mails führen. Der Fehler ist nicht groß, zeigt aber grundsätzliche Probleme.

Nur als Gedanke in die andere Richtung: Probleme könnte es

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